Prerequisites for Federated Security
Note: This support has been verified with specific Oracle technology (and selected third party providers). The instructions in this section are specific to that group of products. Alternatives may be used but instructions will need to be adjusted for those products.
The following products were used in the implementation of Federated Security:
Product | Minimum Version | Comments |
|---|---|---|
Oracle Identity Management | 11.1.2.3.0+ | This version includes Oracle Identity Federation. If earlier version is used, then Oracle Identity Federation may need to be installed separately. |
OHS/WebGate | 12.2.1.4+ | Includes Apache HTTP Server 2.4 which is the recommended version. The instructions in this document are based upon OHS/Webgate 11.1.2.3.0. |
Oracle Utilities Application Framework | 4.3.0.5.0+ | |
Oracle Web Services Manager | 12.2.1+ | Installed with Oracle Fusion Middleware Infrastructure. |
3rd Party Identity Provider (IdP) | - | This document uses Shibboleth as an example only. Any 3rd party provider supporting SAML can be used. Refer to the Installation Reference for Oracle WebLogic and Oracle Interoperability. Note: This is not a recommendation from Oracle for implementing this capability. Shibboleth is recognized as a reference infrastructure. |
Process Flow
When a user logs in to an Oracle Utilities Application Framework application, there are two scenarios in relation to Single Sign On.
• Standard Single Sign On: This is where the single sign on infrastructure and related security repository are either all in the cloud or all on-premise. In this case the Oracle Access Management product is used as Single Sign On solution without the need for any federation.
• Federated Single Sign On: This is where the sign on and security provider are in a hybrid approach where one is on-premise (usually the identity provider) and one is on a cloud instance (usually the single sign on solution).
The latter has the following flow when logging in:
1. The user logs into the product using the provided login to the proxy (OHS/Webgate) which houses the access rules and detects that the user has not been authenticated yet.
2. Oracle Access Manager is called to determine that validation of the authentication is the responsibility of the external Identity Provider (IdP). It formats a SAML 2.0 request to be sent to the Identity Provider.
3. It responds to the user via the product as a redirect.
4. The browser redirects the request to the Identity Provider configured by Access Manager.
5. The SAML 2.0 request is sent to the Identity Provider for processing.
This part of the flow is shown below:
6. The Identity Provider authenticates the user and responds with a SAML 2.0 assertion which includes the authentication data.
7. The browser sends the SAML 2.0 assertion to Oracle Access Manager.
8. Oracle Access Manager validates the assertion and responds with an appropriate identity assertion for the SSO session.
9. The browser sends the SSO session to Webgate which now detects the user is valid and sends all the subsequent requests in that session to the product server(s).
10. The product server(s) respond with the appropriate responses for the transactions for the duration of the session.
This part of the flow is shown below:
In summary:
• WebGate is the proxy and gatekeeper of the session.
• If it detects the user is valid, it will use the session information as authentication tokens for the product.
• If Webgate detects the user has not been authenticated, it will use the rules in Access Manager to determine how to authenticate the user.
• Access Manager should be configured to point to the Identity Provider and format/process any SAML 2.0 requests/responses transmitted to/from the Identity Provider. It also provides the SSO credentials for valid users.
• The Identity Provider is responsible for taking the SAML 2.0 request, validating the user in the request and sending an appropriate SAML 2.0 response.
• The browser acts as the interface, known as the User Agent, between the various components as it is the common point in the hybrid architecture. The feature uses standard features of HTTP to redirect traffic as needed.