Introduction to Liberty Alliance and Their Objectives


The Liberty Alliance Project [Liberty] was formed in September 2001 to develop open standards for federated network identity management and identity-based services. Compared to W3C and OASIS, the Liberty Alliance has many industry participants (instead of many technology vendors), including American Express, Ericsson, Fidelity Investments, France Telecom, GM, HP, Intel, Nokia, Novell, NTT DoCoMo, Sony, Sun Microsystems, VeriSign, and Vodafone as management board members.

The business objective of Liberty Alliance is to address the management of network identity and federated network identity. According to [Liberty12FFArch], Liberty Alliance intends to enable consumers to protect the privacy and security of their network identity information and enable businesses to maintain their customer relationships without third-party participation. This requires the creation of a network identity infrastructure that supports all current and emerging network access devices and provides an open single sign-on standard to decentralize authentication and authorization from multiple service providers.

From this perspective, the scope of Liberty is different than the scope of SAML. Liberty's focus is on the identity provider for the authentication of federated network identity and the creation of network identity infrastructure. Liberty Phase 1's protocol extends SAML 1.1's protocol and provides support for a wide range of authentication methods associated with the identity provider and support of global logout protocol, which were out of scope in SAML 1.1. There has been some significant development in both Liberty and SAML since then. SAML is now under OASIS's governance. Liberty Alliance has recently contributed its Liberty Phase 2 to SAML 2.0, and Liberty will continue its work in developing its community network, the Liberty Web services framework (LD-WSF), and the useful starter service interfaces (LD-SIS). The scope of Liberty Phase 2 specifications are presented in detail at http://www.projectliberty.org/specs/index.html. [Liberty12Tutorial] provides a comprehensive tutorial for Phase 2 specifications.

Liberty introduces the following system entities in the Liberty specifications:

  • Principal: An entity (for example, a user) that acquires a federated identity and makes decisions to which authenticated actions are done on its behalf.

  • Identity Provider: A Liberty-enabled entity that creates, maintains, and manages identity information for principals and can authenticate principals for other service providers within a circle of trust.

  • Service Provider: An entity that provides business services and/or goods to principals.

  • Circle of Trust: A federation of service providers that have business relationships based on Liberty architecture and operational requirements. Within the circle of trust, users can transact business in a secure and seamless environment, say, using single sign-on.

  • Liberty-enabled Client: A client who knows how to obtain knowledge about the identity provider that the principal wishes to use with the service provider.

  • Liberty-enabled Proxy: An HTTP proxy that emulates a Liberty-enabled client.

Liberty Phase 1

Liberty Phase 1 introduced identity federation, which provides single sign-on and global sign-out to multiple application systems and infrastructures. This involves creating an identity-provider role that initiates federation of two or more identities. Using the Liberty protocol, users are able to sign on once to a Liberty-enabled Web site and be seamlessly signed on to another Liberty-enabled Web site without needing to reauthenticate.

In essence, Liberty Phase 1 delivers the Identity Federated Framework (ID-FF) version 1.1, which includes the following features:

  • Federated identity life cycle: The lifecycle of identity federation begins with exchanging meta-data to federate an identity. A principal (for example, a user who can acquire a federated identity) can then perform a single sign-on to one or multiple Liberty-enabled Web sites. During the process of single sign-on, the federated identity needs to be registered (using the name registration protocol). Upon completion of user activity, the principal will perform a global logout and the federated identity will be terminated.

  • Meta-data: The Liberty meta-data provides an extensible framework for describing cryptographic keys, service end-point information, and support protocols and profiles at run-time. The meta-data classes include entity provider, entity affiliation, and entity trust. The origin and the document that contain these meta-data will be verified using digital signatures.

  • Static conformance requirements: The static conformance requirements define profiles for identity federation activities: identity provider, service provider basic, service provider complete, and Liberty-enabled Client or Proxy.

  • Interoperability conformance and validation: There is a validation process for a vendor who wants to be licensed as Liberty-interoperable, where the vendor needs to participate in the Liberty Alliance Interop event to validate such a compliance assertion.

  • Security mechanisms: Liberty's identity federated framework supports both channel security and message security. Channel security allows the service provider to authenticate the identity provider using server-side certificates. It also supports mutual authorization between the service providers and identity providers. Message security uses digital signatures for protecting the Liberty messages for data integrity and non-repudiation.

Liberty Phase 2

Liberty Phase 2 is a major enhancement to Phase 1. It delivers the following specifications:

  • Identity Federated Framework (ID-FF) version 1.2. The ID-FF establishes identity federation under a circle of trust and supports single sign-on. Identity federation refers to linking all user accounts for the same user entity among different service providers and identity providers. Single sign-on denotes enabling a user to authenticate with the identity provider once in order to access remote services provided by multiple service providers under a circle of trust. The identity provider provides decentralized authentication of the user identity. The features of ID-FF include opt-in account linking, simplified sign-on, basic session management, user affiliation with Web sites, anonymity of user identities, and real-time discovery and exchange of meta-data.

  • Identity Service Interface Specification (ID-SIS) version 1.0. The ID-SIS includes two profiles: personal identity and business identity. These profiles define important user attributes for exchanging identity information among service providers and identity providers on top of ID-WSF.

  • Identity Web Services Framework (ID-WSF) version 1.0. The ID-WSF defines a framework to create, discover, or consume identity services. This includes permission-based attribute sharing, identity service discovery, interaction service, security profiles for securing the discovery, SOAP protocol binding for ID-FF, extended client support for non-HTTP devices, and identity service templates to implement identity services on top of ID-WSF.

It is important to understand the roles of Liberty and SAML in the identity management space. Liberty Phase 2 is primarily based on SAML version 2.0, and builds an extension on top of it. The additions in Phase 2 are ID-FF, ID-SIS, and ID-WSF. Liberty is not competing with SAML. SAML provides single sign-on and identity management specifications, and it does not provide custom profiles for specific scenarios or industry use. Security architects and developers have to build their own implementation and customize the profiles on top of SAML specifications. Another goal of Liberty Alliance is to share best practices of identity management, data privacy, and interoperability within the Liberty Alliance compliant products.

The number of commercial Liberty-enabled identity management products is growing. A full list of Liberty-enabled products is available at http://www.projectliberty.org/resources/enabled.html.




Core Security Patterns. Best Practices and Strategies for J2EE, Web Services, and Identity Management
Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management
ISBN: 0131463071
EAN: 2147483647
Year: 2005
Pages: 204

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net