| Oracle® Identity and Access Management Introduction 10g (10.1.4.0.1) Part Number B31291-01 |
|
|
View PDF |
| Oracle® Identity and Access Management Introduction 10g (10.1.4.0.1) Part Number B31291-01 |
|
|
View PDF |
Although single sign-on (SSO) enjoys wide adoption for its ability to cut down the need for redundant logins, mere SSO is insufficient for companies that operate in a federated environment, that is, an environment where services are shared with business partners, while protecting those same services from unauthorized access.
Oracle Identity Federation is a standalone, self-contained federation server that enables single sign-on and authentication in a multiple-domain identity network. Oracle Identity Federation supports multiple federated identity protocols including the Liberty ID-FF and SAML protocols. This allows users to federate in heterogeneous environments and business associations, whether or not they have implemented other Oracle Identity Management products in their solution set.
This chapter provides an introduction to federated identity management and describes key features and benefits of Oracle Identity Federation. It contains the following sections:
A federated environment enables business partners to achieve integration in the identity management realm by providing a mechanism for companies to share identity information across their respective security domains.
Federated identity management is the evolution of the SSO paradigm in response to users' growing needs for access to computing resources and services that reside outside their own company's boundaries. In a federated environment, enterprises offering such a service can reliably obtain identity information about an individual or other entity from the user's home organization or security domain. This provides twin benefits:
The end user does not need to supply login credentials to access each entity where business is conducted. This also eliminates the need to remember and manage multiple logins/passwords. (Users still need accounts at the sites so that the accounts can be linked.)
Enterprises do not need to create additional accounts to manage the identities of users who are already known to a partner organization. In the example cited earlier, the service provider could simply leverage the employee data maintained internally by its client health care organizations.
Key features of Oracle Identity Federation include:
Cross-Site Capability—You can implement cross-site access and authentication in an environment containing both identity providers and service providers.
Configurability—You canconfigure, enable, and disable external sites.
Single Sign-On—Users can access applications at destination sites using a single sign-on.
Federation Protocol Support—Oracle Identity Federation supports these leading federation protocols:
Liberty ID-FF 1.1
Liberty ID-FF 1.2
SAML 1.0
SAML 2.0, including a SAML 2.0 responder
WS-Federation
Integration with Other Products—Oracle Identity Federation is integrated with Oracle Internet Directory, Oracle Access Manager, and OracleAS Single Sign-On. It also supports:
A range of authentication engines, including Oracle Access Manager and CA eTrust SiteMinder
User data repositories, including LDAP Stores such as Microsoft Active Directory and Sun Java System Directory Server
Relational databases
Support for cross-protocol single sign-on and sign-out.
Affiliations—Oracle Identity Federation supports affiliations, which reduce the number of federations by allowing service providers to share their federation information.
Certificate Validation—Oracle Internet Directory supports X.509 certificate validation.
This section contains the following topics:
Use cases in this section explain how federation can provide a seamless end-user experience by authenticating once for multiple applications.
Use Case 1: Single Sign-On to Partner Site
Figure 7-1 describes a situation where Mary, an employee of MyCorp, wishes to plan an upcoming business trip. She is able to achieve this seamlessly, in a single session, by performing the following steps:
Mary accesses her company's MyCorp employee portal from her terminal.
The portal, which is enabled with WS-Federation, presents her with a sign-on dialog.
After Mary signs on, the portal returns a page personalized with her information.
Mary commences travel planning by clicking on a link inside the portal for TravelClub, which is a partner organization providing access to a range of travel services for MyCorp employees. Mary has already established a federated relationship with TravelClub.
TravelClub requires authentication before Mary can access her account, and requests the same from MyCorp, which returns the necessary identity information to the travel site. Mary is then automatically authenticated to the TravelClub site. TravelClub returns a page with Mary's travel account information.
When Mary is done, she can log out of both her TravelClub and MyCorp sessions using a single global logout feature at the MyCorp home page.
In this way, Mary is able to authenticate once to her company's Web site, connect with another site and perform necessary tasks, without the need for any additional authentication at the second site.
Use Case 2: New Federated Account at Partner Site
Figure 7-2 illustrates a use case where Jim, another employee at MyCorp, wishes to set up a new account at MyCars, an external site which provides discount auto repair services to MyCorp employees. The steps are as follows:
Jim signs on to the MyCorp portal.
After doing some work within the portal, Jim elects to move to the "Vendors" page of the portal to look for automotive services, and clicks on the MyCars link.
Information is required to set up a new account at MyCars. With Jim's permission, MyCars communicates with MyCorp to obtain information relevant to Jim's identity.
Jim now has an account at MyCars, which he can access in a manner similar to that outlined in the previous use case.
These use cases are typical examples of the application of federated single sign-on and federated identity management. In subsequent sections we take a closer look at the key concepts of federation technology, and how they are leveraged in Oracle Identity Federation.
This section describes a typical message flow in a federated interaction.
Elaborating on the use case in Figure 7-1, consider that Mary is already authenticated at mycorp.com, and goes to travelclub.com where she is not logged in. travelclub.com requires Mary to be authenticated before she can access her local account, and redirects Mary with a SAML 2.0 message to mycorp.com requesting a single sign-on for travelclub.com. Since Mary is already logged in at the identity provider, mycorp.com retrieves Mary's account and federation data and redirects her back to travelclub.com. Using the Provider Identifier mycorp.com and the User Identifier xyz123 provided with the redirect, travelclub.com can uniquely retrieve Mary's federation data and her local account.
Identity providers and service providers exchange assertions using profiles and services defined in a federation protocol such as SAML or Liberty ID-FF. Assertion functions include:
establishing secure connections
conveying authentication data across those connections
receiving and interpreting assertions from other SAML domains
Profiles describe the types of exchanges required to transfer assertions between IdP and SP. This section takes a closer look at the assertion profiles available in Oracle Identity Federation.
Figure 7-3 shows the architecture of Oracle Identity Federation (OIF) and its relationship to other federation components. Here Oracle Identity Federation is a member of a circle of trust containing other identity providers and service providers, which can be additional Oracle Identity Federation instances or third-party providers.
Oracle Identity Federation includes a self-contained, lightweight authentication service. Based on IdMBridge, this service—illustrated in Figure 7-4—is deployed in a WAR (Web Application aRchive) file with Oracle Identity Federation and runs in the same Java Virtual Machine as the server.
Oracle Identity Federation can communicate with a range of authentication mechanisms and user data repositories:
Oracle Identity Management
You can configure the Oracle Identity Federation authentication service to enable single sign-on access to resources protected by OracleAS Single Sign-On or Oracle Access Manager, including:
Oracle Collaboration Suite
Oracle E-Business Suite
PeopleSoft modules
and more
In addition to Oracle Application Server Single Sign-On (with the Oracle Internet Directory user repository) or Oracle Access Manager (with various repositories), this configuration can also leverage third-party access management solutions when OracleAS Single Sign-On is deployed for use with those solutions.
|
Note: In an environment where Oracle Identity Federation and OracleAS Single Sign-On both protect resources, you can configure either component to serve as the authentication mechanism when a user requests access to a protected resource. For example, Oracle Identity Federation can forward authentication requests to OracleAS Single Sign-On; or, OracleAS Single Sign-On can request Oracle Identity Federation to locate an appropriate identity provider. For details, see Oracle Application Server Single Sign-On Administrator's Guide.Likewise, environments containing both Oracle Identity Federation and Oracle Access Manager provide similar functionality. |
Data Stores
You can configure Oracle Identity Federation to access:
LDAP directories
RDBMS databases
Oracle Access Manager
eTrust SiteMinder
