Shared identities

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.There are several benefits to implementing federated identity management. 'Chief among those that have driven deployments is the cost of maintaining identities for service providers," said Andras Cser of Forrester research. 'With federation, only one party needs to maintain the users' identities.'Moreover, security can be improved by authenticating and authorizing users in a single operation and then using their identity attributes to determine which applications or services they can access.Privacy can also be addressed because the information shared can be controlled or limited.For the user, life gets easier because in a federated environment, they must remember only a single password.Adoption of federated identity management is expected to increase dramatically this year and next as organizations attempt to improve communication with business partners, enhance customer service, better integrate outsourced services, and adopt more open, standards- based technologies. Cser said he expects market adoption to double by 2009.However, some challenges remain before adoption can go mainstream ' and they're not only technical. People, process and risk issues must be addressed during any federated identity implementation, said Gregg Kreizman, research director of Secure Business Enablement at Gartner Group. These agreements lay out the fundamental expectations for all parties and include elements such as:'Establishing such an agreement has typically been the most difficult part of establishing a federation,' Kreizman said. Therefore, one of the most important items on your federated identity management checklist should be establishing a formal governance plan with all cross-domain partners.Carolyn Ford, product manager for Identity and Access Management Solutions at Novell, said she also sees some technical hurdles. 'There needs to be standardization on identity policies and procedures to ensure consistency through the organization,' she said. 'Organizations also need to implement an external auditing and monitoring system to validate and prove those systems were properly implemented and effective.'At a high level, a user or service logs in to an identity provider (IdP) ' usually in the user's local domain. The user or service then requests access to an application or a service. If that request is in the local domain and the user is authorized to access it, the IdP grants access.On the other hand, if the request is for an application or service in another domain, the IdP redirects the request along with an assertion containing the federated identity information.A session cookie could be used to complete this process. Moreover, this data handling is usually conducted across an encrypted connection.After the provider of the application or service receives the request and the assertion, the assertion is read. If the user is authorized, the provider grants access to the requested resource. All this is transparent to the user.Underlying federated identity-management solutions use open standards. You may also hear these standards called specifications, frameworks or personal information frameworks (PIFs). These open standards define the rules, protocols and references needed to support interoperability between identity management infrastructures.The first federation standard, OASIS' Security Assertion Markup Language (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.Novell's Access Manager supports major federation standards such as SAML, Liberty Alliance and WS-Security, and it takes a policy-based approach to federation. Novell's solution includes out-of-the-box privacy and security measures to guarantee confidentiality.It also eases integration of federation with older applications and existing directory and identity management systems. The solution runs on SUSE Linux Enterprise Server.The concept of federated identity is fairly broad and evolving. It is a generic reference and not tied to a single protocol, implementation or company. The term does describe how an organization can achieve identity portability through the use of open standards to address cross-domain security concerns.