Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management
| Liberty specifications primarily address identity federation, single sign-on, and global logout. Figure 7-5 shows a classic example of a business traveler authenticating with an airline and using a car rental service. In this example, JoeS joins a business travel service affinity group in which there are airline reservation services (Airline A), car rental services (Car Rental B), and hotel booking services (Hotel C). JoeS previously registers for online airline reservation services and car rental services. The business travel service affinity group runs a circle of trust under which service providers of airline reservation services, car rental services, and hotel booking services trust each other and share a common identity provider. Figure 7-5. Liberty use case scenarios
The following are the business events shown in Figure 7-5:
The following sections discuss how architects and developers can use Liberty-enabled solutions to address the business challenges of federated identity management, single sign-on, and global logout. Federation Management
Airlines, car rental companies, and hotels can federate themselves in an affinity group of business travel services. By federating themselves, they are able to rely on identity authentication services from an identity provider and share member identity information across different security infrastructures. In Figure 7-5, Airline A, Car Rental B, and Hotel C form an affiliated group under a circle of trust. They do not need to compromise or reengineer their security infrastructure for shared authentication or authorization. In other words, though their members (business travelers) may be using different user ids and account names in each service provider's system infrastructure, these service providers are able to link different user accounts to the same user identity anonymously under the circle of trust. Identity Federation
Identity federation refers to linking accounts from distinct service providers and identity providers. The primary service provider (say, the airline reservation company A) will notify its eligible users (in this case, JoeS) of the possibility of federating their local identities among the service providers in the business travel service affinity group. It will also ask for consent to introduce the user into the affinity group, once they detect that the user has previously authenticated with the identity provider. Other service providers will make similar solicitations for permission as well. Federating identities will create a unique identifier to link different user identities established in different service providers. If a user has already established a federated identity with an identity provider, the requesting service provider can issue a <NameIdentifierMappingRequest> message to obtain the federated identity when communicating with other service providers. Upon receiving the request message, the identity provider will respond with a <NameIdentifierMappingResponse> message. The <NameIdentifierMappingRequest> message is digitally signed, and the federated identity is encrypted. Example 7-9 shows a <NameIdentifierMappingRequest> message. Example 7-9. <NameIdentifierMappingRequest> message
<NameIdentifierMappingRequest Request MajorVersion="1" MinorVersion="2" IssueInstant="2005-06-30T09:30:47Z"> <ds:Signature>...</ds:Signature> <ProviderID> http://RequestingServiceProvider.com </ProviderID> <saml:NameIdentifier NameQualifier="http://www.coresecuritypatterns.com" Format="urn:liberty:iff:nameid:federated"> d24 7128b </saml:NameIdentifier> <TargetNamespace> http://TargetServiceProvider.com </TargetNamespace> </NameIdentifierMappingRequest>
Identity De-federation
Similarly, if the service provider is disassociated from the affinity group, it will also de-federate from the affinity group (identity de-federation) and notify the user. The federation termination notification (<FederationTerminationNotification>) is a specialized Liberty protocol to handle identity de-federation. Liberty-enabled architecture provides the capability of joining the identity federation or disassociating from the identity federation. Each of the service providers needs to implement a Liberty-enabled user agent so that it can reuse the user authentication service from the identity provider as well as federate the user identity of the users. The new ID-SIS personal or business profile defines the user profile and attributes for identity federation. Identity Registration and Termination
Liberty Alliance introduces an identity federated framework (also known as ID-FF) to provide a solution for identity federation, cross-domain authentication, and session management using a set of protocols, bindings, and profiles. When a new user identity is created, the service provider needs to register with the identity provider. The name registration protocol in the ID-FF defines an optional-use protocol for the service provider to use to create an opaque handle to register and identify a user (principal) when communicating with the identity provider. When a user is no longer allowed to access resources within the federated identity environment, the user identity needs to be revoked. This needs to be communicated from a service provider to the identity provider, or from the identity provider to all service providers within the federated identity environment. The federation termination protocol in the ID-FF defines a notification protocol using one-way, asynchronous messages to indicate either the service provider or the identity provider will no longer accept authentication messages for the specific user (principal). Liberty Single Sign-on
Once the registered user authenticates with the identity provider successfully, the identity provider will allow the user to use any business service within the affinity group. In Figure 7-5, JoeS authenticates with the identity provider, which verifies the user credentials for the right identity and grants access to business traveler services within the affinity group. Once JoeS signs on, he does not need to reauthenticate with any of the service providers in order to access other business traveler services. Identity Provider Session State Maintenance
Liberty specifies how an identity provider handles user authentication via redirection. Identity providers can maintain local session information locally (that is, local to the identity provider) via an HTTP-based user agent (commonly known as Web browsers) using cookies. This is different from creating client-side cookies at the user's desktop whereby sensitive identity information may be persisted. Identity providers map local session state information to the participating user agent (Web browser). When a user (Principal) authenticates with the identity provider and accesses a primary service provider's resources, the identity provider will persist and keep track of the authentication state information using cookies. If the user decides to access another service provider, the primary service provider will issue an <AuthnRequest> to the identity provider. The identity provider will then check its local session state information and return an <AuthnResponse> message with an authentication assertion. This response message indicates that the current user agent (browser) session is still active. Multi-tiered Authentication
With the nature of federated identity, Liberty allows authentication and authorization across different service providers, or across a multi-tier architecture. Some business services require more than one level of authentication to handle the varying nature of different business transactions. Some business transactions require sufficient quality of authentication mechanisms, in addition to plain user id and password. For example, a high-value funds transfer would require digital signing using an X.509v3 certificate. For risk-management purposes, service providers would not want any user with a user id and password to authorize a high-value funds transfer automatically without additional authentication. This type of reauthentication, or a second-tier authentication, is also known as multi-tiered authentication. It is true that Liberty supports a wide range of authentication methods, but the actual authentication methods and their supporting protocol exchange are not specified in the Liberty specifications. To support multi-tiered authentication, the identity provider and the affiliated service providers need to make a mutual contractual agreement and the associated protocol exchange prior to the identity exchange (in other words, out of band, or a special mutual agreement outside the standard identity exchange process). The element <AuthenticationContextStatement> can encapsulate the identification process, technical protection, operational protection, authentication method, and government agreements. In addition, it is an implementation decision to determine which party is performing the reauthentication and how to select the appropriate authentication profile for the user. In addition, architects and developers need to customize the authentication policy associated with access to specific resources (for example, funds transfer services). Credentials
Credentials contain security-related attributes that describe a user identity. Sensitive credentials require special protection from being stolen or tampered with, such as encryption and private cryptographic keys. These are used to prove an authentication or authorization assertion. For example, passwords and X.509v3 certificates are credentials. The Liberty artifact is a special form of credentials. The service provider can use a Liberty artifact profile to issue a query to the identity provider in order to get a SAML assertion. The Liberty artifact is an opaque user handle with a pseudo-random nonce that can be used only once. Thus, it serves the purpose of a credential and is a countermeasure against replay attacks. Communication Security
Typically, the user communicates with the identity provider or any service provider within the affinity group under the circle of trust via HTTPS. This secures the communication channel between client and server, or between servers. A service provider can reject communication with an identity provider if the security policy requires a credential over a communication protocol supporting bilateral authentication, integrity protection, and message confidentiality. Federated Single Sign-on
Performing single sign-on across different security domains within an affinity group under a circle of trust is also known as cross-domain single sign-on. Liberty 1.2 specifications currently support cross-domain single sign-on. If the service providers are associated with more than one affinity group, then they can participate in multiple circles of trust, and users in the service providers can then benefit from single sign-on to multiple affinity groups. If a user who belongs to multiple circles of trust (affinity groups) wants to access multiple resources with single sign-on, this will require exchanging identity information between different identity providers. This scenario is also known as federated single sign-on. An example of federated single sign-on is accessing resources across two identity providers with two different identity infrastructures, such as Liberty-enabled infrastructure and Microsoft Passport. At present, Liberty Phase 2 does not define any protocol or profile exchange between identity providers under the federated single sign-on scenario. In other words, users need to have an individual security session with each identity provider, and under each session they can enjoy single sign-on. Global Logout
Liberty defines a logout request to enable a service provider to request global logout within the affiliated group under a circle of trust. This requires specifying the federated identity of the user and the session index. Example 7-10 shows a logout request. In this example, Airline A issues a global logout request for the federated identity (encrypted). The logout request comes with a digital signature. Example 7-10. Liberty logout request
<LogoutRequest Request MajorVersion="1" MinorVersion="2 " consent="urn:liberty:consent:obtained" IssueInstant="2004-09-16T12:30:47Z"> <ds:Signature>...</ds:Signature> <ProviderID>http://AirlineA.com</ProviderID> <saml:NameIdentifier NameQualifier="http://AirlineA.com" Format="urn:liberty:iff:nameid:federated"> 342ad3d8-93ee-4c68-be35-cc9e7db39e2b </saml:NameIdentifier> <SessionIndex>3</SessionIndex> <RelayState> 23lkrjsdlfhsdffsda7sldfjsdl </Relay State> </LogoutRequest>
ExampleSAML and Liberty Using Sun Java System Access Manager
Sun Java System Access Manager was the earliest Liberty-enabled solution; Sun has made considerable contributions to Liberty as well as SAML. Access Manager runs on top of Sun Java System directory server so it can benefit from the underlying LDAP-based infrastructure. Figure 7-6 depicts the high-level technical architecture of Access Manager. It has a common administration graphical user interface for its access management, identity administration, service management, and federation modules. There are SDK libraries available for customizing or building SAML- and Liberty-enabled solutions, respectively. The authentication service provides a login servlet template for customization. The authentication mechanism reuses J2EE security APIs, including the JAAS authentication framework. It also has plug-ins for LDAP and X.509v3 certificates. The authorization or policy service includes a policy framework with a set of policy evaluation APIs and policy administration APIs. Figure 7-6. Sun Java System Access Manager architecture
Sun Java System Access Manager comes with a Java SDK library that supports SAML. The library includes:
In addition, Sun Java System Access Manager also provides a Java SDK library to customize or build Liberty-enabled applications. This Access Manager SDK provides interfaces to the following abstract objects that can be mapped to the resources and entities in the directory server for identity management:
Sun Java System Access Manager uses Sun Java System directory server to store the policy store, authentication data, and system configuration. |
Категории