Skip to main content

Mapping participants for authorization

Currently, participant mapping is required where user classes are used to define the function of policy participants.

Participant mapping uses user classes to define complex relationships by mapping the policy participants (recipient, requester, authorizer) to the user class participants :

  • User class participants – In personal user classes, the participant defines something about a user, such as their location. For example, the class NEW_YORKER which has a single participant named “RESIDENT”.

    In relational user classes, the participants define the relationship between users. For example, a default user class that ensures one user is another user’s manager, _MANAGER_DIRECT_, has two participants: SUBORDINATE and MANAGER.

    With both types of user class participants, the function for each participant is undefined. These user classes can be used with any policy. For example, they can be used when defining authorizers.

  • Policy participants – define the function for each user in the current policy. For example, the recipient, the requester and the authorizer of a request are all possible policy participants.

Personal user classes require you to map the single user class participant. Relational user classes require you to map one or more policy participants.

This functionality is highly flexible and there are many configuration possibilities depending on which user classes you select and how you map their participants. However, all valid configurations require an authorizer.

For example, when defining an authorizer using user classes, you could define the relationship between the AUTHORIZER, REQUESTER, and RECIPIENT. The policy participants determine who authorizes (AUTHORIZER) whose request (REQUESTER) on behalf of whom (RECIPIENT). To define membership for each policy participants, map user class participants to each policy participants.

To configure participant mapping:

  1. Navigate to the Authorizer user classes tab of the resource for which you want to configure authorizers.

    For example:

    • Managed groups > <group> > General

    • Segregation of duties rules > <rule> > Authorization

    • Managed system policies > <policy> > Authorizers: <type>

  2. Click the User classes sub-tab.

Use Case 1: Manager must approve requests

This use case ensures that a user’s manager must authorize requests before the user can receive access for a resource, regardless of who makes the request. This case involves two participants: the recipient and the authorizer. The requester is irrelevant in this case.

The default _MANAGER_DIRECT_ user class can be used to define the required relationship between the recipient and the authorizer.

Participant mapping

  1. Navigate to the Authorizer user classes page.

  2. Add the default _MANAGER_DIRECT_ user class and configure mapping as follows:

    • MANAGER: Authorizer

    • SUBORDINATE: Recipient

Use Case 2: Printer access must be approved by a user’s manager

In this use case, business rules require that a user’s manager must request access to printers on his behalf. For example, Joe wants access to a printer and speaks to Bob, his manager. Printer access is managed by membership to a managed group. Bob issues the request. Additionally, business rules require that Bob’s manager must authorize the request.

Participant mapping

  1. Navigate to the Authorizer user classes page.

  2. Add the default _MANAGER_DIRECT_ user class and configure the mapping as follows:

    • MANAGER: Requester

    • SUBORDINATE: Recipient

    This ensures that requests are being performed by the recipient’s manager.

  3. Add a second _MANAGER_DIRECT_ user class and configure the mapping as follows:

    • MANAGER: Authorizer

    • SUBORDINATE: Requester

    This ensures that the authorizer is the requester’s manager.

  4. Configure the user class matching as follows:

    • The participants have to match which of the user classes : All of the user classes

Use Case 3: Department head must authorize all requests for a high security resource

This use case ensures that a user’s department head must authorize all requests for access to a specific high-security resource.

This case involves two participants: the recipient of the request and the department head who must authorize the request.

User class configuration

Create and configure a new user class to define the relationship:

  1. Create a new user class named DEPARTMENT_HEAD.

  2. Create Participants :

    • DPT_HEAD: The head of the department

    • DPT_MEMBER: A member of the department

  3. Configure Criteria:

    • Group criteria: Since all department heads are members of the Department Head group, add a group criteria requiring that the DPT_HEAD participant is a member of the "DepartmentHead” managed group:

      • Participant: DPT_HEAD

      • Membership: Required

      • Target System: AD

      • Group: CN=DepartmentHead,OU=Company,DC=domain,DC=net

    • Attribute criteria: In order to target the department head, add an attribute criteria to ensure that the DEPARTMENT profile and request attribute is the same for both the user and the department head:

      • Participant : DPT_HEAD

      • Attribute : DEPARTMENT

      • Participant’s value must equal the value of this other participant : DPT_MEMBER

Participant mapping

  1. Navigate to the Authorizer user classes page.

  2. Add the new DEPARTMENT_HEAD user class and configure the mapping as follows:

    • DPT_HEAD: Authorizer

    • DPT_MEMBER: Recipient

In this section: