Financial institutions seeking to increase the breadth of their service offerings are increasingly turning to third-party services. But since these services are not tied in to those of the financial institution, inconsistent interfaces and multiple logins cause the user experience to suffer. Federation offers one way to streamline this process by allowing users to move between environments without being required to manage multiple identities, allowing single sign-on (SSO) across those applications.
There are a number of federation frameworks, such as Security Assertion Markup Language (SAML), OpenID and Microsoft's CardSpace. Lumping these frameworks together is like mixing apples and oranges.
Orange you glad the user is in control?
OpenID and CardSpace are similar in that they employ a user-centric identity management model. In other words, they put the user in control of his or her identity and the decision to extend an identity to other participating systems. They also support multiple identities per user. CardSpace allows users to create separate identities associated with work, freelance business, leisure or other. This model is analogous to presenting your identification badge at work, your driver's license to a store clerk and your passport at the airport. Likewise, when the user goes to a CardSpace enabled site, the user is able to choose which identity card to associate with the new site. This allows for certain levels of risk management as well -- the user can create identities that are only used for sites they don't trust. The OpenID and CardSpace models give the user control over how their identity is managed.
An identity crisis
However, financial institutions want and need to exercise strict, centralized control of their user accounts. Financial firms need to be the authoritative source for the identity. Since CardSpace and OpenID rely on the user to choose an appropriate identity, they are not (at this time) a feasible choice for financial institutions. Moreover, the identity information is housed by third parties. Financial institutions need to be the identity provider, and then allow their customers to utilize that trusted identity to leverage partner services -- partner services explicitly enabled by the relationship with the financial institution.
Centralized control of identity federation -- the apple of the corporate eye
The difference is that OpenID and CardSpace are frameworks that can allow users to extend their identities to other sites, whereas WS-Federation (Microsoft/IBM), SAML (OASIS), and IDEF (Liberty Alliance) are protocols that can enable companies (identity providers) to federate their internally housed identities with selected business partners (service providers). But, to muddy the waters a bit more, any of the above protocols could be utilized in the OpenID and CardSpace models. For instance, CardSpace uses WS-* protocols and OpenID can use SAML.
The most important factor when using any of these protocols is the prearranged agreement between business entities and the toolsets used to send and receive the protocol assertions. The identity provider and the service provider must agree on the common protocol to be used (either WS-*, SAML or IDEF), the attributes to be passed, levels of access, provisioning/de-provisioning rules, etc. They do not need to use the same toolsets, but the technologies on both sides of the federated relationship need to be able to understand each other.
For now, CardSpace and OpenID are great for low-risk sites (e.g. blogs, Webmail). But if a financial institution wants to exercise control over customer identities and have greater assurance that a customer is legitimate, more controlled federation models should be used. Of the three major protocol families associated with federation, SAML seems to be rising as the de facto standard for enterprise controlled federation.
About the author:
Perry Carpenter has spent nearly a decade working in IT and information security. Currently serving as the information security manager for a large wireless carrier, he has expertise in identity management, application security and data encryption and privacy. Earlier in his career he specialized in application development and Active Directory implementations. He maintains a security resource website at SecurityRenaissance.com.
This was first published in July 2008