The document discusses the key considerations and tools needed to start an identity federation. It recommends establishing a public website, participant enrollment process, metadata publication and distribution, discovery standards, user claims, client claim schema, UMA scopes, SAML proxy, charter, participation agreement, user banner for consent, steering committee, and communication plan. Starting a federation takes work but national authorities and companies like Gluu can provide assistance.

1. GO WEST YOUNG FEDERATION
Several countries are helping businesses to start federations. For example, there is
the British Business Federation Authority. At the IdentityNext conference last month
in the Hague, I was lucky to hear Rainer Hörbe give a talk about the Austrian
Identity Federation Authority, which aims (1) to establish and nourish multiple
identity federations for B2B and B2C business cases; (2) to help business-specific
federations adapt to local needs; and (3) to consolidate federations over time
through the promotion of common principles, rules and procedures.
In a B2B federation, the participants are competing parties. This diagram from
Rainer’s presentation highlights that identity federation is a good area for
cooperation, because companies compete based on products and services and core
activities, like R&D and Marketing–not on supporting activities such as
infrastructure and security.
So if you are sitting there and wondering, “Does my ecosystem need an identity
federation…?” The answer is probably “yes.” According to national federation
authorities, not only does every ecosystem need one, but you should align with best
practices in case there is a federation merger with an adjacent industry.

2. But starting your federation is easier said than done. This is why some governments are
jumping in to help. If you are going to be the federation evangelist in your ecosystem, and
you don’t have a national federation authority to give you a boost, where should you
start? Following is a list of some of the things you may want to consider.
Tools
Public Website
This is the first stop for participants who are interested to learn more about your
federation. You’ll need to publish information about your federation, such as the
agreements, policies, procedures, participant list, metadata distribution locations,
standards and other general information.
Participant Enrollment Process
New participants, both identity providers and relying parties, will want to join your
federation. You need a tool to automate participant registrations, to manage the workflow
for approval, and to finally render the metadata in the appropriate formats (XML and
JSON). Many federations write their own software to do this. There are two open source
implementations: Edugate Jagger (used by Gluu) and AAF Federation Registry.

3. Metadata publication and distribution
Once you have your XML and JSON federation files, you’ll need to make sure they
are available. Think DNS and secondary DNS… In many cases, the federation data is
updated every five minutes. So if the metadata is not available during network
outages, websites may choose to deny access.
Discovery Standards
OpenID Connect based discovery defines a standard json object that is returned for
.well-known/openid-configuration. The federation may want to follow this convention,
and provide a JSON object that describes the functionality that is supported by the
participant. You can see a sample response for OpenID Discovery from Gluu’s interop
server here. Following the convention of Webfinger, the federation named
“myFederation” may define a file such as this: .well-known/myFederation-configuration
to enable the participants to publish information about the services provided.
User Claims / OpenID Connect Scopes
OpenID Connect defines basic user claims, which should be adopted by the federation. However,
the federation may have custom requirements for standard claims. Defining standard claims at
the federation drives down the cost of integration for the participants.

4. “OpenID Connect Scopes” enable the federation to group the user claims. If a
federation has defined custom user claims, they may also need to define OpenID
Connect scopes to include these additional claims.
Client Claim Schema
Sometimes policy can be driven by attributes of the website. For example, if certain
websites are classified as “research,” the IDP may have a different default attribute
release policy.
UMA Scopes
UMA scopes are typically URLs that identify federation standards for policy
evaluation. For example, the federation could define a scope
“http://myFederation.org/uma/scopes/finance” (“Finance Scope”) In this way Relying
Parties could submit a standard query to any authorization server to find out if that
person has that permission. The policies behind this permission may vary from
Participant to Participant. Participant A might specify that someone is authorized for
the Finance Scope if they are in a certain Active Directory Group. Participant B may
set the policy for Finance Scope based on network address and time of day. The
benefit of the federation standard scope is that applications can make the same
request to different authorization servers, requiring less one-off security solutions.

5. SAML Proxy
A SAML proxy can make it easier for a federation to roll out new websites to its IDP
participants. In meshed federations, the IDP must explicitly trust the SP and release
attributes. If you have thousands of IDPs in your network, it becomes hard to rollout
new websites… as each IDP would have to update their configuration to add SSO.
Sometimes this is desirable… especially if there is little trust in the federation to
manage content. However, if the federation is trusted, using a proxy to connect to
certain websites can enable people to access new content without their home identity
provider having to do any incremental work.
Rules
Charter
This document provides the governance for the federation including the policies,
rules, and financial arrangements.
Participation Agreement
This document is signed by the identity providers and relying parties. In some cases,
an organization may be both..

6. It also details the policies and procedures. Furthermore the Participation agreement
defines the level of assurance of the authentication provided by identity providers, and
the level of protection for personal data afforded by the relying parties. It can also be a
good place to provide guidelines for security incident handling, threat data sharing,
and other inter-domain security processes.
User Banner – Consent
Somewhere the person using the federated credentials has to agree to the rules. The
best place to do this is at authentication time, so the person knows what he is getting
into when he uses the federated credentials to access websites and mobile
applications.
Steering Committee
Like any collaborative organization, you need to find the people who can help drive
adoption in their respective communities. The steering committee should help with the
formation of the Charter, provide feedback on the agreements, lead the integrations of
the federation in their home organizations, and have a desire to evangelize the
benefits of cooperation to industry peers.

7. Communication Plan
This is “marketing” for the federation. The federation may want to produce white
papers, webinars, case studies, posters, conferences, regional training sessions,
newsletters and other activities to get the word out about the federation. The
communication plan should be a long term plan to both keep participants up-to-date,
and to recruit new
participants from the ecosystem.
It sounds like a long to-do list, but like any journey, the hardest part is the first step. If
you want some help along the way, you may want to schedule a meeting with Gluu.
We are helping to catalyze several federations around the globe.
Article Resource:-http://thegluuserver.blogspot.in/2014/01/go-west-youngfederation.html