Home > Articles > Software Development & Management

This chapter is from the book Liberty Usage Scenarios

Liberty Usage Scenarios

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.

The following are the business events shown in Figure 7–5:

  • Under the circle of trust, members like JoeS can authenticate once with the identity provider (Step 1).
  • User JoeS accesses reservation service using single sign-on without duplicate logins to each service provider (Step 2).
  • Airline A asks for consent to federate identity with the affiliated group, when previous sign-on has been detected (Step 3).
  • User JoeS also accesses car rental service using single sign-on (Step 4).
  • Car Rental B prompts for consent to federate identity with the affiliated group, with previous sign-on detected (Step 5).
  • User JoeS accesses hotel reservation service using single sign-on (Step 6).
  • Hotel C prompts for consent to federate identity with the affiliated group, with previous sign-on detected (Step 7).

Figure 7–5 Liberty use case scenarios

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
     RequestID="a9c2-1b64-3bce-cb2e-3cbe ad118724"
     MajorVersion="1" MinorVersion="2"
      d24 7128b

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 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
   MajorVersion="1" MinorVersion="2 " 
</Relay State> 

Example–SAML 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:

  • SAML assertion statement (com.sun.identity.saml.assertion). This package creates and transforms SAML assertion statements, or accesses part of the attributes in the statements.
  • Common SAML functions (com.sun.identity.saml.common). This refers to XML attributes common to all elements.
  • Plug-in (com.sun.identity.saml). Currently, there are four Service Provider Interfaces (SPI) that are customizable. These APIs include AccountMapper, AttributeMapper, ActionMapper, and SiteAttributeMapper.
  • Protocol (com.sun.identity.saml.protocol). This package parses the request and response XML messages used to exchange assertions and their authentication, attribute, or authorization attribute information.
  • Digital signature (com.sun.identity.saml.xmlsig). This package refers to the digital signature utilities that sign and verify SAML messages.

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:

  • Constants (AMConstants)
  • Objects (AMObject)
  • Organization (AMOrganization)
  • Organization unit (AMOrganizationUnit)
  • People container (AMPeopleContainer)
  • User role (AMRole)
  • User (AMUser)
  • Service template (AMTemplate) to associate with the attributes of AMObject.

Sun Java System Access Manager uses Sun Java System directory server to store the policy store, authentication data, and system configuration.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020