Oracle Identity Federation
This chapter provides an introduction to federated identity management and describes key features and benefits of Oracle Identity Federation. It contains the following sections:
1.1 Federated Identity ManagementAlthough 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 afederated 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:
1.1.1 Challenges of Identity FederationSingle 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.
- 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.
1.1.2 Federation Use CasesUse 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 SiteFigure 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.
Use Case 2: New Federated Account at Partner SiteFigure 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.
1.1.3 ConceptsThe following discussion introduces key concepts of federated identity management.
PrincipalA 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).
DomainsA 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), aservice provider (destination domain), or both.
Identity ProviderAn 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 ProviderA 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
- financial institutions
- government agencies
- not-for-profit organizations
- entertainment companies
- transportation providers
FederationsA 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 SolutionsThe essence of federation is the exchange of identity data between independent security domains. When we think about how to achieve federation, we inevitably need to think about trust levels, goals and objectives, and the amount of administration involved in different types of federation:
- 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 need to agree on a common set of mapping rules.
Administration is simpler (than with account mapping/linking) since only rules need to 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 FederationIdentity 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-OnSingle 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.
1.1.4 Federation ProtocolsIn 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
- 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
"Federation Protocol Profiles" for a description of the profiles supported in Oracle Identity Federation.
126.96.36.199 SAML BasicsSecurity 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 AssertionsSAML 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
assertionelement 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
Example 1-1 shows a typical SAML 1.0 authentication assertion wrapped in a SAMLP response message:
SAML Request and Response CycleIn 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.
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 ProfilesSAML 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.
188.8.131.52 Evolution of the Federated Identity StandardsIn 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.
184.108.40.206 SAML 1.xSAML 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
Example 1-1 shows a typical SAML 1.0 authentication assertion wrapped in a SAMLP response message:
220.127.116.11 SAML 2.0SAML 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:
18.104.22.168 WS-FederationThe 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.
1.2 About Oracle Identity FederationThis 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:
- Features and Benefits of Oracle Identity Federation
- High-Level Processing Flow
- Federation Protocol Profiles
- Cryptographic Provider
- Example of Federation Event Flow
- Supported Standards and Applications
1.2.1 Features and Benefits of Oracle Identity FederationOracle 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:
- SAML 1.x, including SAML 1.x attribute requestor and responder, authn query responder and assertion ID responder functionality
- SAML 2.0, including SAML 2.0 attribute requestor and responder, authn query responder and assertion ID responder functionality
- WS-Federation passive requestor
- Liberty ID-FF 1.x
- 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
1.2.2 ArchitectureFigure 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.
- 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
- Data Stores
You can configure Oracle Identity Federation to access:
- LDAP directories
- RDBMS databases
1.2.3 High-Level Processing FlowBefore 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 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.
1.2.4 Federation Protocol ProfilesIdentity providers and service providers exchange assertions using profiles and services defined in a federation protocol such as SAML or WS-Federation. Assertion functions include:
- establishing secure connections
- conveying authentication data across those connections
- receiving and interpreting assertions from other SAML domains
- Browser POST Profile
- Browser Artifact Profile
- SOAP Binding
- Browser HTTP Redirect Profile
- Name Identifier Management Profiles
- SAML Attribute Sharing Profile
- Federation Termination Profile
- Global Logout Profile
- WS-Federation Passive Requester Profile
22.214.171.124 Browser POST ProfileThe 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.
126.96.36.199 Browser Artifact ProfileSome 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.
188.8.131.52 SOAP BindingA 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.
184.108.40.206 Browser HTTP Redirect ProfileThe 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.
220.127.116.11 Name Identifier Management ProfilesName 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
18.104.22.168 SAML Attribute Sharing ProfileSAML 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
SubjectDNfrom 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.
22.214.171.124 WS-Federation Passive Requester ProfileWS-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.
126.96.36.199 Federation Termination ProfileUsers 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.
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
188.8.131.52 Global Logout ProfileAs 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.
- 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
1.2.5 AffiliationsA SAML 2.0 or Liberty 1.2 affiliation consists of service providers that are part of a logical group.
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.
The signing and encryption keys need to be provided to Oracle Identity Federation either as a PKCS#12 wallet, or as a Java Keystore.
1.2.7 Example of Federation Event FlowThis 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.comand the User Identifier
xyz123provided with the redirect, travelclub.com can uniquely retrieve Mary's federation data and her local account.
certification matrix as follows:
- Log in to My Oracle Support (formerly MetaLink) at
- 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.