Government Computer News discusses how a federated approach makes identity management portable: Overlapping identity management systems can be as much of a pain to users — and ultimately to systems administrators — as multiple passwords. Agencies that maintain multiple user repositories or whose processes cross more than one security domain should consider implementing federated identity management to reduce administrative overhead and costs while increasing security and simplifying the user’s experience. The primary objective of federated identity management is to give authorized users the ability to securely access applications or services both in their own organization and in other domains without the need for redundant user administration in all the domains involved.

The need is obvious; with the increased integration of Internet-related technologies into business processes, users often need to cross domains to access external systems. Likewise, external users often need to access internal systems.

Imagine federal, state and local first responders being able to access all levels of resources with a single sign-on. A federated identity management system can handle that type of responsibility without sacrificing security.

Cross-domain challenges

The first federation standard, OASIS’ SAML is an Extensible Markup Language-based mechanism that supports the exchange of authentication and authorization information between multiple security domains. It developed in response to the challenges of addressing cross-domain single sign-on (SSO) functions.

On the heels of the initial SAML specification, the Liberty Alliance developed the Liberty Federation Framework (ID-FF) that added new functionality, such as account linking and introductions.

At the same time, the people involved with Internet2 created an open-source standard called Shibboleth, based on SAML 1.1 and used primarily in higher education to support SSO and the exchange of user attributes.

Another specification — the WS-Federation Standard — emerged to address federated identity, authentication and authorization standards in service-oriented architectures (SOA). Contributors to this effort include BEA Systems, BMC Software, CA, IBM, Layer 7 Technologies, Microsoft, Novell and VeriSign.

More recently, OASIS issued the SAML 2.0 specification, which blends functionality from SAML Version 1.1 and the Liberty ID-FF and Shibboleth specifications.

The IBM Tivoli Federated Identity Manager interoperates with the SAML, Liberty, WS-Federation, WS-Secure and WS-Trust standards. It provides policy-based federation for organizations that are deploying SOAs or Web services. In addition, it provides a mechanism to integrate a simplified security approach between distributed applications and services and older mainframe applications.

The IBM solution is supported on AIX, HP-UX, Linux, Windows and z/OS.

Oracle’s Identity Federation solution supports the SAML specification along with the Liberty ID-FF and WS-Federation standards.

It can integrate with existing identity and access management solutions, which can reduce implementation times and costs. To address performance and disaster recovery, Oracle Identity Federation includes support for load balancing and failover. It is supported on Red Hat Linux and Windows.

The Java System Federation Manager from Sun Microsystems embraces not only the SAML and Liberty ID-FF specifications but also the Liberty ID-WSF (Web Services Framework). Like IBM, Sun takes a policy-based approach to federation, and its solution includes policy agents for a number of technologies, such as directory, Web and application servers. This solution runs on Solaris, Red Hat Linux and Windows.

Read the complete article by Maggie Biggs at GCN.