Data Access Restriction

Access to data in Policies needs to be restricted based on user authorizations for several reasons. These reasons include privacy (secret addresses) and user skill level. This document describes the features that are provided by the Policies data access restriction solution.

Concepts

This section describes general aspects of data access restrictions.

Data access restrictions are based on the use of access restrictions. An access restriction can be specified for a record or item of information to restrict access to it. Access restrictions behave as 'security labels' that can be attached to records. For example:

The person record of Bob could be labeled with the 'SECRET' access restriction.
The person record of Jane could be labeled with the 'TOP_SECRET' access restriction.
The person record of John could have no access restriction specified.

When an access restriction is specified for a record or other information item, that record or information item is said to be restricted. So if records had access restrictions as indicated above, both Bob and Jane would be restricted while John would be unrestricted.

Access labels are implemented as access restrictions of a certain type. For example, for person records, access restrictions of type 'Person details' are used.

See User Access Restriction Model in the Security Guide for a complete description of access restrictions and possible types.

A user can only access a restricted item when he has been granted access to the access restriction (via a role). For example, if only the 'SECRET' access restriction has been granted to user Philip, he can access the person record of Bob and John whereas he cannot access the person record of Jane.

The following diagram provides an overview of the end-to-end chain that gives a user access to a record of an Policies entity that is protected with an access restriction. The diagram is not a data model, but an example of the relations between types of records and objects.

The diagram shows the following:

The person record of Bob has access restriction SECRET attached. This means that this record is only accessible for users that have been granted access to this access restriction.
Access restriction SECRET is granted to access role SECRET_ROLE.
Access Role SECRET_ROLE is granted to user Philip, so Philip has access to records labeled with access restriction SECRET and thus can access the person record of Bob. Because only the Read? indicator is checked, Philip cannot change or remove the person record of Bob.

Related Entities

Records in Policies can be related to multiple detail records. For example: a person has attributes, but also has multiple addresses. In such a situation, the restrictions of the parent record cascade to the detail records; this also holds true for dynamic records: they behave as a child table. So when person Bob has access restriction 'SECRET', the restriction also applies to Bob’s addresses.

For each entity (record type) for which data access restriction is implemented, the restriction also applies to the related entities of that entity. Per restricted entity, the related entities are fixed. See the description of each restriction for its specific related entities.

Protected Items

Access restrictions can also be used to specify access to some groups of items (for example, several specific attributes of a record). An example is Non-Address Contact Detail Restrictions.

Setup of Access Restrictions

The type attribute of an access restriction defines where the access restriction can be used, that is, which type of records can be labeled with that access restriction.

The type attribute has a fixed list of values for each place in Policies where data access restriction is built in.

Table 1. Setup of Access Restrictions
Type	Usage	Reference Links
Address contact detail	Restrict access to a person address.	Address Contact Detail Restrictions
Attached data	Restrict the ability to modify attached policy data through ADF UI	Attached Data Restriction
Brand policy access	Restrict access to policies of a brand.	Brand Restriction
Data access group access	Restrict access to a group client configuration, a group account configuration or policies assigned to a data access group	Data Access Group Access
Date Paid To	Restrict the ability to modify the date paid to on the attached data	Date Paid To Restriction
Dynamic Field Usage	Restrict access to dynamic field and record usages	Data Access Restriction
Function	Restrict access to a UI page.	Function Access Restriction Function Access Restriction
HTTP IP	Restricts access to integration points and operations
HTTP API	Restricts access to generic api	For details refer to HTTP API Data Access Restrictions chapter in the Security Guide.
Identifier Type	Restrict access to Identifiers of a relation, provider or policy	Identifier Type
Item	Restrict access to an item (field or button). NOTE: Individual items do not support access restriction by default. Access restriction on item level has to be added using UI customization.
Line of Business	Restrict access to a group client, group account, policy, enrollment product or relation based on those item’s Line of Business	Line of Business
Non-address contact detail	Restrict access to non-address contact details of a person.	Non-Address Contact Detail Restrictions
Macro	Restricts the execution of a macro	n.a.
Pend resolution	Restrict resolution of pend reasons	Pend Resolution
Person details	Restrict access to a person.	Pend Resolution
Policy Enrollment Event	Restrict access to the change details JSON objects	Policy Enrollment Event
User Credentials	Restrict retrieval of the userLogin and alternate_user_id in the context of a user.	User Credentials Restriction
Update Request Payload	Restrict retrieval for the 'payload' within the policy update request
Enrollment Event Notification	Restrict access to the change details JSON objects

