Identity Federation – 10 Best Practices from a User’s perspective

Federation is a concept which deals with connection of two parties/providers (Identity Provider (IDP) and Service Provider (SP)). One vetting the credentials of the user and the other providing a service to the user depending upon the successful vetting of the credential by the first provider.  While setting up these federations, certain best practices can be followed by the two parties that would make the federation experience holistic for a user. This blog post explores and highlights these practices.

Let us start with the SP side, as this is where the user lands after a federation. The following are some of the best practices to be followed on the SP side.

  1. If the user has reached the SP for the first ever time, it will be good to make sure (with the consent of the user and with due thought to the user’s privacy), if some identifying information/data (like the immutable id, email id, etc.) of the user can be stored in the SP. This allows the user’s subsequent visits to be tied to it. This may be needed in order to ensure that the user gets a better service experience at the SP each time.  If the intention of the federation is not to expose/tailor user/usage specific sites, then this need not be followed.
  2. The SP should be able to link the user to multiple applications protected by the SP, with the identifying information from the federated transaction, preferably immediately after federation time, in order to establish continuity of services that the particular user was offered last time they logged in to the SP applications and/or tailor the application’s preferences to the federated user’s profile.
  3. Wherever possible it will be better to use local provisioning or remote provisioning of the user at the SP. Critical aspects like security, privacy organization’s policy in handling external users and their attributes dictate which type of provisioning would be best.    This provisioning process again would help speed up the user experience at the SP application and also will assist in giving a better service to the same returning user.
  4. Sending the right assertion parameters to the downstream application.

This is critical, as some of the vital information such as role information, auxiliary user attributes, preferences that the application requires need to be passed on appropriately to the application.  The application might be making important decisions based on these parameters in order to address the user’s needs correctly.

  1. Redirect to appropriate URLs at the Service Provider in both the cases of “User Success” or “User Failure” to get to those URLs. Failure could be because of the following reasons:

a) User not having the right role, privilege or permission to access the site or part of the site, as the assertion did not have them

b) User got authenticated correctly at the IDP, but IDP failed to send the right assertion to the SP

c) Failure of user disambiguation process at the SP

d) User unable to be linked to the right accounts at the SP

In each case, if the Failure URL gives an appropriate error message to the user, the user would know exactly why he could not access the resource. Ticketing software would probably help the user generate a ticket for the same and get a solution for the failed transaction from the SP.

Let us now focus on the IDP side, as this is where the user usually authenticates in order to reach an SP application in a federation.   The following are some of the best practices to be followed on the IDP side:

  1. Most important thing is for the IDP to display an error that is meaningful to the user, if and when his/her authentication fails at the IDP. This would make it easier for the user to know if it was any credential issue, network issue, domain issue or some other issue that made the authentication process fail.
  2. The IDP should mention to the user (either in their website or application) what the supported types of credentials allowed for authentication are. This could vary from userid/password to X509 Certificates, smartcards, OTPs or other hardware/software tokens.   The user interface should appropriately lead the user to the right type of authentication, using the right type of credentials, depending on the type of service he/she wishes to get from the IDP.
  3. The IDP would be able to issue assertions to the SP, that contains details like Level of assurance at which the user credential was accepted, other user attributes like role, user preferences etc., if applicable. This is other than the primary subject information that the IDP is contracted to send to the SP, during the initial metadata exchange.  These extra attributes would help the SP and its applications to tailor their user preferences.
  1. In the case of IDP supporting a particular profile and service, the IDP should support all the possible standard options/features linked with these profiles/services. Otherwise the users should be let known, what is supported.  This is to ensure that the sure users would not be misled, if they assume that all related option/features are supported.  For example:

a) If the IDP is supporting IDP-initiated Browser Post Profile, then it would be better if it supports IDP initiated Single Logout, Common Name ID Formats linked with the Browser Post Profile, Signing and Encryption of Assertions, Protocol Response in POST Formats etc.

