Users and Groups

ActivID AS offers powerful and flexible user management tools.

End users are your customers or employees that are identified and authenticated with ActivID AS.

Direct and Indirect Users

All ActivID AS users can be classified as either direct or indirect users. However, when administrators create users in ActivID AS, they are not categorized specifically as either direct or indirect users.

The distinction comes into play when the user is authenticated by ActivID AS. There are distinct API calls for direct and indirect user authentication. Also, direct users must be assigned pre-defined permissions in order to be authorized to call ActivID AS services. Indirect users do not make use of ActivID AS services and do not need to be assigned pre-defined permissions.

  • Direct users − Direct users are people or entities that connect directly to ActivID AS through APIs or through the ActivID Management Console. For example, operators and administrators who log on to the ActivID Management Console are direct users. Also, an internet banking server is a direct user when it uses an ActivID AS authentication service exposed through the public API to authenticate a customer.
  • Indirect users − In most cases, indirect users are end users, such as an organization's customers. Indirect users do not make direct use of ActivID AS services. They are authenticated to or managed by applications which themselves authenticate as direct users in order to obtain certain permissions. For example, a call center agent (direct user) can verify a customer’s identity (authenticate) via the ActivID Management Console.

The purpose of the Direct and Indirect user model is to maintain a clear delineation between users that have permissions and authorization to make direct API calls to the authentication server (Direct Users) and users that do not (Indirect Users). Simply, end users should not have authorization to make API calls to ActivID AS directly.

User Types

User Types and user Administration Groups make it easy to manage users within a hierarchy of groups. The combination of User Types and Administration Groups enables the separation of users that have very distinct characteristics. The sub-groups within the User Type groups are called Administration Groups. Administration Groups provide a way to partition users for administrative purposes.

Installing ActivID AS automatically sets up a number of User Types. For each User Type, there are pre-defined system users. Collectively, these sample users have all the permissions required to fully administer the system. You can use the base data set as provided during installation, or modify it to meet your specific requirements. In addition, permissions can be assigned to users through membership in Administration Groups, as an alternative to assigning permissions through roles. Individual users can belong ONLY to a single Administration Group. For example, an operator registered as a user in the “operators” Administration Group (within the operators category), cannot be registered as a user in the “IT” Administration Group.

Note: Individual local database users can belong only to a single administration group. For LDAP users, they can belong to multiple groups based on the LDAP/Admin Groups mappings.

Administration Groups

You must register new users within Administration Groups. You cannot register users directly to a User Type. Each user must belong to one and only one Administration Group. However, you can move a user between Administration Groups, within the same User Type. You cannot move a user to an Administration Group within a different User Type. When you create an Administration Group, you select a parent for it. The parent can be the User Type within which you are creating the Administration Group, or another Administration Group within the same User Type.

Administration Groups are defined by: User Type, Parent Group (if there is one), Name, Code, Description, Repositories (subset of the set of repositories associated to User Type, and Branch), and Eligible Authentication Policy.

Important: For ease of administration and increased security, do NOT set up User Types that contain Administration Groups with both direct and indirect users in those groups. Plan to keep direct and indirect users separate. Place direct and indirect users into their own User Types.

User Repositories

This section describes how ActivID AS uses multiple data sources as user repositories. In a typical deployment scenario, users requiring authentication and authorization services can be stored externally or internally.

  • Internally − In the ActivID AS local database. The local database securely stores configuration, policies, devices, credentials, and audit data.
  • Externally − In LDAP directories, an Oracle Directory Server, a Microsoft ActiveDirectory, a Novell eDirectory, or legacy repositories. ActivID AS supports out-of-the-box ActiveDirectory and Novell eDirectory. Multiple external repositories can be added. Each external user repository is managed by a Datasource Adapter.

ActivID AS can store users in its own internal data source (user repository). Also, it can leverage external user repositories (it is not possible to create users in the external user repository from the ActivID Management Console).

You can add as many external repositories as needed. They can be of different types. The only constraint is that the user IDs must be unique across multiple directories. Each directory can have its own unique ID attribute (for example, sAMAccountName for an Microsoft ActiveDirectory, and uid for a Novell eDirectory).In a configuration scenario with a Microsoft ActiveDirectory, a user with the name: sAMaccountName=johndoe cannot have a uid=johndoe in a Novell eDirectory.

External user repositories (for example, LDAPs) are bound to ActivID AS through mappings. Mappings are done within Administration Groups and specific nodes of LDAP directories. The following list describes the procedures required to establish mappings.

  1. Create and configure an external User Repository.
  2. Assign the external user repository to one User Type.
  3. Map specific branches of that user repository to an Administration Group belonging to the User Type to which the user repository has been assigned.

An LDAP User Repository can be leveraged for Authentication and Authorization. For more information on mapping external user repositories and on performing LDAP authentication/authorization, see Configure User Repositories.