Product authorization service

Gatekeeper uses a configurable permission manager for fine grained access control (role based authorization). This authorization layer controls access of the various types of users to specific operations and implements resource-based access control (RBAC). One of the typical resources is the Gatekeeper scope.

Each operation represents the most granular action that a user can do in the system. Operations are associated with a specific API method, web page in the web application, or action (such as listening to audio and downloading audio).

A role is a collection of permission rules. When you assign a user (or groups of users) to a role, you grant permission to perform the operations of that role. Roles are either defined at the scope level or at the system level. Using roles, the biometrics system determines whether a process or a user is privileged to perform an operation on a specific scope or at the root level. When you set up the scope for a new tenant, the system applies default factory roles and permissions, which you can change. Sample factory roles are as follows:

  • GatekeeperAdmin - Not available for cloud users. The super user that has read and write permissions to all resources (including configuration parameters, all API methods, and the Gatekeeper web application).
  • ScopeAdmin - Scope administrator that has read and write permissions to all the scope’s resources.
  • WebUserReadOnly - Web user that has read permissions in the Gatekeeper web application.
  • CallCenterAnalyst - The call center supervisor that has read and write permissions to the web pages in the Gatekeeper web application that manage persons and engagements.
  • CallCenterAgent - The call center agent that has read and write permissions to the web agent console only (WAC).
  • FraudAnalyst - Web user that has read and write permissions to the web pages in the Gatekeeper web application that manage persons, fraudsters, watchlists, and engagements.
  • BusinessAnalyst - Web user that can access and generate Gatekeeper reports.
  • ClientApplication - The role used by the service that invokes Gatekeeper operational API methods.
  • ConfigOperationalReadOnly - Allows viewing the configuration.
  • AuthorizationAdmin - A role that allows access to authorization page only.
  • AccessToMedia - A role that allows access to play, view, and download media.
  • Datashare - A role that allows sharing of fraudsters with others customers (bilateral).

For API methods that manage roles, operations, and users, see Authorization Manager.

Product Operations

There is an operation for each unary API method (except for API methods that handle calls from a contact center).

Operation groups

Operations are categorized into groups. Use a wildcard ([groupname].*) to permit all operations in a group. (This might be faster than specifying individual operations.)

Permission rules

A role can contain a set of rules where each permission rule combines allowed and denied operations. These are most useful for future flexibility to inherit permissions when new operations are added in the future.

For example, if you add a SystemR.* rule to the allowed rules and SystemR.ListTemplates to the denied rules, you give permission for all operations in SystemR, excluding the ListTemplates operation. If an operation is added to a group in the future (for example during an upgrade), all users with the wildcard ([groupname].*) in the allowed or denied operations list inherit the new operation accordingly.

Types of users

The following subsections describe the supported user types.

End users and groups of users

End users (also called interactive users) include agents that use the Web Agent Console, Gatekeeper web application users, fraud analysts, and Kibana reporting users.

The tenant specific IdP is responsible for managing these users. Gatekeeper integrates with different IdPs through OpenID Connect and can optionally receive additional claims from the IdP about the groups that this user is a member of. This allows assigning an IdP group to a Gatekeeper Role to simplify the administration. User authentication is handled entirely by the web browser and the IdP through OpenID Connect. A typical example of such an integration is Azure AD Connect or AD FS, where ActiveDirectory group membership is exposed through groups claim. The group claim in Azure AD can either be a user-friendly name or a long identifier. If the claim is a long identifier, query the /userinfo endpoint to fetch the identifier.

Service principals

Automated and non-interactive client applications obtain authorization tokens using the OAuth 2.0 client credentials grant. The process does not involve an end user and does not depend on the IdP. The application acts as a service principal (service user). Similar to the way it handles end users, Gatekeeper allows controlling the service principal’s permissions.

This means that service principals are assigned roles and their permissions derive from the list of operations associated with those roles. The client application must provide an access token to get access to runtime API methods. The token expires after about 15 minutes, and (depending on the application design) must be regenerated near its expiration time or upon receiving HTTP 401 status. Use the client ID, secret, and client scope provided by Nuance to generate an authentication token.

For more details see Client Credentials  .