Request and Approval Workflows

PAM provides the ability to associate workflows to users to request control which requires the approval from others before their request is enabled or their task can be executed.

Detailed Workflow topics and examples

Cases and scenarios

The following use cases and scenarios are covered when workflows are used in PAM.

Dual Control or Four Eyes: The concept of Dual Control (also known as Four Eyes or Peer Approval) is to prevent any one user from being able to access any system without the knowledge and consent of another. This type of secondary approval is often applied to Administrators themselves so that critical systems require extra approval in order to access grant access, unlock passwords or even execute tasks.

For example, a user should not be able to connect to the Active Directory Controller or unlock your Domain Admin password without the approval from the IT Manager or CSO.

One-time Access: This option provides a user the ability to request and to be approved one-time access for either a limited amount of time (60 minutes) or for a defined period of time (Saturday 6AM to Sunday 8PM). Once the time has expired, the user would need to once again request for that action.

For example, an outside contractor needs remote access to your internal server for maintenance or updates for the next 120 minutes or Thursday night after business hours.

Access Request: This provides the ability for users to access records, but requires that they provide a reason for needing access to the remote system or secret. The Approval user or group then decides whether to approve or reject their request for an action.

For example, an internal IT department member needs to unlock the password for the web server, but this action should only be granted when the IT director’s consent.

Emergency Access: Emergency or off-peak workflows can be configured to notify and request approval from a different set of approvers then what is configured for on-peak or business hours. This ensures that emergency access to critical systems or tasks can be executed without having to wait until your business opens the following day or week.

For example, a critical service goes offline during the weekend or holiday and a user needs immediate access to resolve the situation.

Delegate Admin Roles to Object Management: Configure workflow bindings and object permissions directly to container objects (vaults or folder) in order to delegate object management to a specific user or group without granting them access to the content of the container. By creating unique workflow bindings, the configuration, management or administrating of these objects can be delegated to non-Administrators within Access Manager.

For example, a user can manage the permissions and workflows of the Infrastructure vault without being given access to the content within it.

Approval Workflows

To further explain the Approval Workflows, it is important to understand their components.

Workflow: The workflow object itself can only created, modified or deleted by system administrators and consists of the following core components:
1. Templates: The workflow’s template contains the type of workflow, the steps (who approves the request) and the ranking of each principal (how many approvals are required to advance the workflow to the next step).
2. Bindings: The workflow’s binding is the association between a template (the process) and its principal (who, what and when) that will require approval to perform an action. The binding contains of the associated template, the associated user or group that will be assigned the workflow, the actions that will require approval and finally the time restrictions applied to the approval process.
3. Instances: The list of all active and completed workflows in the System. This includes who initiated the workflow, with which record, at what time and additional details.
Requester: The requester is the user who initiates a workflow by requesting an action like Connect or Unlock. The requester is associated to a workflow by being listed as a User in the workflow’s Binding.
Approver: The approver is the user who approves or rejects a step in the workflow. Approvers are defined in the steps of the workflow’s Template. If an Approver rejects a request at any step, then the workflow is immediately completed and the action is not granted to the requester.
Status: The current status of the workflow displays the current step as well as previous approval or rejection comments. The status is visible only to Requesters, current Approvers and System Administrators.
My Workflows: The area of PAM where Approvers will find workflows that require their approval and Requesters will find their list and details of active and previous requests.

Please note when designing your workflows, that a user may be binded to a workflow that also includes them in the template as an approver. This configuration is permitted; however, a user in this scenario will not be given the ability or opportunity to approve their own request. You cannot approve your own request.

Using workflows

Now that you understand the workflows and how they are constructed, it’s time to start using them. Please review these additional articles to learn about how to configure and use workflows in your environment.