Functional Access Restriction (JET)

Each user that has authenticated successfully, needs to be authorized for accessing system functions. This page describes the concepts of authorization, the steps to setup and typical use cases.

Concepts

Access to all UI pages is protected. Each page is represented by an access restriction of type function. So a user can only access pages he has been granted access to via one of his roles. Function access is granted on the level of a page. It is not possible to give access to certain parts of a page. For example, when the user has access to the persons page, he can search for persons, he can access all parts of that a view and edit person page like person data, person addresses, person bank accounts and so on.

A user can be granted Retrieve access to a page, and optionally also Create, Update, and/or Delete access. Create access means that new records (objects and its details) can be added. Delete access means that records can be deleted. Dynamic fields and multi-select drop down lists are considered attributes of an entity, if the user has Update access to the page he can add/remove/update such attributes even if he does not have Create or Delete access.

Menu options to which the user does not have access, are not shown. On a page to which the user has access, add / delete / save buttons are hidden if the user does not have access rights for that operation. If the user does not have update access, fields are displayed as read-only.

If a link on a page to which the user has access, brings the user to a page to which he does not have access, an access denied page is shown.The following table lists what the CRUD indicators mean for function access type restriction in context of JET UI:

Type \ CRUD indicator	Create grant on access restriction	Retrieve/read grant on access restriction	Update grant on access restriction	Delete grant on access restriction
Function	A user with this grant can create an new record. A user must have this grant to access the 'Create' object page through the URL. Grant to 'Create' implies that a user can add, or remove a details (while in the create mode).	can access the page linked to this access restriction	A user with this grant can update an existing record. Grant to 'Update' implies that a user can add, update, or remove a detail.	may delete an existing record (with its details)

Type \ CRUD indicator

Create grant on access restriction

Retrieve/read grant on access restriction

Update grant on access restriction

Delete grant on access restriction

Function

A user with this grant can create an new record. A user must have this grant to access the 'Create' object page through the URL. Grant to 'Create' implies that a user can add, or remove a details (while in the create mode).

can access the page linked to this access restriction

A user with this grant can update an existing record. Grant to 'Update' implies that a user can add, update, or remove a detail.

may delete an existing record (with its details)

The pages uses HTTP API resources (generic/specific) to perform DMLs and therefore, appropriate grants to GET (to view), POST (to create), PUT (to update), PATCH (to update), DELETE (to delete) operations must be granted on the resource, operations, sub resources and linked resource. See 'Security' in HTTP/API Concepts guide for details. OHI application take cares of these grants implicitly. Grant to a function code also grants access to api resources that are used by the page automatically.

Whenever an access grant for the page is provided to a user, an access grant to the required IP/API is automatically granted. However, exceptions to the rules is IP/API that allows user to perform certain restricted operations e.g. submitting a claim or policy.

It is possible to override this implicit API/IP grant that the user gets through function access, by configuring explicit grants through the user role. For example, a user that has access to the view the person page also gets automatic access to view the addresses through API. However, it is required that the user must not have access to the address at all then the following must be done

Remove the Address configuration from the floorplan
Create a more restrictive access grant for address API and assign it to the user role.

Function Access and Object List in Table

In a object list page the actions available to a user depends on the resource being displayed in the table - 1) a top level object or 2) a details object

Object list displaying a top level object

Access to 'Retrieve'

A user with this grant can view the object list.

Access to 'Update'

A user with this grant can update the object list. Grant to 'Update' implies that a user may add, update, or delete an top level object from the list when additional grants are in available. To be able to add or Delete top level object, addition grants are required along with the 'Update' grant.

Object list displaying a detail object

If the object list is an detail object shown using 'Object Navigation Links', then the function access restrictions of the top level object apply. For example, for contract alignments within the contract page, the function access for contract page applies.

Access to 'Retrieve'

A user with this grant can view the object list.

Access to 'Update'

A user with this grant can update the detail object list. Grant to 'Update' implies that a user can add, update, or remove an detail object from the list.

Setup

The setup of function authorization requires the following steps:

Access restrictions of type function are loaded into OHI during installation. No manual installation is required.
Define the access roles using the setup access role function, and assign access restrictions to each access role. Specify create, retrieve, update and delete flags for each access restriction.
Define roles in the external identity store. Note that the User Provisioning Service will match Access Roles using the code field. So make sure to enter the code of the OHI access role as an attribute of the role definition in the external identity store.
Create users in the external identity store and grant roles to them.
Provision the users to OHI by using the Provisioning Integration Point, described in the Integration Guide
The provisioned users now have access to the functions they are authorized for.

ACCESS RESTRICTIONS TO LOGIN TO OHI JET UI

Below are the common generic resources which the users may need to have the access restriction for, to login to JET application:

User Information IP
Current Properties IP
GET Access to Messages API (generic API)

Use Cases

This use case describes the steps to setup the Access Role 'Contract Pages Readonly' and 'Contract Pages Updateonly;

Define Access Role

CONTRACTS Read-Only Role

Create a new Access Role with following values:

Code = 'CONTRACT PAGES READONLY'
Name = 'Contract Pages Readonly'
Descr ='This role gives readonly access to contract page'

Create the following access restriction grants for this Access Role

Contracts
Specific and generic APIs listed in the contracts page UI

Only set the Retrieve? flag for these access restriction grants, not the Create?, Update? or Delete? flags.

Contracts Update-Only Role

Create a new Access Role with following values:

Code = 'CONTRACT PAGES UPDATE ONLY'
Name = 'Contract Pages Update Only'
Descr ='This role gives update-only access to contract page'

Create the following access restriction grants for this Access Role

Contracts
Specific and generic APIs listed in the contracts page UI

Only set the Retrieve? and the Update? flags for these access restriction grants, not the Create? or Delete? flags.

Setup External Identity Store and provision

Create the new Access Roles in the external identity store. Make sure to store 'CONTRACT PAGES READONLY' and 'CONTRACT PAGES UPDATE ONLY' respectively as an attribute of the new roles.

Assign the roles to users in the external identity store. Run the Provisioning Integration Point.

Access to OHI Application

Login to Oracle Health Insurance using a user that only has the CONTRACT PAGES READONLY role. This user only sees the contracts, its details including alignments and adjustments. All create, update and delete options in the pages are not available.

Login to Oracle Health Insurance] using a user that only has the CONTRACT PAGES UPDATE ONLY role. This user can update existing contracts and its details, for example, can add/update/remove alignments/adjustment overrides for existing contracts, can add/update/remove a dynamic field values for existing contract and its details, can add/update/delete calculation periods . This user is not able to add or delete contracts.