Workflow-based access
Sectona Privileged Access Management system can allow you to enforce workflow actions by allowing access to passwords or access via the system. The system works on a concept of request types ( or can be referred to as a transaction). Two request types in the systems are password and access. The workflow system leverages emails to provide notifications to requestors & approvers. Approvers can approve requests over Sectona Web Console or directly over emails. For email-based approval, Sectona must have POP3 emails configured to receive approval via email. Ensure you have set up SMTP & POP3 settings in Email Gateway configurations.
POP3 emails settings and function points Email Approval workflow must be activated to activate email approval methods.
Systems support up to 15 levels of approvals and rules based on attributes for easy configurations. Attributes help to filter requests and define multiple approval flows. Workflow requests work on a principle of attribute-based scoring. Rules matching maximum attributes to an object of requests are applied for a workflow request.
Request types in the workflow system can be defined as objects you want to control and monitor. The system supports options for controlling password requests & access requests workflow.
Password: A request is made to have access to the password. It may be a single level of approval or multilevel.
Access: An access type request is made when the user needs passwordless access.
Procedure for configuring workflow rule
Workflows are enforced to enable need-based access to passwords and direct access. It's essential to define the scope of what a user can view to request access. Limiting a scope can be defined by leveraging the Access Request Scope feature of the User Access Policy. For example, a vendor user who may need access to only windows servers should not be able to raise an access request for Unix or databases. Steps to configure workflow rules are listed below.
Navigate to the "Policies" option in the navigation bar.
Select "Configure" from the sidebar.
Click on the "+ Add Workflow Rule" button.
Rule name: Specify an appropriate name for the rule which will define your workflow. The name should be unique and instance-specific.
Description: Enter a unique descriptive title for your workflow rule.
Rule type: Select Workflow.
Levels: Define the number of levels required for an approval workflow.
Request type: Select password or access-based workflow.
Schedule time: Select any if you would like a rule enforced any time of the day, or select the time window you want to enable. the
Attributes: *Important* Select the attributes where you would like to apply this workflow. If workflow attributes are left blank, workflow rules are applied to all transactions initiated for the selected attributes. You can also add levels for multiple approvals.
Status: By default, any workflow rule request is enabled as Active.
In case of conflicting workflow rules for a particular transaction, preference is given to the latest rule.
Overriding workflow-based access
In a situation where a user belonging to a specific workflow can also belong to another workflow. It might happen that the user will have to wait for the previous request to be approved, which gives rise to a deadlock situation. Here, the administrator will have to manually delete or terminate the request raised by the user. This will override the workflow that has been stuck due to the pending request. Also, users can cancel or terminate their requests.
This section consists of all the log & pending requests to check out a password of an account or require access to an asset to perform a certain task. The procedure to terminate a request is
Navigate to the "Policies" option in the navigation bar.
Select "All request" from the sidebar.
Click on the terminate option of the request you wish to terminate.
A pop-up box will be displayed. Click on 'Yes' to terminate the request.
You can check the information Request ID, Type, Requested By, Requested On, Comment, Ticket No, and Current Status.
Revoking Workflow-based Access
With the help of an access request, the user could request access to an account. Once approved, the user will get access to the account. However, the approver can also revoke the account access after granting the account access. The access can be revoked if the user's work is done before expiration or if the access is mistakenly granted.
To revoke the account access:
Navigate to the "Policies" option in the navigation bar.
Select the "All Requests" option from the sidebar.
- Click Log.
- To revoke the account access, click the Revoke option of the required Request ID.
Related How-to Articles
- Configure a Maker Checker for Account management
- Configure a Maker Checker policy for Asset management
- Configure a Maker Checker policy for User management
- Configure a multiple-level workflow for Access Request
- Configure a multiple-level workflow for Password request
- Configure a single-level workflow for Access Requests
- Configure a single-level workflow for Password request
- Disable a Workflow policy
- Schedule a time for raising Access requests
- Schedule a time for raising Password requests