Federated Identity Through the Eyes of the Deployer

Why deploy federated identity? To date, it's mostly been used for
cross-domain single sign-on (SSO) to save user time and hassle and to
eliminate costly password resets. To protect the identity and
application data being passed around, IdPs and SPs typically establish
a circle of trust with technical and business agreements that define
their respective responsibilities. Often, a circle of trust assumes a
star-shaped topology with a single IdP and many SP spokes that trust
the IdP but not necessarily each other. The IdP role is more complex
because it must furnish the authentication infrastructure along with
most of the security measures. SPs, looking to simplify by outsourcing
to the IdP, expect to be offered toolkits that ease deployment. The
choice of federated identity protocol determines the language in which
the parties communicate -- the forms and meaning of the messages.
(1) SAML: The most comprehensive and widely deployed protocol is the
Security Assertion Markup Language (SAML), currently at version 2.0.
The SAML 2.0 design resulted from a merging of the SAML 1.1 capabilities,
the SAML-based Shibboleth protocol that's in use in higher education,
and the Liberty Alliance protocols known as the Identity Federation
Framework (ID-FF). You might have come across some of those older
protocols, which are still in active deployment. They represent unique
languages because their syntaxes are mutually incompatible. (2)
WS-Federation: A somewhat similar protocol that was developed
independently is WS-Federation. The Microsoft genesis makes it most
often chosen for IdPs and SPs that share a Microsoft-based identity
and Web services platform. Microsoft's InfoCard protocol, which governs
its Windows CardSpace implementation, offers a phishing-resistant means
of Web authentication and attribute sharing that meshes well with the
concept of SSO. To adopt the CardSpace paradigm, you must ensure that a
special agent, called an identity selector, is deployed on your users'
client systems. (3) OpenID: This protocol focuses on simplicity and
ease of SP deployment, particularly for Web 2.0 sites. OpenID presumes
a total lack of trust -- anyone can create an OpenID identifier (a URI)
and host an IdP. SPs that choose to accept OpenID logins do so without
setting up trust relationships with IdPs in advance. Such a setup avoids
burdening the process of rolling out an SP but limits your options in
terms of partner trustworthiness and system security. (4) Sun Solutions:
To help deployers who need multiple protocols or flexibility, Sun Java
System Access Manager and its open-source twin OpenSSO have become
polyglots. They work with SAML, ID-FF, and WS-Federation, but OpenSSO
also offers an extension for OpenID; support for the InfoCard protocol
through an extension is in the works.