b) if the IDP is supporting SP-initiated Browser Post Profile, then it would be better if it supports IDP or SP initiated Single Logout, Common NameID Formats, Signing and Encryption of Assertions, Protocol Response in POST Formats, Relay State, Accept AuthenRequest in GET and POST Formats, support “allow create” of new IDs if an ID is not already present for a federation transaction etc.

c) if the IDP is supporting multiple Protocols and features such as delegated authentication, redirection to other IDPs, etc., it should clearly mention the protocols and the corresponding profiles, features supported in each of the IDP supported website/application.

d) If exclusively a particular feature is not followed or supported by the IDP, it should be clearly mentioned by the IDP to its users.

All the above should be provided in laymen terms, so that the user can understand what features are supported and what are not.

  1. IDP should clearly mention the conditions associated with privacy clause/rules/protection with respect to user credentials/identities and their secure transport. This is to keep the user informed about how their credentials will be used. It also highlights the protection measures followed to make the federated transaction secure.


Author Bio:
Raj Srinivas, the author of this blog is an IAM and Security Architect with 8K Miles.   His passion includes analyzing problems that enterprises have in the IAM & Cloud Security domain, from various verticals that include Banking, Insurance, HealthCare, Government, Finance & Mortgage and provide in-depth solutions that will have far-reaching effects for the enterprise.

451 Research Report: 8KMiles crosses the chasm in cloud-based identity federation

Analyst: Wendy Nather 22 Nov, 2013

Original Report URL from 451 Research website :

Full Report is published down…

8KMiles has been heavily invested in cloud integration. As one of Amazon Web Services’ Premier Consulting Partners for 2013, it has helped customers stand up everything from Amazon’s Elastic Block Store to its S3 and Relational Database services. So it made sense to continue to add cloud integration services in the identity and access management (IAM) space. To this end, the company acquired Sunnyvale, California-based FuGen Solutions in May to obtain its Cloud Identity Broker and Multi-Domain Identity Services Platform.

The 451 Take
A combination of design and operations support helps 8KMiles, and its subsidiary FuGen makes on-ramping of federated identity partners easier, particularly for enterprises that don’t have the infrastructure or expertise to figure it out themselves. A migration opportunity can become a hosting opportunity, while a hosting opportunity could turn into the kind of identity and attribute exchange that is still needed. Other efforts are underway to build such an exchange, but 8KMiles and FuGen could get out ahead of it – although it might help if they settled on one company name to promote the unity they’re offering.

Did identity federation get any easier when the execution venue moved from legacy systems to the cloud? Actually, that’s a trick question, because most of it hasn’t moved – it’s just been stretched. Even without the dynamism and scale requirements of the cloud, an enterprise’s federation efforts with its partners suffer from complexity that many organizations aren’t equipped to handle.
There are many types of federation, and only some of them are binary: that is, one organization completely trusts the other one, so that it accepts any identity offered. A common example is federation between a health insurance provider and a partner that provides pharmacy benefits: there can be a
one-to-one acceptance because it’s the same business case (benefits for an insured client) and the same level of security risk. Because it’s the same business case, both sides can validate the user in the same way and no additional validation is needed. A user can be passed through single sign-on from one site to another in a fairly seamless fashion.

However, not all federation is binary. Take the example of a state education agency: it has thousands of school district employees that need to use the agency’s applications. The agency would like to have the districts set up access for those users, but it is still legally on the hook to approve every access. This means that the agency has to rely on some assertions by the district, but must take an additional step of its own for validation and approval before it can fully accept that user into its systems. These validation workflows often use attributes of the user’s identity: whether the user is an employee of the district (which only the district is authoritative about), which roles the user is assigned (which might be determined by the agency), or whether the user is also a member of a different organization (such as working for a second district).

Attributes may sound complicated, and the business rules behind them can be. But an attribute is really the reason why you’re allowing access to that user. You’re allowing access because the insurance provider says this is a registered subscriber; you’re allowing it because the Department of Motor Vehicles (DMV) asserts that this is a licensed driver; you’re allowing it because the user is a registered PayPal customer. And you can only rely on that attribute when it comes from the right authoritative party: only PayPal can say with certainty who its current customers are.

