1 Entity Relationships and Permissions

1.1 Entity Relationships

The Access Portal Service implements the following relationships between the application policy and other policy entities, as illustrated below:

• Password Policy - a single password policy can be assigned to each application policy at a given time, or none at all.

• Credential Sharing Group - a single credential sharing group can be assigned to each application policy at a given time, or none at all.

• Credential - any number of credentials can be assigned to each application policy, or none at all.

The Access Portal Service implements the Credential_ApplicationPolicy relationship, which allows exactly one application policy to be assigned to each credential at any given time. A credential entity cannot exist without an associated application policy, as illustrated below.

The Access Portal Service implements the following relationships between the user entity and other entities:

• ESSOUser_Registry - exactly one user registry is permitted for each user.

• ESSOUser_SyncState - exactly one user synchronization state is permitted
  for each user.

• ESSOUser_SSOProvisioning - any number of provisioning instructions are permitted for each user, or none at all.

• ESSOUser_Credential - any number of credentials are permitted for each user, or none at all.

1.2 Entity Permissions

When either the Access Portal Service REST service or Logon Manager create the user wallet, the wallet's ACL is configured to allow that user to read, search, write, and compare entities within the wallet. These permissions are configured at the wallet level and inheritable by all objects stored within the wallet.

Each ACL for a policy entity contains the following keys policies ACL consist of two keys:

• AT_ProvisioningRights - defines the operations that the Provisioning Gateway server can perform to add, modify, and delete credentials.

• AT_Security - defines the access rights to the target policy.

The Enterprise Single Sign-On Suite Administrative Console can perform the following operations on the provisioning keys in the policy:

• AT_Security - set the ACL (orclaci) as defined by the key,

• AT_ProvisioningRights - Create an object of type ProvisioningRights under the CO. This is read by the Provisioning Gateway server to govern its operation.

The Enterprise Single Sign-On Suite Administrative Console operates on repository data in the user context, which allows us to allow the directory to filter and handle the rights for the AT_Security and ProvisioningRights keys.

The Access Portal Service REST service operates on repository data within the administrator context, preventing the use of the directory to filter and handle AT_Security rights. Because of this, the ProvisioningRights right must be maintained for the CO to allow create, update, and delete operations; no special rights are required for the read operation.

The Access Portal REST service can perform the following operations for AT_Security:

• READ - Using the AT_Security key defined for the policy, check whether the target user has the rights required to read the target policy; if the user does not have read access, do not return the policy in the request.

• CREATE - Update the ACL (orclaci) for the policy as defined by the AT_Security keys.

• UPDATE - Using the AT_Security key defined for the policy, check whether the target user has the rights required to update that policy.

• DELETE - Using the AT_Security key defined for the policy, check whether the target user has the rights required to delete that policy.

An ACL is configured for each individual policy entity. For example, a policy can be limited to read, write, search, and compare operations executed by members of a particular group - this would effectively limit access to that policy to only members of that user group.