Permissions, Roles and Assets

This section provides an introduction to the ActivID AS concepts of Permissions, Roles and Assets.

About Permissions

A permission is essentially a “privilege” that permits an operator/administrator or system to perform a specific function in ActivID AS.

The permission can be as simple as “Create User” which is a single function (for example, add a new user to an Administration Group).

“Permission Sets” are a group of these “privileges.” There are internal permissions and external permissions.

• Predefined internal permissions cannot be changed or removed. However, from the ActivID Management Console, you can group internal permissions into “sets” to simplify the task of assigning pre-defined permissions.
• You can create, modify, or delete external permissions using the ActivID Management Console.

The permissions to carry out certain ActivID AS functions are not restricted for use with a specified Administration Group. Examples are the permissions in the permission set “Create external transaction set” and “Update external transaction set”.

Permission sets are not restricted when they contain only unrestricted permissions.

Permission sets associated with roles and assigned to individuals always have the status “Enabled” and cannot be set to “Blocked”. For more about roles, see the next section.

You can prevent an individual user from carrying out a particular function in a permission set associated with a role assigned to that user. To do so, assign the permission for the individual function to the individual user and set the status to “Blocked”.

Assigning Predefined Permissions

There are three methods that can be used to assign predefined permissions:

• Assign a Permission set to an administration group - gives all the users in the group the permissions in the set
• Associate a Permission set with a role, and assign the role to an individual user (in the case of a local database user) - gives the individual user the permissions in the set
• Associate a Permission set with a role, and assign the role to an LDAP Group or Branch/Organizational Unit (in the case of an LDAP user) - gives all the users in the LDAP Group or Organization Unit the permissions in the set
• Assign elementary permissions to an individual user - a user will automatically inherit the permissions assigned to his administration group. However, high-level permissions granted only to a few users will be granted through a role, or direct user assignment of the permission

An exception to the permission assignment rule is when an External permission related to assets can be assigned to a user directly.

Permissions can also be restricted for use with a specified Administration Group or Asset Type.

Others might be restricted to specific Assets Resources on which permissions can be granted. For example, specific user bank accounts. or Asset Sets Group of Assets of the same Asset Type.. This is referred to as the “resource” type of the permission. For example, when a user attempts to perform an action in the ActivID Management Console, this action will only be allowed if it is on the specific resources defined in the permission assigned to him.

The resource type to be assigned depends on the Permission Type.

Permission Restrictions

When a direct user attempts to carry out a function, the ActivID AS checks to make sure the user has the necessary permissions to perform the function. Depending on the type of function, the permission can be qualified either by the user Administration Group or asset group, or it can have no qualifier. For example, the permission required to create a new administration user enables the administrator granted the permission to add a new user to an Administration Group. Assigning this pre-defined permission includes specifying a particular Administration Group to which the new user can be added.

For example, by using the ActivID Management Console, a direct user − who has the pre-defined permission for use with an Administration Group called “Classic Customers” − will be able to add a new user only to the “Classic Customers” Administration Group, and not to any other Administration Groups.

Some pre-defined permissions are not restricted for use with a specified Administration Group. For example, the permission for the “Create permission set” function enables the permission holder to group functions into sets. This facilitates assigning pre-defined permissions to indirect users.

Permission Combinations

To fully complete a task, direct user might need permissions for a combination of functions. For example, the permission for the function “Search users” enables a search of all the users to find those matching given criteria. However, to display the details of a particular user found as a result of a search, the permission for the function “Read user details” is required. In addition, the permission for the function “Read user details” is restricted for use with a specified Administration Group.

Suppose a direct user has predefined permissions for the “Search users” and the “Read user details” functions. The permission for the “Read user details” function is restricted for use with an Administration Group called “Classic Customers.” A search is carried out, and ActivID AS returns a list of user records matching the search criteria. The searcher will only be able to display the records of users in the “Classic Customers” Administration Group.

Similarly, the permission for the function “Search devices” enables a search of all the devices to find those who match the given criteria. To display the details of a particular device found as a result of a search, the permission for the function “Read device details” is required. The permission for the function “Read device details” is not restricted for use with a specified Administration Group.

The permission for the “Read reference data” function enables the content of the ActivID Management Console list boxes to be read. The function is not restricted for use with a specified Administration Group.

Important: Direct users within the ActivID Management Console always require the permission for the “Read reference data” function.

Permission Authentication Policies and Channels

When you assign predefined permissions to an Administration Group, associate a permission set permission with a role, or assign an individual pre-defined permission to an individual user, you also assign the authentication policy required by the user(s) to gain the permission.

Examples of ‘Permission Set’ Permissions

Permissions Sets can be assigned to an Administration Group or associated with a single role. “Permission Set” permissions assigned to Administration Groups or associated with roles and assigned to individual users always have the “Enabled” status. If you do not want a specific individual to carry out a specific permission within a “Permission Set” then you can disable the permission by blocking it for that user.

• Assigning a permission set to an Administration Group gives all the users in that Administration Group the permission to carry out each of the functions in the set, provided that they are authenticated with the designated authentication policy. The permission is generally restricted for use with a specified Administration Group. In other words, a direct user who is a member of the group to whom the permission has been assigned and has logged on with the specified authentication policy, may carry out all functions in the set on users in the designated group in addition to the permissions inherited from parent groups.
• Assigning a permission set to a role, and then assigning the role to an individual user gives that individual the permission to carry out each of the permissions in the associated permission set. The permission is generally restricted for use with a specified Administration Group.

Permissions for an ‘Asset Type Permission Set’