The ecosystem of attributes has yet to be addressed in a coherent way. Many websites and applications will be happy to accept the credentials of a Facebook user, because they only care that someone at Facebook (presumably) validated the user account. That’s all the validation they need. But that’s not enough for many other organizations, especially where legal and regulatory issues are on the line. But if you could get all these authoritative parties in one place…

This is where 8KMiles and FuGen come in.
Founded in 2007, 8KMiles is led by Suresh Venkatachari, its chairman and CEO, who also founded consulting firm SolutionNET. The company has 140 employees among its locations in California, Virginia, Canada and India. In May, 8KMiles acquired FuGen Solutions for $7.5m, with the target becoming a subsidiary.

Products and services
8KMiles offers both consulting services (cloud migration, engineering and application development) and frameworks for assembling secure cloud systems. The company provides a turnkey architecture for implementing a secure private cloud, including firewall and DDoS protection services, secure remote access, system administrator access and monitoring, and disk encryption. This can be deployed either as an Amazon virtual private cloud or in an organization’s own datacenter. 8KMiles similarly offers a secure enterprise collaboration implementation that combines Alfresco’s content management and Amazon’s RDS. An AWS Direct Connect package contains both design and management of the network, points of
presence, and security.

When 8KMiles bought FuGen, it obtained both a cloud identity brokerage and the target’s Multi-Domain Identity Services Platform (MISP). The platform supports the partner onboarding and federation management activities, as well as what the vendor calls last-mile single-sign-on integration to a centralized hub for smaller customers that don’t have legacy IAM systems to connect, or who don’t have the expertise to put everything together. The platform is vendor-agnostic in that it can be used with any IAM provider’s systems to connect and federate partners. The authentication protocols supported include SAML 1.1, SAML 2.0, WS-Federation, WS-Trust, OpenID and OAuth. MISP comes with rules-based validation and reporting, criteria certification, monitoring and logging, and storage of scenarios, data messages, templates and certification reports.

One of the strengths of the broker and platform offerings is that FuGen and 8KMiles staff can duplicate the customer’s complex federation requirements in their virtualized environment. The vendor can build the hub and test all of the integrations with the partners’ systems in a lab setting. Once it’s been assembled and shown to work properly, the company can walk the customer through implementing the working version on its own systems, providing instructions down to the level of the configuration file changes. In cases where the customer does not have specialized IAM expertise or a test network, FuGen can provide both.

These services are available for community providers, SaaS application firms, identity and attribute vendors, and many others. FuGen’s customers range from one of the largest financial services institutions to media providers, large IT suppliers and defense contractors (Amazon AWS customers use FuGen’s federated identity features).

The idea of creating a vendor-agnostic federation space is a good one – as the number of partners grows with which FuGen has already built integrations, the onboarding for future customers goes more quickly. For example, if FuGen has already done the hard work of figuring out connectors for a large payment provider that happens to use Oracle for an IAM system and Ping Identity for cloud-based SSO, then any other partners that want to federate with that large payment provider using the same products will have most of the work already done. The network effect comes into play here: the more partners FuGen integrates, the stronger its offerings grow as a cloud-based ID federation service.

For the reasons described above, many enterprises end up relying on a varied set of IDs and attributes, all coming from different partners. Building a central ID and attribute exchange could speed federation projects for government, healthcare, finance and other verticals if FuGen can pre-integrate those providers. When businesses can join a virtual marketplace where they can get the attributes they need from their state DMV, PayPal and business process outsourcer, and all of the integration work is done for them, then the community has a good chance of growth. Many identity and attribute exchange projects are already underway (and FuGen is already part of some of these open initiatives) – the one advantage is that the company helps facilitate the plumbing, not just the framework. Also, this isn’t just about the cloud: enterprises can still federate with one another using their own systems, with FuGen’s services to set it up. The one hitch is that this is a potential that hasn’t been fully realized. 8KMiles and FuGen would have to figure out how to charge for this service, since charging by ID or partner account might be too dynamic to support a licensing structure. (This isn’t to say that a cloud provider can’t charge dynamically, it’s just that determining how many IDs are in use at any given time is a tricky proposition.) The vendor could charge an onboarding project fee, but services after that – such as monitoring, support, troubleshooting and integration tweaks – would need a different incremental pricing structure. If a large provider is hooked into the hub, and new partners join it, does the provider get charged more, or just the new partners? Identity and attribute management are both still developing areas of technology, and with the cloud as a delivery method, many aspects have to be reconsidered.