For each restriction type, multiple access restrictions can be defined. It is not possible to define an access restriction that applies to multiple restriction types. So when the Address restriction type and the Person restriction type both should have an access restriction 'Secret', two different access restrictions need to be defined. See the following table for an example:

Table 2. Example
Restriction	Access Restriction Code
Address Contact Detail	ADSECRET
Person Details	PERSECRET
Person Details	VIP

Granting Access Restriction or CRUD Matrix

Access restrictions are assigned to roles using an access restriction grant. In an access restriction grant, Create, Retrieve, Update and Delete (CRUD) indicators can be set. The CRUD indicators in general have the following meaning:

Create - Records protected by the access restriction can be created by the users with the role. In addition, existing records can have the access restriction applied to them by the users with the role.
Retrieve or Read - Records protected by the access restriction can be seen by users with the role.
Update - Records protected by the access restriction can be updated by the users with the role.
Delete - Records protected by the access restriction can be deleted by the users with the role.

Granting of create, update and/or delete rights without retrieve rights is not allowed. If none of the CRUD rights are selected, the grant on this Access Restriction is effectively disabled.

The record to which the access restriction is directly linked is not always part of the records protected by the access restriction. In particular in setup pages, users with the right to create or update records in that page will also have the right to link an access restriction, without explicit CRUD grants on that access restriction. For operational data like Persons and Addresses, stricter rules apply.

The following table (the "CRUD Matrix") lists per access restriction type what the CRUD indicators mean, for several types it deviates from or extends the general meaning:

