OpenID 2.0 Protocol Supported Protocols

2-6 Oracle Fusion Middleware Administrators Guide for Oracle Identity Federation Pseudonyms Oracle Identity Federation uses opaque, persistent name identifiers in OpenID assertions. This means that: ■ a federation data store is required on the IdP side ■ a federation data store is optional on the SP side: if the SP is configured to use Federated Identity to map the assertion to a user, then the federation data store is required. Profiles and Extensions Table 2–3 shows the protocol profiles and extensions that Oracle Identity Federation supports.

2.2.2 Choosing a Profile

This section describes considerations to keep in mind when selecting a profile to implement for the selected protocol: ■ Under the SAML protocols, you can specify whether providers should exchange Oracle Identity Federation assertions using the artifact profile or the POST profile. These profiles represent different methods for secure exchange of assertions. ■ Under the OpenID protocol, you can select the ICAM profile, AX extension, or PAPE extension. This section discusses: ■ Using the Artifact Profile ■ Using the POST Profile ■ SAML Security Considerations ■ Using the SAML Attribute Sharing Profile ■ Using the WS-Federation Logout Profile ■ Using OpenID Profiles and Extensions

2.2.2.1 Using the Artifact Profile

Here are some items to keep in mind when considering the artifact profile: ■ The artifact profile is less resource-intensive than the POST profile because the latter uses XML signatures. ■ The identity provider’s SAML components must reside in the DMZ. Table 2–3 Oracle Identity Federation Profiles and Extensions for OpenID 2.0 ProfileExtension Notes Attribute Exchange AX extension v. 1.0 supported Provider Authentication Policy Extension PAPE v. 1.0 supported ICAM profile Support for No Personal Identification Information, ·Private Personal Identifier, ·GSA Profile for OpenID, and ·NIST authentication levels Planning Oracle Identity Federation Deployment 2-7 Artifact Profile Request Processing Figure 2–2 shows the process by which requests are processed under the artifact profile. Figure 2–2 Artifact Profile Processing Flow The processing flow takes this path: 1. A user performs a request at Oracle Identity Federation acting as the IdP. 2. Oracle Identity Federation authenticates the user and creates an artifact which includes an identifier for the IdP that is known to the SP. The message to be sent is stored in a repository at the server, with the artifact as a key for retrieval. 3. The server redirects the user to the peer site with the artifact. The artifact profile is used to carry the message. 4. The peer site decodes the artifact and deduces that Oracle Identity Federation is the originating site. 5. The peer site contacts the IdP Oracle Identity Federation, sends the artifact and asks the server to dereference it. 6. Oracle Identity Federation retrieves the message from the repository using the artifact. 7. Oracle Identity Federation sends the message to the peer site for processing. Note: Depending on the installation, the repository may reside either in memory or in a relational database. When using replicated Oracle Identity Federation servers for high availability, the repository must reside in a database. Note: This scenario illustrates IdP-initiated single sign-on. When the request is SP-initiated, the user directly requests the resource at the service provider.