Security

Oracle Health Insurance Components are secure by default. For HTTP API/IP this means:

  1. Basic Authentication is applied. Every request must include username and password.

  2. Authenticated users must have been authorized for each resource they access.

More details about Oracle Health Insurance Components Security can be found in the Security Guide.

Basic Authentication

With Basic Authentication, clients have to include username and password in the Authorization header of each request:

GET /[api-context-root]/generic/<collection resource>/ HTTP/1.1
Host: <host>:<port>
... more headers ...
Authorization: Basic anZlcmhldWw6b3Blbnpvcmc5OQ==
Warning

Username and password are Base64 encoded in Basic Authentication. This does not guarantee confidentiality, as no encryption or hashing is applied. So Base64 should always be used in combination with HTTPS/SSL. See the Security Guide.

Warning

Although HTTPS/SSL secures the network traffic, Basic Authentication requires the username/password to be included with every request. This means clients have to store the password locally, for example in the browser memory or local storage for HTML5 User Interfaces. If not properly protected there, Basic Authentication is a security risk.

As an alternative to Basic Authentication, HTTP API/IP resources can be secured using OAuth2. The details for that are elsewhere in this guide.

Authorization

In addition to being authenticated, a user needs to be authorized for each operation on each resource. So again, by default everything is protected. Without authorization, a HTTP 403 status code is returned:

HTTP/1.1 403 Forbidden
Date: Fri, 30 Dec 2016 08:13:49 GMT
... more headers ...

Not authorized for this operation on this resource. Please contact your system administrator.

HTTP API/IP leverages the access restrictions model of Oracle Health Insurance Components. More details about this model can be found in the User Access Guide and the next sections.

HTTP API

For every resource exposed by HTTP API, a seeded access restriction exists with code "<collection resource> API". One can inspect those access restrictions using the "Access Restrictions" page.

Those access restrictions can be granted to a role using the "Access Roles" page, which in turn can be assigned to a user accessing HTTP API. When granting an access restriction to a role, four flags can be set:

  1. "Create?". When checked, this gives the right to POST new resources to the related resource, optionally including sub resources.

  2. "Retrieve?". When checked, this gives the right to GET resources from the related resource, optionally including sub resources.

  3. "Update?". When checked, this gives the right to PUT and PATCH existing resources, optionally including sub resources.

  4. "Delete?". When checked, this gives the right to DELETE existing resources, optionally including sub resources.

    Note

    Note that the flags always include sub resources as well. So if a user can POST claims, including a claim line as sub resource of the claim is allowed as well, even if the user does not have to rights the POST claim lines independently.

For convenience, the role "ALL_API_ACCESS_ROLE" is seeded as well, which gives access to available operations on all HTTP API resources.

HTTP IP

For every IP, a seeded access restriction exists with code " IP". For example "persons IP" or "diagnoses IP".

Those access restrictions can be granted to a role, which in turn can be assigned to a user accessing HTTP IP.

When granting an IP access restriction to a role, the "Create", "Retrieve", "Update" and "Delete" flags are always checked. HTTP IP does not consider this level of authorization. Once a user has access to an IP, all operations supported by that IP are authorized.

Access Restrictions differences between HTTP API and IP

The IPs are granted as a whole or not at all. So if a user had access to the Policies Integration Point, the user can then do GET, PUT or DELETE (which ever method is available) on that IP. It is not possible to give more fine grained control.

IPs are meant to be used for machine to machine communication. If a machine or operator has the rights on the integration, all functionality must be available. It’s not useful to grant only a part of the IP functionality.

For UI related work, it is strongly advised to use HTTP APIs. They provide a more fine grained control on the method and resource. With HTTP API it is distinguish between read only and read-write access using access restrictions.