Table 3. Granting Access Restriction or CRUD Matrix
Type	Create Grant	Retrieve (Read) Grant	Update Grant	Delete Grant
Address Contact Setail NOTE: only applies to Addresses of Persons, not of Organizations	May link an access restriction of this type to an Address	Can query Addresses with this access restriction and no concealing of Addresses with this access restriction in the New Policy page, View and Edit Policy page, Members Search and View Member page	May update Addresses with this access restriction, including the access restriction itself (may change it to another access restriction if create rights on that access restriction)	May delete Addresses with this access restriction
Attached Data	Not used	Not used (but has to be set to make this grant apply)	May modify attached data of a policy	Not used
Brand Policy Access	May link a Brand with this access restriction to a Policy	Can query Policies that are linked to Brands with this access restriction	May update Policies that are linked to Brands with this access restriction, including insert/update/delete of (grand)child entities shown in the View and Edit Policy page	May delete Policies that are linked to Brands with this access restriction
Data Access Group Access	May link a Data Access Group with this access restriction to a Group Client, a Group Account or a Policy.	Can query Group Client, Group Accounts or Policies that are linked to Data Access Groups with this access restriction.	May update Group Clients, Group Accounts or Policies that are linked to a Data Access Group (old Data Access Group in case that field is being updated) with this access restriction, including insert/update/delete of (grand)child configuration entities	May delete Group Clients, Group Accounts and Policies that are linked to Data Access Groups with this access restriction
Date Paid To	Not used	Not used (but has to be set to make this grant apply)	May modify date paid to on the attached data of a policy	Not used
Dynamic Field Usage	May create dynamic records of the specified usage	No concealing of non time valid dynamic fields of the specified usage. Time valid dynamic fields and dynamic records of the specified usage are shown	Contents of dynamic fields and records of the specified usage may be updated.	May delete dynamic records of the specified usage
Function	May create new rows in the page linked to this access restriction (regardless of the entity for which a new row is created)	Can access the page linked to this access restriction	May update rows in the page linked to this access restriction	May delete rows in the page linked to this access restriction (regardless of the entity for which a row is deleted)
HTTP	May access the integration point Note - In order to provide access grant, all flags must be set to true
Item	Reserved for site level UI customizations	Reserved for site level UI customizations	Reserved for site level UI customizations	Reserved for site level UI customizations
Line of Business	May link a Line of Business with this access restriction to a Group Client, a Group Account, a Policy, or Enrollment Product	Can see group clients, group accounts, policies, and enrollment products for a line of business with this access restriction Can see enrolled relations and policyholders on a policy for a line of business with this access restriction Can see contact relations and insurer’s reference persons on a group account or group client for a line of business with this access restriction	May update group clients, group accounts, policies, and enrollment products for a line of business with this access restriction May update enrolled relations and policyholders on a policy for a line of business with this access restriction May update contact relations and insurer’s reference persons on a group account or group client for a line of business with this access restriction	May delete group clients, group accounts, and enrollment products for a line of business with this access restriction
Non-address Contact Detail	May link an access restriction of this type to a Person	Can see non-address contact attributes of Persons with this access restriction	May update non-address contact attributes of Persons with this access restriction and may remove the link of a Person to this access restriction (may change it to another access restriction if create rights on that access restriction)	Not used
Identifiers Type	May create identifiers of the specified usage	May query restricted identifiers	Identifiers may be updated	May delete identifiers
Pend Resolution	Not used	Not used (but has to be set to make this grant apply)	May resolve pend reasons that are attached in a process step with this access restriction	Not used
Person Details	May link an access restriction of this type to a Person	Can query Persons with this access restriction and no concealing of Persons with this access restriction in the New Policy page, View and Edit Policy page, Members Search and View Member page	May update Persons with this access restriction, including insert/update/delete of child entities shown in the Persons page, and including the access restriction itself (may change it to another access restriction if create rights on that access restriction)	May delete Persons with this access restriction
Policy Enrollment Event JSON access	Not used	Restrict access to the change_details attribute that contains a JSON representation with detailed information about the changed data	Not used	Not used
Process Flow Access	May link an access restriction of this type to a Process Flow	Can query Process Flow with this access restriction and no concealing of data with this access restriction in Setup Policy Process Steps,Setup Group Client Process Steps, Setup Policy Pend Rules, Setup Policy Callout Rules, Setup Policy Validation Rules and Setup Group Client Validation Rules	May update Process Flows with this access restriction, including insert/update/delete of child entities shown in the Setup Policy Process Steps and Setup Group. Also may update the data in Setup Policy Pend Rules, Setup Policy Callout Rules, Setup Policy Validation Rules and Setup Group Client Validation Rules when they refer to this Process Flow	May delete Process Flows with this access restriction
User Credentials	Not used	concealing of LoginName and alternate_user_id in generic users http API	Not used	Not used
Update Request Payload	Not used	Concealing of payload in generic policy update request http API	Not used	Not used
Enrollment Event Notification	Not used	Concealing of payload and request headers in generic enrollment event notifications http API	Not used	Not used

The following table gives an example setup for two Address access restrictions: SECRET and TOP_SECRET and how the CRUD indicators are set for three different roles.

Table 4. Example Setup
Address Access Restriction	Role 'Secret Read Only'	Role 'Secret'	Role 'Top Secret'
SECRET	R	CRUD	CRUD
TOP_SECRET	not granted	RUD	CRUD

Based on this example setup, the following table shows the different actions these roles can perform using these access restrictions:

