SAML, Liberty offer identity gains

Security Assertion Markup Language and Liberty Alliance specifications for federated identity are in early adoption and offer advantages to large organizations.

Creating a single-sign-on (SSO) environment for the Web is painful without federated identity because many applications have their own concept of a "session." In practice, this means that in addition to a security portal's encrypted SSO cookie, applications deposit their own cookies on users' desktops. Strange or unpredictable behavior can result when cookies have different time-out periods, or when users log on from within an application rather than at the portal level.

These and other integration problems can reduce reliability, especially as a corporation increases the number of interconnections it supports with external sites, users and applications. Moreover, when you're trying to extend SSO across external Web applications through traditional means, many interconnections require customization - extra code, proxy accounts or even proxy machines - to implement.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Security Assertion Markup Language and Liberty Alliance specifications for federated identity are in early adoption and offer advantages to large organizations.

Creating a single-sign-on (SSO) environment for the Web is painful without federated identity because many applications have their own concept of a "session." In practice, this means that in addition to a security portal's encrypted SSO cookie, applications deposit their own cookies on users' desktops. Strange or unpredictable behavior can result when cookies have different time-out periods, or when users log on from within an application rather than at the portal level.

These and other integration problems can reduce reliability, especially as a corporation increases the number of interconnections it supports with external sites, users and applications. Moreover, when you're trying to extend SSO across external Web applications through traditional means, many interconnections require customization - extra code, proxy accounts or even proxy machines - to implement.

By leaving behind complex application security integration schemes in favor of the loosely coupled, disconnected session security that SAML offers, corporations will find it is easier to create reliable processes and transactions that cross multiple Web sites.

Companies also can reduce other identity-management challenges, such as help desk calls for password reset. Particularly in the case of business-to-business interactions, corporations can accept SAML authentication assertions from their trading partner instead of maintaining accounts for external users.

Alternatively, as vendors demonstrated in 21 Liberty Alliance implementations at the RSA Security Conference in April, it's possible to link user accounts or profiles across multiple sites using Liberty's "opaque identifier" and getting users' permission ahead of time. In many cases, only one of many sites needs to act as the identity provider (IDP) and maintain passwords for users. In other cases, users log on to any site acting as an IDP and still experience federated SSO's convenience.

Some project managers already have interconnected multiple sites or applications to their federated identity environments, but others report difficulty getting buy-in from business application owners or external partners. Generally, "800-pound gorilla" corporations at the center of their own trading hubs aren't having too much trouble getting partners for federated identity. Otherwise, your results will vary.

It might make sense to start your journey toward federated identity by using SAML or Liberty as a way to integrate some in-house or business-to-employee applications initially. Consider making SAML a mandatory capability for new applications and security infrastructure rollouts. From a policy perspective, prepare for breaches on either side of your federation by adding procedures for cooperative risk management and dispute resolution to business agreements or service-level agreements. Consider providing technical and business documentation for newbies to review. And be careful to set the right expectations for progress based on your position in the industry ecosystem and your internal IT environment.