| Oracle® Fusion Middleware Administrator's Guide for Oracle Identity Federation 11g Release 1 (11.1.1) E13400-03 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Identity Federation 11g Release 1 (11.1.1) E13400-03 |
|
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 reduce the need for redundant logins, mere SSO is insufficient for companies which must operate in a federated environment - that is, an environment where services must 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. Some of these challenges include:
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 health care 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 health care 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 can 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 (IdP) is responsible for managing, authenticating, and asserting a set of identities within its set of federations.
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 (SP) provides services 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. |
A provider that performs user authentication through the OpenID protocol; abbreviated as OP. Similar to a SAML Identity Provider.
An OpenID Relying Party; abbreviated as RP. Similar to a SAML Service Provider.
An OpenID identifier that refers to a user managed by the OP.
An agreement between an OP and RP that defines a secret MAC key to be used for message signatures.
An online means by which the OpenID OP and RP can determine and verify service support and endpoint locations. Discovery in OpenID is done through the XRDS metadata publishing protocol. An OP's XRDS metadata advertises its supported services (for example, attribute exchange, PAPE, and so on.) and its sign-on URL. An RP's XRDS advertises its return URL.
Federations
A federation is a trust relationship between an identity provider and a service provider, which allows a principal to use a single federated identity and single sign-on when conducting business transactions with those providers.
Organizations create federations based on federation technology and operational agreements that define trust relationships between them.
For example, an enterprise federation could be created where the identity provider is a company leveraging employee network identities across the enterprise. Another example is in consumer banking, where the user's bank has established business relationships (that is, federations) with various other service providers, allowing the user to wield his bank-based network identity with those providers.
Federation Solutions
The essence of federation is the exchange of identity data between independent security domains. When we think about how to achieve federation, we inevitably must think about trust levels, goals and objectives, and the amount of administration involved in different types of federation:
|
Note: This list defines ways of thinking about federation at a business level, and about the types of solutions that may be relevant in planning your federation; they do not necessarily correspond to specific technical solutions. |
Transient Federation
Transient federation involves the transfer of the user session across domains without the need to send or consume additional identity data. The receiver relies on the sender to authenticate/authorize the principal.
Transient federation is suited for situations where a) the providers implicitly trust each other, and b) they agree to support common standards such as SAML 2.0.
Transient federation is relatively easy to implement and administer; the user experience is transparent as the user simply clicks a link to be able to access the service provider as an authenticated user.
In a common application of transient federation, a government agency - which maintains and authenticates citizen information in its own domain using certificates and other authentication methods - federates the user to other agencies to enable single sign-on to their services.
An obvious limitation of transient federation is the inability of the receiving domain to perform additional user verification due to reliance on the sending domain.
Account Mapping
Account mapping is suited for situations where the security domains may not have a very high level of established trust, or they wish to limit the information accessible to the federated user.
Account mapping involves additional administration since identities must be maintained in both domains. The domains exchange user information (assertions) in the form of messages that contain a user ID that can be mapped by the receiver to a known identity in its local store. By the same token, account mapping offers the advantage of not requiring a high level of trust between federating domains.
Account Linking
Account linking is an extension of account mapping; however, instead of maintaining local identity details in each domain, a receiving partner can utilize, or extend, the information it obtains from a user the first time federation occurs, and store it for future use.
The task of account creation is relegated to the user, and thus account linking reduces the administration effort needed by account mapping.
A typical application of account linking and account mapping is seen in the travel industry. Users can plan all aspects of their trip, including airline reservations, car rental, and hotel, when the businesses in question federate with related partners to share business opportunities, and also enable the user to access the necessary services with a minimum of authentications.
Attribute Federation
Attribute federation is useful in situations where the partners want or need to grant access to their resources based on access control policies.
Instead of maintaining user identities, each domain maintains such information as groups, roles, and so on. During federation, a receiving partner examines the user's attributes and maps them to this authorization information to determine what type of access to allow. Thus, the partners must agree on a common set of mapping rules.
Administration is simpler (than with account mapping/linking) since only rules must be maintained, not actual identity data.
An example of this type of federation is a business-to-business (B2B) environment, where the partners exchange identity information while maintaining their respective rules to grant access and determine the authorization for users requesting access to their resources.
Combined Federation
Combined federation, as the name suggests, enables the sending domain to provide as much identifying information (name, address, role, and so on) as it wishes in the federation request.
An advantage of this federation approach is the flexibility it provides each domain in how it formulates the request. At the same time, a disadvantage of combined federation is the high administration needs and the requirement of strong trust relationships and coordination among partners.
Identity Federation
Identity federation is the linking of two or more accounts a principal may hold with one or more IdPs or service providers that have created a federation.
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.
From a technical perspective, a principal's identity is said to be federated between a set of providers when there is an agreement between the providers on a set of identifiers and/or attributes to use to refer to the principal.
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 and subsequently use various resources among the group without the need to sign on again.
Under the SAML or WS-Federation protocols, performing a single sign-on operation between a principal, an SP and an IdP requires that:
there exists a federation between the SP and IdP, that is, they have a trusted business relationship.
the principal has local identities (or roles) as both the SP and the IdP, and that the two identities are federated.
Oracle Universal Federation Framework
The Oracle Universal Federation Framework provides out-of-the-box support for industry-standard federation features. It also provides a number of extensibility features, including:
custom actions before and after authentication and SP integration processing (this feature is also referred to as pre- and post-processing plugins)
custom authentication engines
custom SP integration engines
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:
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
SAML 2.0, which extends SAML 1.1 to provide additional profiles.
WS-Federation, which enables different security realms to federate by brokering trust of identities, user attributes, authentication between participating Web services
The SAML and WS-Federation 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. 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 Section 1.2.4, "Federation Protocol Profiles" for a description of the profiles supported in Oracle Identity Federation.
|
Note: Liberty 1.x support is deprecated. |
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 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: |
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. Specifically, SAML 1.1 introduces XML Digital Signatures changes that greatly improve interoperabilty. Because of these XML Digital Signature changes, Oracle recommends that you use the SAML 1.1 protocol over SAML 1.0 whenever possible as it greatly reduces issues when verifying signatures.
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>
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 requesters, such as Web browsers, and active requesters such as SOAP-enabled applications.
|
Note: Oracle Identity Federation currently supports passive requesters for WS-Federation. |
This section shows how Oracle Identity Federation allows users of Oracle Identity Management products, and 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, OpenID, 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:
SAML 1.x, including SAML 1.x attribute requester and responder, authn query responder and assertion ID responder functionality
SAML 2.0, including SAML 2.0 attribute requester and responder, authn query responder and assertion ID responder functionality
WS-Federation passive requester
Liberty ID-FF 1.x
OpenID 2.0
integration with Oracle Access Manager and Oracle 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 LDAP
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 and its relationship to other federation components. Here Oracle Identity Federation (denoted as OIF) has created federations with 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 act as an IdP and an SP. The identity provider and the two service providers shown in the figure are federated peer providers. |
Oracle Identity Federation includes a self-contained, lightweight authentication service.
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 Oracle Single Sign-On or Oracle Access Manager, including:
Oracle Collaboration Suite
Oracle E-Business Suite
PeopleSoft modules
and more
In addition to Oracle 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 Oracle Single Sign-On is deployed for use with those solutions.
|
Note: In an environment where Oracle Identity Federation and Oracle 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 Oracle Single Sign-On; or, Oracle 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
Before looking at Oracle Identity Federation features in detail, it is 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 Corporation 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 Corporation, may serve its technical database application with a "MyBeta.com" type of portal. In that case, each company would operate its own portal server.
The processing flow is as follows:
The user logs into Alpha portal whose access is being managed by a web access management (WAM) system like Oracle Access Manager, Oracle Single Sign-On or other product.
The user initiates a request, by clicking on a resource that is actually hosted by Beta corporation.
The Oracle Identity Federation instance at Alpha portal acting as the identity provider (IdP) sends the user information to the WAM system.
The WAM system creates a session after mapping a user to an identity in its local identity store.
The WAM system returns a successful response and the session token to the Oracle Identity Federation IdP server at Alpha portal.
Using the above information, the IdP at Alpha portal creates a SAML identity assertion and signs it using its private signing key. This response is sent to the Oracle Identity Federation instance acting as a Service Provider (SP) at Beta Corporation.
The Oracle Identity Federation server acting as SP at Beta Corporation verifies the signed response using the IdP's public certificate associated with its signing key.
The Oracle Identity Federation service provider at Beta Corporation extracts the assertion, and creates a user session for the assertion after mapping the user session to its local authorization system.
The Oracle Identity Federation service provider sends the user's browser a redirect to the requested resource.
The user's browser sends a request to the target resource over the user session created by the service provider.
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, WS-Federation, or OpenID. Assertion functions include:
establishing secure connections
conveying authentication data across those connections
receiving and interpreting assertions from other 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:
|
Note: Liberty 1.x support is deprecated. |
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 and WS-Federation, 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, 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 and WS-Federation, 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 provides an Attribute Query/Response protocol for retrieving a principal's attributes.
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 requester profile defines the use of this specification when clients for federation services include such passive requesters 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 will 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.
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 1).
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. 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:
SAML 2.0 IdP-Initiated Single Logout Profile
SAML 2.0 SP-Initiated Single Logout Profile
WS-Federation Passive Requester Logout Profile
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
Oracle Identity Federation supports the following OpenID extension and profile specifications:
Attribute Exchange (AX)
AX is an OpenID 2.0 extension allowing user attributes to be requested and returned.
Provider Authentication Policy Extension (PAPE)
PAPE is an OpenID 2.0 extension allowing RPs to request specific authentication type and strength, including Levels of Assurance.
US Government Federal Identity, Credentialing and Access Management (ICAM) Profile
This profile supports policy and security requirements for the US Government for OpenID 2.0 deployments, including:
No Personal Identification Information
Private Personal Identifier
GSA Profile for OpenID
NIST authentication levels
For details, see OpenID topics in Section 2.2, "Profiles and Bindings".
A SAML 2.0 or Liberty 1.2 affiliation consists of service providers that are part of a logical group.
|
Note: Liberty 1.x support is deprecated. |
An affiliation is not a concrete entity or server, but a logical grouping of providers. Thus, no particular server can act as an affiliation; rather, the affiliation identity is used by service providers when performing protocol message exchanges. In this case, the messages appear to come from the affiliation logical entity, but the actual sender of the messages is a specific service provider. In this way, the affiliation serves as an alias for all service providers in the affiliation, each of which makes use of the federation information associated with the affiliation entity.
Oracle Identity Federation uses Java Cryptographic Extension for any signature and encryption operations it needs to perform.
The signing and encryption keys must be provided to Oracle Identity Federation either as a PKCS#12 wallet, or as a Java Keystore.
|
Note: It is possible to configure Oracle Identity Federation to use a specific JCE Provider that will provide signing and encryption keys. |
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 My Oracle Support (formerly 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.
Under General Oracle Identity Management Certification Information, click Oracle Identity Federation Certification.
|
 Copyright © 2006, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
