Securing Outbound RESTful Service Invocations using Basic Authentication

Using Basic Authentication for Data Replication related RESTful service

invocations between Oracle Health Insurance applications

With a "secure by default" installation RESTful services in Oracle Health Insurance application’s HTTP API require the use of Basic Authentication. To exchange data between multiple Oracle Health Insurance applications the following prerequisites must be adhered to.

Server Side

• The user account must exist in the user store that authentication requests are delegated to.

• The user must be provisioned in the Oracle Health Insurance application that the request is sent to.

• One of the access roles that is assigned to the user must have the appropriate access privileges granted. For example, to retrieve data replication events from Oracle Health Insurance Policies with user account X, privilege "replicationevents IP" must have been granted to a role that is assigned to user X.

Client Side

• Valid credentials for the user account must have been registered in the Oracle Health Insurance application from which the requests is initiated. The next paragraph explains the API that can be used to get an overview of credentials and for (re)setting these. Credentials are securely stored in an Oracle Platform Security Services (OPSS) credential store and need to be set on a per application and per WebLogic domain basis.

• Property "ohi.service.{0}.client.authentication" (for example: "ohi.service.DataReplicationPersonEvents.client.authentication" or "ohi.service.PolicyEnrollmentClient.client.authentication") must be set to value BasicAuthentication (which is also the default value for Oracle Health Insurance specific REST clients if it is not specifically set).

Managing Credentials using the Credentials IP

The RESTful "credentials" service supports the following options:

• GET "/credentials": returns an overview of the Oracle Health Insurance defined or registered REST Client use cases as well as customer defined use cases. The overview shows the credential key, the authentication feature (in this release BasicAuthentication or None) and identifies if a credential for that use case is registered or not. The following example shows credentials for data replication in Oracle Health Insurance Authorizations:

  { "credentialStatuses": [
      { "credentialKey": "DataReplicationPersonEntities",
        "credentialRegistered": true,
        "customerDefined": false,
        "authenticationFeature": "BasicAuthentication",
        "links": [
          {
            "href": "https://host:port/api/credentials/DataReplicationPersonEntities",
            "rel": "self"
          }
        ]
      },
      { "credentialKey": "DataReplicationPersonEvents",
        "credentialRegistered": true,
        "customerDefined": false,
        "authenticationFeature": "BasicAuthentication",
        "links": [
          {
            "href": "https://host:port/api/credentials/DataReplicationPersonEvents",
            "rel": "self"
          }
        ]
      }
    ]
  }

• PUT "/credentials/{credential_key}": accepts a credential in the following JSON format:

  { "username": "a_username",
    "password": "a_secret_password"
  }

  and resets the credential in the OPSS credential store (creates the credential if it does not exist or updates an already existing credential).

• DELETE "/credentials/{credential_key}": deletes the credential with the given credential key. If a credential was not found for the credential key that was passed by the client then an HTTP 404 (Not Found) response is returned. If the operation succeeded an HTTP 204 (No Content) response is returned.

Enabling Basic Authentication for a Callout Rule that is configured in an

Oracle Health Insurance Application

In this example a Callout Rule is defined in an Oracle Health Insurance Application for calling a Basic Authentication secured RESTful service in an external application. Callout Rules are defined as Dynamic Logic scripts. For this example it is assumed that the Dynamic Logic is saved with the uniquely identifying code 'SAMPLE_CALLOUT_RULE'.

To specify that the service that is called from the SAMPLE_CALLOUT_RULE Dynamic Logic is secured using Basic Authentication set the following property:

ohi.service.SAMPLE_CALLOUT_RULE.client.authentication=BasicAuthentication

Next, configure the credentials that the REST client will use when executing this Callout Rule. For that purpose send a request with the following JSON payload to the OHI Application’s "/credentials/credential/SAMPLE_CALLOUT_RULE" resource:

{ "username": "a_username",
  "password": "a_secret_password"
}