Network Identity management and Liberty Alliance Project (LAP)
Overview by Yuri Demchenko
NLnet Labs <demch@chello.nl>
Liberty Alliance specifications page
http://www.projectliberty.org/specs/main.html
Synopsis:
There is an expectation that Identity management framework developed by LAP can provide a good basis for related AuthN and Identity management services for related AuthN and Identity management services for OGSA and AAAArch.
1. LAP as a framework for Identity management and Single-Sign-On
3 Liberty Functional requirements
4 Liberty Security Requirements
1. LAP as a framework for Identity management and Single-Sign-On
LAP defines a framework for Identity management and Single-Sign-On (SSO) services. First stage of the LAP is rather business relations oriented, as it is anticipated that business relations are based on confirmed identity of user or other participating entity. LAP enables Identity and SSO services for existing (pre-defined) business and trust relations between Service Providers (SP) and Identity Providers (IP). Next stage will extend them to cross-domain and dynamic virtual associations.
Liberty adds three refinements to a general single sign-on mechanism:
1) Liberty introduces a special circle-of-trust member – an Identity Provider whose responsibility is user authentication. Liberty specifies the relationship and communication patterns among the identity providers, the service providers, and the user.
2) Liberty ensures that a user has complete control over his/her identity information—any manipulation of a user's identity data requires prior user consent (which is recommended to be conveyed via webform request).
3) Liberty relies on SAML (Secure Assertion Markup Language), to exchange authentication information between service and identity providers.
Although Liberty separates the identity and service provider roles, in some cases, a service provider may adopt the additional role of the identity provider. However, in general user authentication may be delegated to a dedicated identity provider whose sole focus is user authentication.
Liberty empowers users to make decisions about their online identities, which may scatter across many SP’s and locations. Single sign-on requires some sort of cross referencing, or federating, of user accounts among circle-of-trust members. However, Liberty mandates that a user initiate any sort of federation for his identity information. In other words, once a user initiates account federation between trusting service providers, those providers can trust one another's authentication decisions and thereby offer the convenience of single sign-on. The user is also a member of the circle of trust: not only do service providers have to trust one another, the user also must trust the providers. If a user no longer trusts a service provider, he can annul the identity federations associated with the provider at any time.
The authentication system may also authorize a user to perform certain system actions, perhaps based on that user's access level. That type of authorization information is also associated with an authenticated principal. The complete set of authentication and authorization information, as well as other attributes associated with a principal at the time of authentication, serve as proof of that principal's identity during his interaction with a system; those data items form assertions about the authenticated user.
Described above approach can provide a basis for Agent Systems identity management service, enabling Agents to use/request special identity/authentication service to initiate/invoke and control their identity (at specific location).
Liberty Trust models are described in the document “Liberty Trust models” (draft-lib-tsp-trust-models-v1.0-14.pdf). The document introduces Business Anchor List (BAL) and Trust Anchor List (TAL) of entities between which there are established business or trust relations.
Three basic trust models are described in the document:
1) Pairwise Trust model (basic model
for the Liberty Phase 1)
These models afford strong trust in
a business sense, but have relatively limited scalability. Cryptographic
authentication in the Pairwise/Direct model may be based on pairwise
out-of-band exchange of shared secret keys or public-key certificates, in
conjunction with business/legal agreements.
For the Pairwise/Indirect case, it is possible to authenticate each
other via an infrastructure involving intermediary entities (e.g., PKI CAs).
In the Pairwise Trust models,
relationship and business trust between all interoperating participants is
exclusively governed by signed business agreements. The strong trust
established via business agreements is not technically extendable which results
in the forming of closed communities. A new entity may not interact within such
a community without first entering into a business agreement with the existing
participants and being added to the BAL.
2) Brokered Trust model
Brokered Trust describes the case
where two entities do not have direct business agreements with each other, but
do have agreements with one or more intermediaries so as to enable a business
trust path to be constructed between the entities. The intermediary brokers
operate as active entities, and are invoked dynamically via protocol facilities
when new paths are to be established.
In Liberty’s Brokered Trust model,
active intermediaries are invoked and involved when federation and/or
authentication transactions span multiple administrative domains. This trust
model is beyond Liberty Phase 1.
3) Community Trust model
Community Trust applies when the
business trust between a pair of entities is derived from their enrollment in a
common authentication infrastructure and acceptance of its practices, without
reliance on other business agreement paths. As such, the entities’ mutual trust
in a business sense is based on their membership in a community constructed and
linked for authentication purposes.
Community Trust models presume
neither direct nor indirect business agreement paths between communicating entities.
Instead, they rely on shared membership in a community defined by a
cryptographic trust establishment infrastructure as a basis to enable
communication between entities for purposes of federation and/or
authentication. Public Key Infrastructure (PKI), Kerberos realms and
inter-realm relationships, and PGP webs of trust represent examples of
available trust establishment infrastructures.
3. Liberty Functional requirements
The Liberty architecture and protocols must be specified so that Liberty-enabled implementations are capable of performing the following functions:
· Identity federation
· Identity provider introduction
· Authentication
· Use of pseudonyms and support for anonymity
· Global logout
Requirements of identity federation
stipulate that: service providers and identity providers give the user notice
upon identity federation and defederation; service providers and identity
providers notify each others about user account termination and identity
defederation; and identity providers and service providers are required to give
users information about their federated identities.
Identity providers may introduce one
another to service providers that they trust, so that new trust relationships
may be established in real time. However, in this case it is required to notify
user and other parties about identity federations that take place as a result
of their mediation.
Authentication requirements include
both requirements for user authentication by Identity provider and identity
provider authentication (consent) by user. The following minimum set of
authentication information with regard to a user should be exchanged:
authentication status, instant, method, and pseudonym (which may be temporary
or persistent). Identity provider, at the discretion of the service provider,
may be allowed to authenticate the user via an identity provider other than
itself and relay this information to a service provider.
It must be provision for the
confidentiality, integrity, and authenticity of information exchanged between
identity providers, service providers, and user agents, as well as mutual
authentication of the identities of the identity providers and service
providers, during the authentication and single sign-on processes.
Liberty-enabled implementations must be able to support the use of pseudonyms that are unique on a per-identity-federation basis across all identity providers and service providers.
In respect to anonymity, service provider may request that an identity provider supply a temporary pseudonym that will preserve the anonymity of a Principal/user. This identifier may be used to obtain information for or about the Principal (with his or her permission) via mechanisms that are outside the scope of the Liberty identity federation framework. This may help to avoid requirement for the user to consent to a long-term relationship with the service provider.
4. Liberty Security Requirements
Liberty Security Framework defines mechanisms used for ensuring channel and message security: confidentiality, per-message data integrity, transaction integrity, data origin authentication, nonrepudiation. Channel security is based on TLS/SSL and may use IPSec. Message security is based on XML Security technologies (mostly, XML Signature and XML Encryption).
Liberty defines SAML extension for SSO and federated network identity management. Liberty enriches the basic SAML framework with metadata, schemas, and a set of protocols needed to create and manage federated network identities, and to perform single sign-on. In addition, Liberty also defines a Web redirection mechanism to support existing Web clients, such as current Web browsers.
Liberty protocols rely on
extensions to the SAML request and response messages (saml:RequestAbstractType
-> lib:AuthRequestType and saml:ResponseAbstractType
-> lib:AuthResponseType) to exchange authentication assertions
between identity and service providers. When an identity provider performs
authentication, it issues its assertions in messages using extended lib:AssertionType format and lib:AuthenticationStatementType format.
Information about a subject follows the original format of the SAML SubjectType
element. A Liberty identity federation exists when a service provider trusts
the assertions issued by an identity provider.
Based on SAML's simple request-response pattern, Liberty specifies the following protocols:
1) Single Sign-On and Federation Protocol
The single sign-on and identity federation protocol lets a service
provider obtain an authentication assertion from an identity provider.
Optionally, this protocol also instructs the service provider to start trusting
assertions from an identity provider, that is, to federate the user's identity
at the service provider with that user's identity at the identity provider, if
both parties maintain information about that user's identity.
2) Name registration protocol
The name registration
protocol lets a
service provider register a name for a user with an identity provider. Liberty
does not require a service provider to give any specific information about a
user's local identity when joining a federation. During federation, the identity provider
generates an opaque handle that serves as the initial name identifier that both
the service provider and the identity provider use in referring to the
Principal when communicating with each other. This name identifier is termed
the <IDPProvidedNameIdentifier>.
Subsequent to
federation, the service provider MAY register a different opaque handle with
the identity provider. This opaque handle is termed the <SPProvidedNameIdentifier>. Until the service provider
registers a different name, the identity provider will use <IDPProvidedNameIdentifier>
to refer to the
Principal when communicating with the service provider
3) Federation Termination Notification Protocol
The federation termination protocol notifies both the service and identity
providers to terminate a federation; it tells a service provider to no longer
trust authentication assertions from an identity provider. The protocol uses <FederationTerminationNotification>
message type.
4) Single Logout Protocol
When an identity provider authenticates the user, typically
that identity provider creates a session with the service provider. The single
logout protocol notifies
both the service provider and the identity provider to terminate that session
for a given principal, in effect, logging the principal out. This operation is
conveyed via <LogoutRequest>
message
5)
Introduction Notification Protocol
If a service provider is
successfully introduced to an identity provider through the mediation of an
introducing identity provider; the service provider federates a Principal’s
identity with the provider to whom they have been introduced. The protocol uses
<IntroductionNotification> message type and <IntroductionStatement> element.
6) Provider Relationship Termination Protocol
When a service provider
has previously been successfully introduced to an identity provider through the
mediation of an introducing identity provider, but the business relationship
between the identity providers has subsequently been broken, then the
introducing identity provider SHOULD send a <ProviderRelationshipTerminationRequest>
message to the service provider.
Liberty protocols are based on SOAP messaging framework and may be used in various communication environments, including current-generation Web browsers and Web servers. The communication mechanisms and the protocol messages together form Liberty's protocol profiles. The Liberty specifications define protocol profiles for HTTP POST, browser "artifacts," WML (Wireless Markup Language) POST, and Liberty-enabled Web services (clients) and proxies.
Liberty Identity Federation Framework and protocols are described in the document “Liberty ID-FF Protocols and Schema Specification” (draft-lib-arch-protocols-schema-v1.2-08.pdf). Liberty protocol binding is described in the document “Liberty ID-FF Bindings and Profiles Specification” (draft-lib-arch-bindings-profiles-v1.2-08.pdf).
Interoperability Prototype for Liberty is the first open-source implementation of the Liberty Alliance Version 1.0 specification based on Java technology (http://wwws.sun.com/software/sunone/identity/ipl/). IPL is designed to help developers learn how the Liberty Alliance Version 1.0 specification can be implemented. Written for the Java 2 platform, IPL provides the foundation for building liberty into applications and testing interoperability between liberty compliant solutions such as the Sun ONE Identity Server version 6.0.
IPL consists of sample Java source code libraries, implementing the Liberty version 1.0 specification, and is not designed for commercial deployment. IPL is licensed as open source under the Sun Microsystems Open Source License.