Associating an Asset Type Permission Set with a role, and assigning the role to an individual user, gives that individual the permission to carry out each of the permissions in the associated permission set for each of the assets in a specified Asset Type.

An Asset Type Permission Set is always restricted for use with a specified asset group. Permissions included in these sets are associated with roles, assigned to individual users, and always have the status “Enabled.” They cannot be set to “Blocked.” That is, you cannot prevent an individual user from carrying out a specific permission in an Asset Type Permission Set that is associated with a role that is assigned to that user.

External Permissions

External permissions represent permissions on operations (external transactions) carried out on an 'external' asset (or any system other than ActivID AS).

External permissions are created to model a specific operation/activity. When there is a requirement to create and store a “permission” (also known as a rule), so that only specific “roles” with a specific set of permissions can perform that specific activity, you create an “external permission.”

External permissions can be grouped into “External Permission Sets” to simplify administration. A specific external permission can be used in multiple External Permission Sets.

User-Level Policies (for External Permissions)

ActivID AS can be used to manage user-level policies that define a user’s authority to execute specific sets of external permissions on specific assets. User-level policies are created by assigning “asset permission sets” to users.

Permissions are conditionally based on a specific authentication policy and channel. The user is authorized to execute external transactions over only the designated channel − and only provided that the user is authenticated with the designated authentication policy.

ActivID AS serves three purposes:

• It provides a secure store for the policy and restricted access to maintain that policy.
• It provides a set of services that enable an external system to query the policy.
• It provides an authorization service that returns a “permit” or “deny” response for a requested transaction.

Risk-Based Authorization Policies for External Transactions

Each asset transaction-set permission is dependent on a defined authentication policy. This enables an organization to use ActivID AS to manage risk-based authorization policies. External Transactions that have a relatively low associated risk can be authorized based on relatively weak authentication, while more risky external transactions require stronger user authentication.

External Transaction Risks (High, Medium, Low)

For example, withdrawing funds from an account is viewed as a higher-risk external transaction than viewing an account balance. Therefore, a policy can be created that permits a customer to view the account balance based on a static password, but requires two-factor authentication to withdraw money from an account.

About Roles

ActivID AS roles represent relationships that users have with an organization. For example, the relationship between a direct user, such as a help desk operator, and an organization can be based on the position the direct user holds within the organization. The relationship of an indirect user, such as a customer, can be based on a commercial or legal agreement with the organization.

Such relationships imply certain authorities or permissions. For example, the call center operator would need the authority to maintain customer passwords. A customer would need the authority to perform transactions on his or her account.

Associating a permission set with a role and assigning the role to an individual user gives that individual the permission to carry out each of the permissions in the associated permission set. Usually, the permission is restricted for use with a specified Administration Group.

You can create a role to represent a relationship, associate the role with the relevant permission sets, and then assign the role to an individual user. Assigning the role gives the individual user the permission to carry out the permissions in the associated set.

One user can have many roles and one role can be assigned to many users. Permissions assigned through a role can be blocked by creating a blocking permission at the level of the individual user.

In some respects, roles are similar to administration groups in that they provide a mechanism to assign groups of permissions to a user. There are, however, a few major differences:

• A database user must be in one and only one administration group, whereas a user can be assigned one or many roles.
• Assigning a user to a role has no impact on who is permitted to administer that user, whereas it is a user’s administration group membership that determines who has administration rights over that user.

Roles for LDAP Users

LDAP users can inherit permissions linked to a specific role when the user belongs to:

• A specific LDAP branch (for example, Organizational Unit), or
• A specific LDAP group.

For example, a Helpdesk Role can be mapped to all users who are a part of the “Helpdesk” group of a ActiveDirectory and all users who are a part of the ou=IT, ou=people, dc=mycompany, dc=com of a Novell eDirectory

You can perform such configuration tasks from the ActivID Management Console under the User Repositories tab. You can enable the assignment of a role to an entire branch of a specific LDAP directory or to all the users belonging to a specific LDAP group.

About Assets

An asset is something upon which an action (also known as an “external transaction”) can be performed.

For example:

• A bank account is an asset from which funds can be withdrawn (the external transaction).
• A medical record is an asset that can be updated with new patient information (the external transaction).
• A smart card or a driver’s license is an asset to which new data, credentials or applications can be added.

Assets are managed at three levels that determine the permissions that can be assigned:

Level	Description
Asset Types	A means of categorizing the different business assets. For example, you can create an Asset Type for each category of banking account (that is, mortgage, checking, savings, credit card, current...). Asset Types are then referenced as resources of Predefined permission sets Group of default elementary permissions. when they are assigned to an ActivID AS user via their role or administration group. For example, operators can be assigned permissions to modify the transfer conditions for a specific category of bank accounts.
Asset Sets	Created within Asset Types to allow assigning permissions to multiple individual assets. For example, you can create an Asset Set to group all the current accounts of a banking agency for a region. Asset Sets are then referenced as resources of External permission Permissions on operations perfomed on assets 'external' to the ActivID AS system. sets when they are assigned through a user’s role or administration group. Bank employees can be assigned the permission to modify transfer conditions for a specific list of bank accounts.
Assets	An asset is a resource on which permissions can be granted, such as specific user bank accounts. Before registering an asset, you must create an Asset Type. Then if Asset Sets are created within the Asset Type, the assets can assigned to one of the sets. Once created, assets can be referenced as resources of External permission Permissions on operations perfomed on assets 'external' to the ActivID AS system. sets when they are assigned directly to a user. For example, a user can be assigned the permission to draw funds from his account.

You can manage assets (and asset groups) through the ActivID Management Console or through the Public API.