4 User Access

This chapter provides an overview of user access related topics.

4.1 User Provisioning

Before users can access OHI applications they have to be provisioned first, i.e. they have to be registered within the system. The User Provisioning web service is used for that purpose. It is documented in the User Access Implementation Guide.

Note:

OHI applications do not store password data.

4.2 User Authentication

Before users can access the system they have to be authenticated by entering username and password credentials in the login page. OHI applications delegate the actual authentication request to an identity and access management system of choice. The authentication provider can be configured through the WebLogic console. A combination of multiple authentication providers is supported, for example to try credential store A first and credential store B second.

Failed login attempts can be logged in a specific security log.

Note:

OHI does not enforce any password policies, like setting a maximum number of failed login attempts before an account is locked. That is also delegated to an access management system.The OHI Operations Guide explains the configuration for that.

For additional information on authentication please visit the following sources:

The OHI Installation Guide explains the configuration of an authentication provider for Oracle Internet Directory (OID).
For more information on WebLogic Authentication Providers see http://docs.oracle.com/cd/E17904_01/web.1111/e13707/atn.htm.
The OHI Operations Guide explains how the security log can be configured.

4.3 User Authorization

Access to data in OHI applications is restricted based on user authorizations. Access to all UI pages is protected: a page cannot be accessed unless a user is granted the proper privileges to do so.

Furthermore, more granular access to data in OHI may need to be restricted based on user authorizations for several reasons, like:

privacy, e.g. secret addresses,
sensitive medical information, e.g. regarding diagnoses and procedures for a member,
user skill level, e.g. for adjudicating high-value claims.

Access controls are maintained entirely in the application. Roles are fully configurable in the application but can be maintained in an external source (typically a directory server) so that these can be interfaced using the OHI provisioning service.

For additional information on configuration of user access right please read the User Access Implementation Guide.

4.4 Cookies

An OHI application is accessed by users through a browser. Because OHI uses session cookies to manage user sessions, cookies must be enabled in the browser. Consult the browser's documentation to configure the use of cookies.

The JSESSIONID session cookie contains the session ID generated for a user to manage data associated with the user's session. A unique session ID is generated when a user successfully logs into the OHI application. The session ID is generated by the JEE server and passed to a browser as a non-persistent cookie. The browser retains it for the duration of the session, and deletes it when the user logs out or the session times out. During a session, when a browser issues a request back to the application server, it sends the session cookie in the HTTP header of the request. Requests that do not contain valid session IDs are not processed by the server.