Contained WithinFind More DocumentationFeatured Support Resources |  Download this book in PDF (1736 KB)
Chapter 5 Federation, SAML, and Web ServicesThis chapter explains the concept of identity federation, and describes the role of the Federation feature in Access Manager. For detailed information about enabling or managing identity federation, or using the Federation Management APIs and SPIs, see the Sun Java System Access Manager 7.1 Federation and SAML Administration Guide. This chapter includes the following topics: Federating IdentitiesConsider the many times an individual accesses services on the Internet in a single day. At work, he uses the company intranet to perform a multitude of tasks including reading and sending email, looking up information in the company phone book, searching internal databases, and submitting expense reports and other online forms. At home, he checks personal email, logs into an online news service, finalizes travel plans via a travel agent’s web site, and shops. Each time he accesses one of these services, he must log in and identify himself. A local identity refers to the set of attributes or information that identify the user to a particular service provider. These attributes typically include a name and password, plus an email address, account number or other identifier. Most users have many local identities. For example, the individual in our scenario might log in at work using an employee number but, at home, he might log in to his travel agent as Joe Smith. He might use an account number to log in to the car rental agency he uses frequently, and he might log in to an airline using a frequent flyer number. Identity federation allows a user to consolidate the many local identities he has configured among multiple service providers. With a federated identity, the individual can log in at one service provider site and move to an affiliated service provider site without having to re-authenticate or re-establish his identity. For example, with a federated identity, the individual might want to access both his personal email account and his business email account from his workplace, and move back and forth between the two services without having to log in each time. Or at home he might want to log in to an online travel agency to book airline tickets and make hotel reservations. It is a convenience for the user to be able to access all of these services without having to provide different user names and passwords at each service site. It is a valuable benefit to the user when he can do so safely, knowing that his identity information is secure. The Liberty Alliance ProjectThe Liberty Alliance Project develops and delivers specifications that enable federated network identity management and supporting web services. Using web redirection and open-source technologies such as SOAP and XML, they enable distributed, cross-domain interactions. The specifications include:
An overview of these specifications as well as background information on the Liberty Alliance Project can be found in Chapter 1, Introduction to the Liberty Alliance Project, in Sun Java System Access Manager 7.1 Federation and SAML Administration Guide. The specifications themselves can be found on the Liberty Alliance Project web site. How Federation WorksThe goal of the Liberty Alliance Project specifications is to enable individuals and multiple organizations to easily conduct network transactions while protecting the individual’s identity. When organizations form a circle of trust, they agree to exchange user authentication information using web service technologies. A circle of trust must contain at least one identity provider, a service provider that maintains and manages identity information. It also includes multiple service providers that offer web-based services to users. Once a circle of trust is established, single sign-on is enabled between all the providers and users can federate their multiple identities. In Access Manager, the circle of trust is referred to as an authentication domain. An authentication domain contains entities that are grouped together for the purpose of identity federation. A travel portal is a good example of an authentication domain. Typically, a travel portal is a web site designed to help you access various travel-related service providers from one location. The travel portal forms a partnership with each hotel, airline, and car rental agency displayed on its web site. The user registers with the travel portal which, in effect, is the authentication domain's identity provider. After logging in, the user looks for a flight using the airline service provider. After booking a flight, the user looks for a hotel using the accommodations service provider. This time, because of the agreements established among the travel portal partners, the airline web site shares the authentication information obtained earlier in the user's online session. The user moves from the hotel reservations web site to the airline reservations web site without having to re-authenticate. All of this is transparent to the user who must initially choose to unite his local identities. The following figure illustrates the travel portal example. Figure 5–1 Federation Within a Travel Portal
Note – Account federation occurs when a user chooses to unite distinct service accounts and identity provider accounts. The user retains individual account information with each provider in the circle. At the same time, the user establishes a link that allows the exchange of authentication information between them. Users can choose to federate any or all identities they might have with the service providers. After account federation, when a user successfully authenticates with one service provider, he can access any of the his accounts within the authentication domain in a single session without having to reauthenticate. The Web Services StackIn Access Manager, the Federation framework enables the secure exchange of authentication and authorization information by providing an interface for creating, modifying, and deleting authentication domains and configuring service and identity providers (both remote and hosted types) as entities. Additionally, the implemented web services define a stack to support the Federation framework. The following figure illustrates the architecture of the web services stack and how a web service consumer communicates with the web service provider (Access Manager). Figure 5–2 Web Services Architecture
Implemented ServicesAccess Manager includes the following web services based on the Liberty Alliance Project specifications:
Web Services ProcessThe following figure provides a high-level view of the process between the various components in the web services stack. In this example:
Figure 5–3 Web Services Stack Process
The following process assume that the user, the identity provider, and the service provider have already been federated.
For detailed information about all these components, see the Sun Java System Access Manager 7.1 Federation and SAML Administration Guide. SAML ServiceSAML defines an eXtensible Markup Language (XML) framework to achieve interoperability across different vendor platforms that provide SAML assertions. SAML is an XML framework for exchanging security information over the Internet. Access Manager SAML Service consists of a web service interface, a SAML core component, and a SAML framework that web services can connect to. The Access Manager SAML Service enables the following functionality:
|
|