SAML 2.0 Protocol SAML 1.x and WS-Federation Protocol

Planning Oracle Identity Federation Deployment 2-5

2.2.1.3 OpenID 2.0 Protocol

Oracle Identity Federation supports OpenID version 2.0. Authentication Oracle Identity Federation supports basic OpenID authentication request functionality. Associations Oracle Identity Federation supports provider federations using an HMAC shared secret for message signing and verification, including: ■ HMAC-SHA1 ■ HMAC-SHA256 Oracle Identity Federation supports these session association types: ■ No encryption ■ Diffie-Hellman SHA1 ■ Diffie-Hellman SHA256 Discovery Oracle Identity Federation supports: ■ metadata publishing for OpenID Provider OP and Relying Party RP ■ XRDS discovery of OPs by the RP RP endpoint validation is implemented to defend against URL redirectors spoofing RPs to capture OpenID assertions. The RP endpoint validation by the OP is implemented by: ■ XRDS discovery of the RP, checking that the endpoint is listed in the XRDS documented hosted at the realm URL ■ ·Verification using the Realm as described by the OpenID specifications. The realm can either be a URI or a matching domain .foo.com for example. At verification, the server extracts the domain from the realm and attempts to match it to the RP endpoint. A valid domain used for verification needs to contain at least two elements .foo.com is acceptable while .com is not. Additionally, the server provides a way to specify which domain should be discarded for example .co.uk. Account Linking Oracle Identity Federation supports persistent account linking between OpenID claimed ID and local user account by using a federation data store. Assertions Oracle Identity Federation supports assertion-to-user record mapping on the SP side. Logout HTTP Redirect x Table 2–2 Cont. Oracle Identity Federation Profiles and Bindings for SAML 1.x and WS-Federation Function Profiles Bindings SAML 1.01.1 WS-Federation 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