Using the Artifact Profile

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. 2-8 Oracle Fusion Middleware Administrators Guide for Oracle Identity Federation In contrast with user entries and user federation records, artifact objects are considered as transient data. Because of its transient status, the artifact has a limited lifetime and will be removed from the repository after a certain time. Artifact Profile With Proxy As shown in Figure 2–3 , you can configure Oracle Identity Federation with proxies for IdP and SP servers when using the artifact profile. In this secure environment, the proxies are located within the DMZ. Figure 2–3 Artifact Profile Processing with Proxy The processing flow is as follows: 1. A user issues a request at the Oracle Identity Federation IdP server. 2. Oracle Identity Federation authenticates the user and creates an artifact which includes a short IdP server identifier. The server redirects the user with the artifact to the receiver service on the SP proxy server. 3. The user’s browser sends the request containing the artifact to the URL of the service provider’s receiver service, which is located on the proxy in the SP’s DMZ. 4. The proxy forwards the request to the Oracle Identity Federation SP server. 5. The SP contacts the IdP’s responder service, which is located on the proxy in the IdP’s DMZ, sends the artifact, and asks the IdP to dereference it. 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 . Planning Oracle Identity Federation Deployment 2-9 6. The proxy forwards the request to the IdP. 7. The IdP retrieves the message from the repository using the artifact, and sends it to the SP. 8. The SP server creates a user session and redirects the user’s browser to the desired resource. For testing purposes, you can configure the peer providers to communicate over open ports. Secure SSL ports are recommended for production, however, and the peer IdP and SP administrators must have exchanged and installed each other’s CA certificates. These certificates are used to encrypt and decrypt requests and responses exchanged between the respective federation servers

2.2.2.2 Using the POST Profile

With the SAML POST profile, the identity provider sends the full assertion to the service provider over HTTPS. While testing, you may wish to configure Oracle Identity Federation without using a proxy. Here are some items to keep in mind when considering the POST profile: ■ The POST profile does not require putting your IdP’s SAML components in a DMZ. ■ The SAML components can be placed behind a fire wall. ■ The POST profile requires the use of XML signatures, and signing and verifying signatures is resource-intensive. ■ If you plan to send or receive large numbers of requests and responses, consider Section 2.6, Sizing Guidelines for performance tips. POST Profile Request Processing Figure 2–4 shows the process by which requests are processed under the POST profile: Note: The assertion can be sent over HTTP as well. However, it is highly recommend that you always use HTTPS in production environments to ensure the security of the interaction. 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: