Download
1 / 7
70 likes | 266 Views
But starting your federation is easier said than done. This is why some governments are jumping in to help.
E N D
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. Go West Young Federation
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: EdugateJagger (used by Gluu) and AAF Federation Registry.
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’sinterop 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 • OpenIDConnect 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.
“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.
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..
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.
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-young-federation.html
