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.
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.
- 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.
- 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.
- For example, a critical service goes offline during the weekend or holiday and a user needs immediate access to resolve the situation.
- For example, a user can manage the permissions and workflows of the Infrastructure vault without being given access to the content within it.
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:
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).
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.
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 the System 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.
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.
- How to create, assign, request and approve a workflow (Getting Started Guide)
- What are the Workflow Template Types
- What are Workflow Binding Actions
- How to request an action for yourself
- How to grant access to an action for another user
- How to approve or reject a request
- How to approve or reject a request by email response
- How to cancel your existing request
- How to cancel an approved request of another user
- How to update or delete workflows
- How to configure workflow binding time selectors
- How to configure a workflow binding duration
- How to configure a MFA token requirement
- How to configure Check Out
- How to create an auto-approved workflow
- How to associate a client IP address to a workflow
- Behavior Profiles
- What happens when my access request time expires?
- Designing Workflow Templates and Approval Processes