Using the POST Profile

2-10 Oracle Fusion Middleware Administrators Guide for Oracle Identity Federation Figure 2–4 POST Profile Processing The processing flow is as follows: 1. The user initiates a request, and must be authenticated before the request can be processed. 2. Oracle Identity Federation - acting as the identity provider - authenticates the user and returns an HTML form containing a response, which consists of an identity assertion and the URL of the service provider. The response is signed using the Oracle Identity Federation IdP’s private signing key. 3. The browser posts this form to the URL of the service provider’s receiver service. The receiver service verifies the signed response using the IdPs public certificate associated with its signing key. 4. The service provider extracts the assertion, and creates a user session for the assertion. 5. The service provider sends the user’s browser a redirect to the requested resource. 6. The user’s browser sends a request to the target resource over the user session created by the service provider. POST Profile With Proxy In a secure deployment, the POST profile sends the full assertion to the service provider over SSL. The IdP and SP are configured to communicate over HTTPS through their SSL ports. Figure 2–5 illustrates this preferred approach for using the POST profile in production, with Oracle Identity Federation serving as the SP in the DMZ: Planning Oracle Identity Federation Deployment 2-11 Figure 2–5 POST Profile with a Proxy The processing flow is as follows: 1. With Oracle Identity Federation acting as the IdP, the user requests a resource. The SP, an Oracle Identity Federation server, is accessed through a proxy server located in the DMZ. 2. The IdP server authenticates the user and responds with an HTML form that contains an assertion and the URL of the target resource. The response is signed using the Oracle Identity Federation IdP’s private signing key. 3. The user’s browser posts the form to the SP’s proxy receiver service URL. 4. The proxy forwards the form to the SP’s receiver service. 5. The Oracle Identity Federation SP verifies the signature, extracts the assertion, creates a user session for the assertion, and sends the user’s browser a redirect to the resource. 6. The browser conveys the request to the target resource over the new user session. The request may be handled by an additional proxy located in the service provider DMZ. See Also: For more information about setting up a proxy server for Oracle Identity Federation, see Appendix B, Using Oracle HTTP Server as a Proxy for Oracle Identity Federation . 2-12 Oracle Fusion Middleware Administrators Guide for Oracle Identity Federation

2.2.2.3 SAML Security Considerations

SAML provides numerous security features that you can use to ensure privacy, integrity, authenticity, and confidentiality of the SAML messages and the message exchanges. This section provides a brief summary of message security considerations. For a detailed analysis of the security risks and countermeasures, refer to the OASIS SAML Security Considerations specification, titled Security and Privacy Considerations for OASIS SAML V2.0, at: http:docs.oasis-open.orgsecuritysamlv2.0saml-sec-consider- 2.0-os.pdf Oracle Identity Federation supports the full set of security technologies and techniques available for use in a SAML deployment. These include ■ SSLTLS for peer authentication and secure communications ■ XML-SIG for message-level integrity and authentication ■ XML-ENC for message-level confidentiality Oracle recommends that secure SSLTLS channels be used for all SAML message flows in addition to message level security. All communications between an identity provider and service provider must use bilateral authentication client and server certificates. SAML profiles provide specific recommendations on how to securely use SAML assertions and request-response messages in communications protocols. Here are the security requirements for the SAML SSO Artifact and POST profiles. Secure communication using the SAML Artifact Profile Secure communication using the SAML artifact profile requires the following: 1. SSL is required for redirection from the IdP to the users browser, and for redirection from the browser to the SP. 2. The SOAP channels used by the IdP and SP to communicate directly must be protected either by using SSL or by using HTTP Basic Authentication. Secure communication using the SAML POST Profile Secure communication using the SAML POST profile requires the following:

1. Secure HTTP HTTPS is required to transmit a user request from a browser to the

service provider.

2. The identity provider must use an XML signature to sign responses it sends to a

service provider.

3. The service provider must verify the XML signature on the response.

2.2.2.4 Using the SAML Attribute Sharing Profile

The SAML attribute sharing profile is used by service providers to authenticate users by means of SSL client X.509 certificates rather than SAML assertions, when additional user attributes are needed to provide authorization of resource requests. Note: It is also possible for the SP to use HTTP basic authentication with a username and password known to the IdP. Planning Oracle Identity Federation Deployment 2-13 Oracle Identity Federation provides the attribute sharing profile for use with Oracle Access Manager to enable interoperation with SAML implementations at peer sites. For details about components and their respective roles, and how to configure Oracle Identity Federation and Oracle Access Manager, see Section 5.6.4.3, Configuring an Oracle Access Manager Policy using Attribute Sharing .

2.2.2.5 Using the WS-Federation Logout Profile

WS-Federation can be used to sign into one or more service providers using an identity provider that performs the actual authentication. To log out, the user clicks on a link at the IdP site that initiates a WS-Federation signout. Using a session cookie, Oracle Identity Federation has kept track of each SP to which the user signed on. The server returns an HTML signout page to the user’s browser. Each SP processes the signout cleanup to sign out the session created for Oracle Identity Federation.

2.2.2.6 Using OpenID Profiles and Extensions

This section describes Oracle Identity Federation support for different OpenID profiles and extensions. Attribute Exchange AX AX is an OpenID 2.0 extension allowing user attributes to be requested and returned. OIF supports AX version 1.0. Support on the IdP includes the following: ■ Profile support is enabled on the IdP, but for each SP, you must indicate whether attributes should be sent ■ Attribute definition is achieved through the existing screen on the SP Partner specific page Support on the SP includes the following: ■ Attribute definition is achieved through the existing screen on the IdP Partner specific page ■ In the attribute definition page, you can specify which attributes to request from the IdP when performing the SSO protocol. ■ A custom SP engine or a pre-processing engine can dictate at run-time which attributes must be requested from the IdP when performing the SSO protocol. Provider Authentication Policy Extension PAPE PAPE is an OpenID 2.0 extension allowing RPs to request specific authentication typestrength, including Levels of Assurance. Oracle Identity Federation supports PAPE version 1.0. Support on the IdPOP includes the following: ■ The IdP publishes in the XRDS document whether or not the PAPE extension is enabled. ■ If enabled, the IdP includes the authentication mechanism used to authenticate the user in the response to the SP. Support on the SPRP includes the following: