Request and Approval Workflows
XTAM 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 XTAM.
- 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.
- 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.
- 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.
- 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.
- 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 XTAM.
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.
XTAM Approval Workflows
To further explain the XTAM Approval Workflows, it is important to understand their components.
- Workflow: The workflow object itself can only created, modified or deleted by XTAM 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 XTAM. 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 XTAM 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 FAQ articles to learn about how to configure and use XTAM workflows in your environment.
- How to create, assign, request and approve a workflow (Getting Start 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