Single Sign-On (SSO)

Oracle Health Insurance can participate in various SSO architectures. Example use cases are:

  • Multiple Oracle Health Insurance applications, each being executed in its own WebLogic domain, for which Oracle Access Manager (OAM) provides SSO capabilities.

  • One or more Oracle Health Insurance applications that are part of a larger set of business applications for which a third party identity management solution provides SSO capabilities.

Oracle internally runs multiple Oracle Health Insurance applications and verifies the SSO capabilities using OAM and the Oracle WebGate. In an SSO architecture the WebGate functions as a kind of firewall / proxy that protects resources based on URI patterns. It collaborates with OAM for authenticating users and establishing user sessions.

The following graphic provides a high-level overview for that architecture. It shows the components involved in authenticating a user and handling a request.

SSO with OAM

Overview of the process:

  1. The user sends a request for accessing an OHI Components application.

  2. The WebGate forwards the request to OAM for policy evaluation.

  3. OAM:

    • Checks for the existence of an SSO cookie.

    • Checks policies to determine if the resource protected and if so, how?4. OAM logs and returns decisions.

  4. WebGate responds as follows:

    • Unprotected resources are served to the user.

    • For a protected Resource the request is redirected to a SSO login page. Authentication processing begins.

  5. The user enters credentials and these are submitted to OAM.

  6. OAM verifies the credentials, for example by delegating the authentication request to an Oracle Directory server.

  7. OAM starts the session and creates cookies for that, e.g. an OAMAuthnCookie.

  8. Now that the user is authenticated, the user’s request is redirected to the application.

  9. It again passes the WebGate.

  10. The WebGate forwards the request to OAM for policy evaluation.

  11. OAM evaluates policies and validates the session based on the cookies.

  12. OAM logs and returns decisions.

  13. The request is passed on to the OHI Components application.

  14. The application processes the request and returns a response.

  15. The response is returned to the user’s client.

Setting up all the components that are involved and wiring these together is a complex process that should be handled by experienced resources. Oracle Consulting services can assist with that.

OHI Components applications SSO properties

As Oracle Health Insurance applications do not store user credentials, authentication requests are delegated to external authentication providers. For example, for an OHI Components application that is executed in a WebLogic domain a WebLogic Authentication Provider can be configured to handle user authentication against an external identity store. If an OHI Components application participates in an SSO architecture then the application relies on external components, like Oracle Access Manager and Oracle WebGate, to authenticate users. In that case the application must be configured such that it no longer authenticates users.

The Installation Guide for Oracle Health Insurance applications specifies the properties that must be set in order for an OHI Components applications to take part in an SSO architecture.