| Oracle® Identity Federation Administrator's Guide 10g (10.1.4.0.1) B25355-02 |
|
 Previous |
 Next |
| Oracle® Identity Federation Administrator's Guide 10g (10.1.4.0.1) B25355-02 |
|
Previous |
Next |
This chapter provides an introduction to federated identity management and describes key features and benefits of Oracle Identity Federation. It contains the following sections:
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 which must operate in a federated environment - that is, an environment where services need to be shared with business partners while protecting those same services from unauthorized access.
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.
This section provides an introduction to federated identity management. It contains these sections:
Single sign-on for Web-based applications is a business goal that has been approached and solved in various ways over the past several years. Still, enterprises continue to face major challenges in managing their information systems cost-effectively:
The proprietary nature of many of these solutions means that the protocol and software are particular to a specific vendor, implementer, or deployment scenario, and do not readily lend themselves to easy interoperability with other single sign-on systems.
The proliferation of content formats, supply chains, customer management systems, and user data stores poses security and maintenance concerns. For example, a financial services company serving healthcare organizations may need to manage hundreds of thousands of employee accounts and incur substantial costs related to provisioning new users, responding to events like forgotten passwords, and other record maintenance. On the part of the user, disparate authentication systems mean having to remember and perhaps write down multiple IDs and passwords, with the obvious risks inherent in that practice.
Ever-expanding and increasingly dynamic end-user communities demand that information and applications be accessible not only to employees, but to vendors, partners, and customers as well. Traditional efforts to provide access require maintaining individual user accounts within the organization, leading to duplication of identity data along with administrative and compliance issues.
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 healthcare organizations.
Use cases in this section explain how federation can provide a seamless end-user experience by authenticating once for multiple applications, to overcome the real-world business problems of the kind described above.
Use Case 1: Single Sign-On to Partner Site
Figure 1-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 1-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.
The following discussion introduces key concepts of federated identity management.
Principal
A principal is any entity capable of using a service and capable of acquiring a federated identity.
A Principal is a person (a "user"), a group of users such as a corporation, or a system entity whose identity can be authenticated.
This is one of the three primary roles defined in the identity federation protocols supported by Oracle Identity Federation. The others are Identity Provider (IdP) and Service Provider (SP).
Domains
A domain is a web site and applications that enable a principal to utilize resources. A federated site acts as an identity provider (source domain under some specifications), a service provider (destination domain), or both.
Identity Provider
An identity provider is responsible for managing, authenticating, and asserting a set of identities within a given circle of trust.
Identity providers are service providers offering business incentives so that other service providers affiliate with them.
This is one of the three primary roles defined in the identity federation protocols supported by Oracle Identity Federation. The others are Principal and Service Provider.
An identity provider is sometimes also referred to as a source domain in the SAML 1.x protocols. From this perspective, it is the point at which requests originate; users from a source domain request permission to access resources on sites residing on destination domains.
Service Provider
A service provider provides services or goods to a Principal while relying on an Identity Provider to authenticate the Principal's identity.
A service provider is also referred to as a Relying Party (SAML) or a destination domain. From the domain perspective, a service provider contains the resource that users from source domains wish to access.
Service providers are organizations offering Web-based services to users. This broad category includes practically any organization on the Web today, for example:
internet portals
retailers
financial institutions
government agencies
not-for-profit organizations
entertainment companies
transportation providers
This is one of the three primary roles defined in the identity federation protocols supported by Oracle Identity Federation. The others are identity provider and principal.
|
Note: A single organization may be both an identity provider and a service provider, either generally or in the context of a given interaction. |
Circle of Trust
A circle of trust is a trust relationship among a set of identity providers and service providers that allows a Principal to use a single federated identity and single sign-on when conducting business transactions with providers within that set.
Organizations affiliate together into circles of trust based on federation technology and operational agreements that define trust relationships between the parties.
For example, in the enterprise circle of trust, the identity provider is a company leveraging employee network identities across the enterprise.
Another example is the consumer banking circle of trust, where the user's bank has established business relationships with various other service providers, allowing the user to wield his bank-based network identity with those providers.
|
Note: There can be multiple identity providers within a given circle of trust. |
Identity Federation
Identity federation is the linking of two or more accounts a principal may hold with one or more identity providers or service providers within a given circle of trust.
When users federate the otherwise isolated accounts they have with businesses (known as their local identities), they are creating a relationship between two entities, an association comprising any number of service providers and identity providers.
Single Sign-On
Single sign-on enables users to sign on once with a member of a federated group of identity providers and service providers (from a provider's point of view, with a member of a circle of trust) and subsequently use various resources among the group without the need to sign on again.
Under the Liberty protocol, performing a single sign-on operation between a Principal, an SP and an IdP requires that:
the SP and IdP reside in the same circle of trust, that is, they have a trusted business relationship.
the Principal have local accounts at both the SP and IdP and that these two accounts be federated.
In building a federated architecture that addresses interoperability, assurance, and trust concerns across security domains, the following protocols have emerged as useful building blocks for identity management integration:
Security Assertions Markup Language (SAML), a standard developed by OASIS, provides a means for exchanging security information between online business partners. In a typical exchange of SAML messages between two parties, one party acts as a Relying Party while the other acts as an Asserting Party. The Asserting Party asserts information about a given subject, such as whether a subject has been authenticated, whether a subject is authorized to perform a certain action, and so on.
The Relying Party uses information provided by the Asserting Party to make security-related decisions regarding a subject, such as what types of access to a specific resource the subject should be granted, and so on.
The Liberty Identity Federation Framework (Liberty ID-FF) is a standard developed by the Liberty Alliance. Its objectives include:
enabling simplified sign-on through federated network identification
supporting permission-based attribute sharing to enable users to have control over the use and disclosure of their personal identity data
The SAML and Liberty protocols provide a framework for exchanging information between security domains, for provider introduction or "handshake," and for managing identity events such as federated sign-on and global logout. The protocols include:
SAML 1.0 and 1.1, which define a format for security data exchange known as an assertion, and profiles which provide the means for using the assertions
Liberty ID-FF 1.0 and 1.1, which extend SAML 1.0 to provide additional profiles for account linking, introductions, and other tasks
Liberty ID-FF 1.2
SAML 2.0, which incorporates Liberty ID-FF 1.2
WS-Federation, which enables different security realms to federate by brokering trust of identities, user attributes, authentication between participating Web services
These standards provide an XML-based framework for communicating security information across domains. Benefits include:
loose coupling of domains, with no need to synchronize or replicate user data between directories
a platform- and technology-neutral approach that removes barriers to cross-domain integration
broad support from application server, web services management, and security products and vendors, and adoption by a growing number of organizations
This section explains fundamental SAML concepts and provides details about federation protocols. It contains these topics:
See "Federation Protocol Profiles" for a description of the profiles supported in Oracle Identity Federation.
In a typical exchange of SAML messages between two parties, one party acts as a Relying Party while the other acts as an Asserting Party.
The Asserting Party asserts information about a given subject, such as whether a subject has been authenticated, whether a subject is authorized to perform a certain action, and so on. The Relying Party uses information provided by the Asserting Party to make security-related decisions regarding a subject, such as what types of access to grant the subject to a specific resource, and so on.
SAML Assertions
SAML associates a principal with additional identity information that can be used to determine the principal's access rights within a specific domain. Every SAML document has an assertion element containing such an association.
SAML defines three kinds of assertions, which are declarations of one or more facts about a subject:
authentication assertions, which state that the user has proven her identity by a particular method at a specific time
attribute assertions, which contain specific details about the user such as an employee number or an account number
authorization assertions, which state the resources a user can access and under what conditions they can be accessed
Assertions are coded statements generated about events that have already occurred.
|
Note: While SAML makes assertions about credentials, it does not actually authenticate or authorize users. |
Example 1-1 shows a typical SAML 1.0 authentication assertion wrapped in a SAMLP response message:
SAML Request and Response Cycle
In a typical SAML cycle, the relying party, which needs to authenticate a specific client request, sends a SAML request to its issuing authority. The issuing authority responds with a SAML assertion, which supplies the relying party with the requested security information. This cycle is illustrated in Figure 1-3.
For example, when a user signs into a SAML-compliant service of a relying party, the service sends a "request for authentication assertion" to the issuing authority. The issuing authority returns an "authentication assertion" reference stating that the user was authenticated by a particular method at a specific time. See Example 1-1 for a typical authentication assertion.
The service can then pass this assertion reference to other relying party sites to validate the user's credentials. When the user accesses another SAML-compliant site that requires authentication, that site uses the reference to request the "authentication assertion" from the issuing authority, which states that the user has already been authenticated.
At the issuing authority, an assertion layer handles request and response messages using the SAML protocol, which can bind to various communication and transport protocols (HTTP, SOAP, and so on). Note that while the client always consumes assertions, the issuing authority can act as producer and consumer since it can both create and validate assertions.
SAML Protocol Bindings and Profiles
SAML defines a protocol for requesting and obtaining assertions (SAMLP). Bindings define the standard way that SAML request and response messages are transported across the issuing authorities and relying parties by providing mappings between SAML messages and standard communication protocols. For example, one defined transport mechanism for SAML requests and responses over HTTP is Simple Object Access Protocol (SOAP). This enables the exchange of SAML information across several Web services in a standard manner.
A profile describes how SAML assertions are embedded into and extracted out of standard frameworks and protocols. Web browser profiles for single sign-on and SOAP profiles for securing SOAP payloads are some of the available profiles.
In response to the needs of access control vendors for a standard mechanism to speed development of cross-domain single sign-on applications, efforts by the OASIS standards organization produced SAML 1.0, the first such standard, in 2002. The Liberty Alliance, working on open standards for federated identity, built upon the SAML specifications to produce the Liberty 1 standard. At the same time, another consortium of vendors and companies worked on evolving authentication and authorization standards for Web service-oriented applications. Subsequent efforts led to the development of the WS-Federation standard, and extension and co-evolution of the SAML and Liberty standards in parallel. These different standards are described below.
|
See Also:
|
SAML 1.0 defines two key concepts:
a security token format, known as an assertion, which associates a given identity with specific access rights
profiles that describe ways to package these assertions to provide single sign-on
SAML 1.1 updates SAML 1.0 with feedback and corrections.
Example 1-1 shows a typical SAML 1.0 authentication assertion wrapped in a SAMLP response message:
Example 1-1 Sample SAMLP Response Containing a SAML 1.0 Authentication Assertion
<samlp:Response
MajorVersion="1" MinorVersion="0"
ResponseID="128.14.234.20.90123456"
InResponseTo="123.45.678.90.12345678"
IssueInstant="2005-12-14T10:00:23Z"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success" />
</samlp:Status>
<saml:Assertion
MajorVersion="1" MinorVersion="0"
AssertionID="123.45.678.90.12345678"
Issuer="IssuingAuthority.com"
IssueInstant="2005-12-14T10:00:23Z" >
<saml:Conditions
NotBefore="2005-12-14T10:00:30Z"
NotAfter="2005-12-14T10:15:00Z" />
</saml:Conditions
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2005-12-14T10:00:20Z">
<saml:Subject>
<saml:NameIdentifier NameQualifier="RelyingParty.com">
john.smith
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:artifact-01
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</samlp:Response>
Liberty ID-FF 1.1 is an extension profile of SAML 1.0 intended to support identity federation and single sign-on. The Liberty framework defines three types of actors: identity providers, service providers, and principals.
Within the Liberty framework, a group of Service Providers and Identity Providers may affiliate themselves with one another in what is known as a circle of trust. A Principal can then use a single federated identity and single sign-on when conducting business transactions with providers within the circle of trust.
Liberty ID-FF 1.2 is an extension profile of SAML 1.1 intended to support identity federation and single sign-on. The Liberty ID-FF 1.2 framework defines four types of actors: identity providers, service providers, affiliations (or group of service providers), and principals.
SAML 2.0 includes support for single sign-on based largely on the framework developed by the Liberty Alliance ID-FF specifications.
Although the concept of identity federation is not present in the specifications, SAML 2.0 promotes the existence of a name identifier for a specific use. SAML 2.0 supports a number of named profiles that largely mirror the functionality of the Liberty ID-FF 1.2 profiles, on top of the name identifiers inherited from SAML 1.x.
Example 1-2 shows a SAML 2.0 authentication assertion:
Example 1-2 SAML 2.0 Authentication Assertion
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Version="2.0"
ID="id-V01vmFAGUOKmKVJh9-hQ-gsPhX8-"
IssueInstant="2005-10-06T21:03:17.375Z">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
http://issuingauthority.example.com/
</saml:Issuer>
<!-- signature by the issuer over the assertion -->
<ds:Signature>
...
</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
id-V9l9N2S4nA8KlHd0X9Df3KYKm4E-
</saml:NameID>
<saml:SubjectConfirmation Method=
"urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
NotOnOrAfter="2005-10-06T21:03:32.375Z"
Recipient="http://issuingauthority.example.com/fed/sp/art20"
InResponseTo="id-G2mgYgtGH9gu8Nwo8KwxPYrpXKE-"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2006-04-27T16:40:49Z"
NotOnOrAfter="2006-04-27T17:05:49Z">
<saml:AudienceRestriction>
<saml:Audience>
http://serviceprovider.example.com:80/fed/sp
</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2005-10-06T21:01:03.451Z"
SessionIndex="1448745">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:
PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
The WS-Federation specification is "an integrated model for federating identity, authentication, and authorization across different trust realms and protocols." WS-Federation is a Web services-oriented standard which supports profiles for passive requestors, such as Web browsers, as well as active requestors such as SOAP-enabled applications.
|
Note: Oracle Identity Federation currently supports passive requestors for WS-Federation. |
This section shows how Oracle Identity Federation allows users of Oracle Identity Management products, as well as customers new to the Oracle APS stack, to engage in business associations across heterogeneous environments using various sources of user authentication. It contains the following topics:
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.
Key features of Oracle Identity Federation include:
the ability to implement cross-site access and authentication in an environment containing both identity providers and service providers
the ability to configure, enable, and disable external sites
the ability to access applications at destination sites using a single sign-on
support for these leading federation protocols:
Liberty ID-FF 1.1
Liberty ID-FF 1.2
SAML 2.0, including SAML 2.0 attribute responder functionality
WS-Federation
integration with Oracle Access Manager and OracleAS Single Sign-On
support for cross-protocol single sign-on and sign-out
support for affiliations, which reduce the number of federations by allowing service providers to share their federation information
integration with Oracle Internet Directory and support for:
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 X.509 certificate validation
Figure 1-4 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.
|
Note: A single Oracle Identity Federation instance can only support one IdP and one SP. Therefore, the two service providers shown in the figure cannot both belong to the same instance of Oracle Identity Federation. Rather, they are peer providers participating in the circle of trust. |
Oracle Identity Federation includes a self-contained, lightweight authentication service. Based on IdMBridge, this service - illustrated in Figure 1-5 - 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
Before looking at Oracle Identity Federation features in detail, it will be instructive to consider, at a high level, the processing flow that makes it possible to manage user access in such a federated environment.
Users typically access applications in multiple domains through a corporate portal. For example, Alpha Corp. could have a Portal Server in place, to manage Alpha's user logins, page personalization, and so on. The portal server might consist of homegrown logic running within an application server, or it might be a commercial product. Its partner, Beta Corp., may serve its technical database application with a "MyBeta.com" type of portal. In that case, each company would operate its own portal server.
A user logs into the Alpha portal, with the access being managed by a web access management (WAM) system such as Oracle Access Manager, CA SiteMinder, or some other product. Next the user clicks on a resource that is actually hosted by Beta Corp.
At this point Oracle Identity Federation connects to the WAM system to trigger the creation of a session, which is typically represented by an encrypted session token, that is set on the user's browser as a session cookie. The process by which Oracle Identity Federation triggers this session within the WAM system depends on the specifics of the WAM vendor (see "Authentication Engines"). At a high level, though, the process involves Oracle Identity Federation supplying attributes - obtained from the incoming assertion - to the WAM system through an API, which the WAM system uses to uniquely map to an identity in its local identity store.
Upon successful mapping, the WAM returns a successful response along with the session token (a SAML assertion). Starting with the initial user cookie (generated from the initial single sign-on at the portal), the federation engine thus builds a SAML assertion that can be presented to Beta Corp., which would then receive the SAML assertion and map it to its local authorization system.
For a more detailed description of Oracle Identity Federation processing flows, see Chapter 2, "Planning Oracle Identity Federation Deployment".
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:
The SAML Browser POST profile sends a full assertion from an identity provider to a service provider without the use of an artifact. Oracle Identity Federation sends the assertion to the user's browser as a hidden variable in the HTML form, and the browser then posts the assertion to the destination site.
In SAML 2.0, the HTTP POST Binding provides a framework for the embedding and transport of SAML protocol messages under real-world communication protocols.
Some browsers may limit the number of URL characters they can handle. The SAML Browser Artifact profile accommodates this by transmitting data using a compact reference to an assertion, called an artifact, instead of sending the full assertion. The recipient of the artifact then uses an artifact resolution protocol to obtain the full assertion referred to by the artifact.
In SAML 2.0, the HTTP Artifact Binding provides a framework for the embedding and transport of artifacts under real-world communication protocols.
A binding is the mapping of abstract message exchanges into real-world messaging or communication protocols. As an example, the SAML SOAP Binding defines how SAML protocol messages can be communicated within SOAP messages.
The Browser HTTP Redirect profile indicates to the requesting party that the requested resource resides under a different URL.
In SAML 2.0, the HTTP Redirect Binding uses the HTTP redirect response to send data in URL query string parameters through a user's browser from one provider to another. The amount of data that can be sent is limited by the maximum URL allowed by the browser, so this is usually employed for shorter messages and not full assertions.
Name Identifier Profiles define how providers communicate with each other when one of the providers wishes to update the name identifier assigned to one of their common users. These profiles allow a service provider or identity provider to specify (or register) a name identifier for a principal. Peer providers, for their part, must use this name identifier when communicating with other providers about the principal.
Oracle Identity Federation supports these SOAP/HTTP and HTTP-redirect name identifier profiles:
Liberty ID-FF 1.1 IdP-Initiated Register Name Identifier Profile
Liberty ID-FF 1.1 SP-Initiated Register Name Identifier Profile
Liberty ID-FF 1.2 IdP-Initiated Register Name Identifier Profile
Liberty ID-FF 1.2 SP-Initiated Register Name Identifier Profile
SAML 2.0 IdP-Initiated Manage NameID Profile for Name Identifier Update
SAML 2.0 SP-Initiated Manage NameID Profile for Name Identifier Update
SAML 2.0 provides an Attribute Query/Response protocol for retrieving a principal's attributes. The SAML Attribute Sharing Profile defines how to use this protocol with SOAP binding, to enable attribute retrieval when the subject is authenticated using an X.509 certificate.
To see how this is protocol is used, consider a principal who needs to access a web resource maintained at a service provider. Authentication is achieved by presenting the user's federated credential in the form of a trusted X.509v3 certificate, along with proof of possession of the associated private key. One common example of this is the client certificate authentication feature of the SSL (Secure Sockets Layer) protocol used between a user's browser and a web server.
The service provider may require additional information about the principal to determine authorization for some privileged resource. To get this information, the SP utilizes the SubjectDN from the principal's X.509v3 certificate to query an identity provider for the required attributes. When the IdP returns these attribute values, the SP can make an authorization decision based on the additional data. Thus, the profile provides additional protection of resources from unauthorized access.
WS-Federation provides support for integration of identity, authentication, and authorization across security domains and protocols. The WS-Federation passive requestor profile defines the use of this specification when clients for federation services include such passive requestors as Web browsers that support the HTTP protocol.
Users have the ability to terminate a federation, typically by using a link on the identity provider's or service provider's Web site. If initiated at the IdP, this action tells the SP that the IdP will no longer provide the user's identity information to the SP. If initiated at the SP, this action tells the IdP that the user requests that the IdP no longer provide that user's identity information to the SP.
|
Note: Federation termination is also referred to as defederation. |
The Federation Termination Profile specifies how identity providers and service providers are notified of federation termination.
Oracle Identity Federation supports these federation termination profiles:
Liberty ID-FF 1.1 IdP Initiated Federation Termination Notification Profile
Liberty ID-FF 1.1 SP Initiated Federation Termination Notification Profile
Liberty ID-FF 1.2 IdP Initiated Federation Termination Notification Profile
Liberty ID-FF 1.2 SP-initiated Federation Termination Notification Profile
SAML 2.0 IdP Initiated Manage NameID Profile for Name Identifier Deletion
SAML 2.0 SP Initiated Manage NameID Profile for Name Identifier Deletion
As the name implies, this profile provides support for global logout. The identity provider maintains a list of all the service providers at which a given user has logged in based on assertions provided by the IdP. When the user invokes logout, the IdP sends each SP a logout request for the user, achieving global logout with respect to that IdP.
The steps in the logout process are:
Either the user or a peer provider initiates the logout request.
The Oracle Identity Federation IdP sends a logout request to the service providers or identity providers where the user was logged in. The type of message sent depends on the type of single sign-on; for example, if single sign-on was based on Liberty 1.2, Oracle Identity Federation will send a Liberty 1.2 LogoutRequest.
Oracle Identity Federation receives a logout response from the provider to whom it sent the message.
Oracle Identity Federation sends the next logout request (step 2).
When the user is logged out of all the providers, Oracle Identity Federation logs the user out of the server.
For WS-Federation logout, Oracle Identity Federation displays a success page to the user. Liberty 1.x and SAML 2.0 logout profiles send the user back to the requesting peer provider that sent the original logout request.
Oracle Identity Federation supports SOAP/HTTP and HTTP-Redirect global logout profiles for these protocols:
Liberty ID-FF 1.1 IdP-Initiated Single Logout Profile
Liberty ID-FF 1.1 SP-Initiated Single Logout Profile
Liberty ID-FF 1.2 IdP-Initiated Single Logout Profile
Liberty ID-FF 1.2 SP-Initiated Single Logout Profile
SAML 2.0 IdP-Initiated Single Logout Profile
SAML 2.0 SP-Initiated Single Logout Profile
WS-Federation Passive Requester Logout Profile
A Liberty 1.2/SAML 2.0 affiliation consists of service providers that are part of a logical group.
An affiliation is not a concrete entity or server, but a logical provider; thus, no server can act as an affiliation. Rather, an affiliation will be used by service providers when performing protocol message exchanges - in this case, the affiliation will be viewed as a logical provider, but the sender/receiver of messages for this affiliation will be a concrete service provider. In this way, the service providers participating in the affiliation act as the affiliation, and will have access to all the federation information about that logical provider.
For details on implementing affiliations in Oracle Identity Federation, see "Configuring and Using Affiliations".
Oracle Identity Federation expects XML signing/encryption keys to be provided by means of a PKCS#12 wallet. Oracle Identity Federation does not provide configuration knobs for swapping out the underlying crypto provider
This section describes a typical message flow in a federated interaction.
Elaborating on the use case in Figure 1-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.
For information about the platforms and product versions supported by Oracle Identity Federation, see the appropriate certification matrix as follows:
Log in to MetaLink at https://metalink.oracle.com.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Select the Oracle Identity Management option and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1).
Under General Oracle Identity Management Certification Information, click Oracle Identity Federation Certification.
