Liberty Alliance Architecture

The initial proposal of Liberty Alliance includes the following stages:

I. Single Sign-on for e-Wallet applications (which involves use of context-sensitive cookies and multi-authentication systems),

II. Federated Data Exchange (which uses extensive schema with mappings between partners and strong cryptographic mechanisms between trading partners),

III. B2B Transaction Support (which provides asynchronous communication and non-repudiation),

IV. Web Services as endpoints (distributed redundant data for identity theft protection).

There are three key actors in a Liberty-enabled single sign-on business scenario: User Agent (User, security agent), Service Provider (provider of services to users), and Identity Provider (provider for identifying user identity). The following describe these actors and their relationship.

• User Agents Users or security agents that require signing on to the systems once to access the business services that they are entitled to.

• Service Providers Service providers are organizations offering Web-based services to users. This includes a broad category of Internet portals, online stores, retailers, wholesalers, manufacturers, transportation service providers, financial service institutions, entertainment services, non-profit organizations, government agencies, and so forth.

• Identity Providers Identity providers are service providers that specialize in providing authentication services. Any service provider affiliated with the identity provider will honor the authentication done by the latter. For example, Hong Kong Post, who is also a Certificate Authority, provides authentication services to local service providers.

Relationships

Service providers are affiliated with an identity provider into circles of trust based on Liberty-enabled technology and on operational requirements that define trust relationships among themselves. In addition, users federate their accounts (also known as local identities) with these service providers so that the same user identity can link to multiple accounts under different service providers. Under the mutually trusted environment, if a user authenticates with the identity provider, these service providers will honor the authentication. Such a business relationship is also known as "Circle of Trust."

Figure 7-4 summarizes the Liberty concept in the use of cross-domain Single Sign-on and depicts the following interactions:

• User Agent sends an HTTP request to Service Provider for Single Sign-on (Step 1).

• Service Provider responds by redirecting the request to Identity Provider (Step 2).

• User Agent sends a request to Identity Provider (Step 3).

• Identity Provider responds by redirecting to Service Provider (Step 4).

• User Agent sends an authentication request to Service Provider with URI (Step 5).

Figure 7-4. Liberty's logical architecture

Web Redirection

Web Redirection refers to actions that enable Liberty-enabled entities to provide services via user agents. It has two variants: HTTP-redirect-based redirection and Form-POST-based redirection. HTTP-redirect-based redirection uses HTTP redirection and the syntax of URIs to provide a communication channel between identity providers and service providers. For instance, the user clicks a link in the Web page displayed in the user agent. The user agent sends an HTTP request of resource access to the service provider using HTTP GET. The service provider responds with an HTTP response with a status code 302 (HTTP redirect) and an alternate URI (identity provider URI such as http://www.myidentityprovider.com/auth) in the Location header field. Then the user agent sends an HTTP request to the identity provider, and the identity provider can then respond with a redirect that specifies the service provider URI in the Location header field. Finally, the user agent sends an HTTP request to the service provider using HTTP GET with the complete URI from the identity provider's Location header field.

The flow of events in form-POST-based redirection is similar to the HTTP-redirect-based redirection, except that the service provider responds with an HTML form to the user agent with an action parameter pointing to the identity provider and a method parameter with the value of POST. The user needs to click on the Submit button, which sends the form and the data contents to the identity provider using HTTP POST.

Web Services

Web services here refer to business services provided by service providers using SOAP protocol profiles that enable Liberty-enabled entities to communicate to each other. Liberty currently supports RPC-style SOAP Web services.

Meta-Data and Schemas

Meta-data and schemas refer to a common set of classes of information and their formats that are exchanged between service providers and identity providers. They include user account identity information, authentication context (supporting a variety of authentication methods), and provider meta-data (meta-data schemas that need to be exchanged prior to exchanging authentication information, such as X.509v3 certificates and service endpoints).

Security Mechanisms

The Liberty ID-WSF specification defines security mechanisms that address the use-case scenarios intended for identity-based Web services. It mandates that the Liberty-provider implementation include security mechanisms that address the following requirements in order to secure the exchange of identity information between the applications and participants. The security mechanisms must address the following key requirements:

• Request Authentication

• Response Authentication

• Request/Response Correlation

• Replay Protection

• Integrity Protection

• Confidentiality Protection

• Privacy Protections

• Resource Access Authorization

• Proxy Authorization

• Mitigation of denial of service attack risks

In the Web redirection scenario, Liberty suggests the use of HTTPS for exchanging identity information and authentication assertions. This provides a secure transport mechanism between service providers and identity providers. In addition to the underlying secure transport, Liberty relies on strong authentication mechanisms used by the identity provider. Using cookies to maintain the local session state is often abused by unauthorized Web sites and hackers. If developers use cookies to persist identity and authentication information, it is possible that once a user exits the Web browser, another user may re-launch the Web browser using the same system, which may result in impersonating the first user. Using Web redirection and URL rewriting, identity providers do not need to send business data to service providers via cookies.

For details of the Liberty security mechanisms, please refer to [LibertyIDWSF].