Table 5. Different Actions Roles can Perform
Action	Possible for Role 'Secret Read Only'?	Possible for Role 'Secret'?	Possible for Role 'Top Secret'?	Possible for Other Role?
Create address without access restriction	yes	yes	yes	yes
Retrieve address without access restriction	yes	yes	yes	yes
Update/Delete address without access restriction	yes	yes	yes	yes
Create address with access restriction SECRET	no	yes	yes	no
Retrieve address with access restriction SECRET	yes	yes	yes	no
Update/Delete address with access restriction SECRET	no	yes	yes	no
Create address with access restriction TOP_SECRET	no	no	yes	no
Retrieve address with access restriction TOP_SECRET	no	yes	yes	no
Update/Delete address with access restriction TOP_SECRET	no	yes	yes	no

Implementation in Entities: Access restrictions are implemented as standard single value attributes.
Usage in Pages and Interfaces: Because access restrictions are implemented as standard attributes, they can be set by interfaces and regular screens like any other standard attribute. In screens, users can only save an access restriction for an access restriction attribute if they have one or more roles that gives them 'Create' access rights for that access restriction. In other words, to be able to label a new or existing record with a specific restriction, a user must have 'Create rights' for the restriction. Through interfaces, no such restrictions apply, interfaces don’t need 'Create' access rights to set an access restriction.

When a record with an access restriction is accessed via a screen, the name of the current access restriction is shown in the inline overflow to inform the user of the security level of the record. In addition, a security indicator is shown in the table row to indicate the presence of an access restriction.

Implementation

For restriction types that restrict access to the whole record, restriction of access is implemented in two different ways, depending on the type of access:

Restricted records may be completely hidden from users without read access. This implementation applies when the restricted records are accessed directly. For example, person records can not be seen at all by users without access to them from person search functions.
The attributes of restricted records may be concealed. This implementation applies when the restricted records are accessed indirectly as in when they are referred to from other records. For example, policies of these restricted persons could be visible to users who cannot find the person directly; in this case the relation details would be concealed.

The restriction not only applies to the entity itself, but also to the related detail entities. For example: a reference to a bank account number of a restricted person is also concealed.

The restrictions are implemented consistently throughout the whole Policies. For example, LOV’s are also restricted.

A restriction also applies to the dynamic fields defined for that entity. So when access to a record is restricted, access to the dynamic fields of that record is also restricted.

An attribute is concealed by displaying '**' in the field.

For restriction types that restrict access to a subset of attributes of the restricted record (like Non-Address Contact Detail restrictions), restricted attributes also display '**' in the field. This is done whether the attribute actually has a value. Therefore, users will not know if a value is actually present or not.

Inference Prevention: It should not be possible to infer concealed values. For example, if Person Bob has a restricted address with postal code 1234, this address is not to be shown to users that do not have rights for the address. This also applies indirectly, for example, when searching for relations with postal code 1234. Bob must not be found as this would reveal Bobs address. The prevention of inference differs per restriction and is indicated in the 'Inference Prevention' part of the description of each restriction.

Restriction Type-Specific Aspects

This paragraph describes each specific restriction type. Note that an entity can be subject to multiple restrictions. For example, a policy is subject to restrictions imposed by the access restrictions defined in a data access group and the access restrictions defined on the Brand. When an entity is subject to multiple restrictions, all involved access restrictions must be granted to a user to gain access to that entity.

Example:

Policy 1234 has brand 'VIP Brand' and access data access group code 'Company ABC'.
The brand 'VIP Brand' has access restriction 'VIP_BRAND'. The data access group 'Company ABC' has access restriction 'SECURED_COMPANY'.
For a user to be able to access policy 1234, both access restrictions 'VIP_BRAND' and 'SECURED_COMPANY' must be granted to the user.
Protecting Sensitive Information
Permitted Work Restrictions (General): These features cover broad filtering of data from users that simply don’t need access to it. For example, this could apply where a separate group of users works on policies of specific data access groups and they have no need to access policies from additional data access groups.