Data Access Restriction Concepts

The HTTP API can be used by customers to build a custom User Interface. Typically, access to data residing in a browser, or flowing over the network, cannot be expected to be secure. Once the data is out of Oracle Health Insurance applications and sent to some User Interface or other client, it should therefore be properly protected.

For this reason, HTTP API implements Data Access Restriction automatically. This additional level of security in HTTP API cannot be circumvented.

The "User Access" chapter of the Security Guide explains which Data Access Restriction exists. HTTP API is using the Oracle Health Insurance User Access Restriction Model of Oracle Health Insurance Components. This model is also described in the User Access" chapter of the Security Guide.

Access Restrictions in Oracle Health Insurance Components can be used for several purposes, not all types of access restrictions are implemented in the HTTP API. The implemented types will be described in subsequent sections of this Security Guide.

When the HTTP API is used for integration (machine-to-machine communication), data access restrictions are also enforced. In this case, a username should be used with access roles with sufficient privileges for the integration use case at hand.

The implementation of data access restrictions in the HTTP API can happen in several ways. Those are described in the next paragraph.

Automatic Filtering of Top-Level Resources

The HTTP API will automatically add an additional filter when a resource is accessed. This type of restriction is used to restrict access to Sensitive Information. See the "User Access" chapter of the Security Guide for details about this category. When a resource is marked as Sensitive Information (by adding an access restriction), and a user is accessing the HTTP API without the access grants for that access restriction, the resource is not returned at all. Clients cannot determine whether that resource is not existing at all, or that it is protected. This restriction is used to completely hide certain sensitive resources, like secret addresses.

Automatic Filtering of Sub-Resources

The same filtering is applied to sub resources automatically as well. For example, a person in Oracle Health Insurance has 2 addresses: a restricted one and an unrestricted one. When the HTTP API is used to retrieve the person resource including all addresses as sub resources, only the unrestricted one is returned when the user has no rights to see the restricted address.

Concealing

Sensitive Information can also appear in a resource representation as linked resource. The resource the user is retrieving is unrestricted, but links to a resource with Sensitive Information the user is not allowed to see. See the "User Access" chapter of the Security Guide about concealing for more details.

An example of a resource representation with a reference to a linked resource when the linked resource is accessible for the user, is given below. There is a link relation present for claimantRelation:

{
   "claim" : {
      "id" : 123,
      "code" : "CLAIMCODE456",
      "claimantRelation" : {
         "links" : [ {
            "href" : "/[api-context-root]/generic/persons/142862",
            "rel" : "claimantRelation",
            "type" : "application/json"
         } ]
      }
}

An example of a resource representation with a reference to a linked resource when the linked resource is not accessible for the user, is given below. \ No details about the restricted claimantRelation are exposed:

{
   "claim" : {
      "id" : 123,
      "code" : "CLAIMCODE456",
      "claimantRelation" : {
          concealed: true
      }
}

It is possible that only certain attributes of a resource are concealed. In that case the resource representation is like this:

{
   "id" : 142862,
   "code" : "FI0001Person030",
   "name" : "FI0001Person030",
   "phoneNumberBusiness" : “concealed”

Inference Prevention

See the "User Access" chapter of the Security Guide for Inference prevention. All applicable inference prevention is implemented automatically by HTTP API.

Create, Update, and Delete

Data Access Restrictions may also restrict users in creating, updating and deleting. For example, only certain users are allowed to create secret addresses. The HTTP API automatically enforces those restrictions. When data access restrictions are violated, a HTTP 403-Forbidden status code is returned.