The term ‘identity broker’ is unintentionally confusing, since it is most often used to describe technology that helps intermediate an enterprise’s portfolio of ID stores and services, usually to provide single sign-on for that enterprise’s users or its customers. This is not the same as a third-party identity exchange, such as the kind envisioned by the Identity Ecosystem Steering Group (whose website, incidentally, is powered by Ping). There is also a lot of discussion in the IAM community about who can and should act as identity providers, and the candidates include social media such as Facebook or Google, financial institutions and telcos, since all of these appear to have the largest user bases.

However, none of these identity providers in and of themselves can supply all of the assurance and validation that different business cases require. It doesn’t matter whether Verizon has verified a user for phone service if a relying party has to figure out whether the user is really the same one who walked into the emergency room last night. Some organizations have much stronger requirements for identity assurance, and will have to assemble their own validation lists from multiple ID providers.

Not only does the ID and attribute exchange need to be vendor-agnostic, it also needs to be easy to join. This is where the pre-integration and onboarding services are crucial. Customers don’t have to let FuGen host the hub, but it helps with the kind of complex troubleshooting that federated IAM can sometimes require. The opportunity for FuGen is that it can be a broker for the brokers, so to speak: each enterprise in an ideal world would have just one interface to expose to the world, but those interfaces still need to be matched up with the other ones.

The term ‘broker’ is confusing, but if we focus on ‘exchange,’ we get closer to our original meaning and can consider the competition. SecureKey Technologies was recently awarded a contract by the US Postal Service to create the Federal Cloud Credential Exchange. Criterion Systems was one of the National Strategy for Trusted Identities in Cyberspace pilot grant recipients in 2012, and is building its ID DataWeb Attribute Exchange Network, with an ecosystem of technology partners and relying parties such as Ping, CA Technologies, Fixmo, Verizon, Experian and Wave Systems. If firms like these manage to build a working exchange, it could rival what 8KMiles and FuGen can do. Again, the latter are helping customers set up the integration, not just acting as a provider, so the operational features of their offering set it apart from these exchange projects. The race will be to see who can collect the largest amount of trusted resources and participants in a broadly working exchange. Vendor neutrality and open standards will play a role, but so will user-friendliness. If FuGen can offer both the onramp services and the day-to-day operation in a way that preserves trust, it could have the magic formula.

SWOT Analysis

As a cloud broker, 8KMiles expanded its repertoire with the acquisition of FuGen. Identity management is certainly a key part of cloud migration and operation, and FuGen’s virtualized lab environment helps it work out all of the bugs in a complex identity federation system without impacting the customer.

FuGen may be known in the IAM industry, particularly due to its participation in public initiatives, but customers may find the name too confusing alongside 8KMiles (neither name really says what the company does). It also has a lot of potential in supporting an identity and attribute exchange, but that potential needs to be realized.

Nobody has really figured out federation yet. Even though some straightforward, homogeneous business use cases are working fine, the more complicated ecosystems are still in the committee/framework/pilot stages. If 8KMiles/FuGen can onramp enough critical-mass partners, it could become a de facto hub before these committees can turn around.

Vendors such as SecureKey and Criterion are building exchanges too, although they’re in the early stages.
8KMiles/FuGen will also be confused with many other cloud IAM technology vendors due to the misuse of the term broker.

Analyst(s): Wendy Nather , 451 Research