Example: Configure static authorization
Any regular user with a valid profile can be assigned as a static authorizer. Static authorizers can be mapped directly to resources or policies.
The types of requests that static authorizers can review, and the actions they can take, depend on the privileges granted to them by user access rules.
Requirements
This use case assumes that:
There is an Active Directory target system set up as a source of profiles.
The Active Directory target system is configured so that groups with owners are automatically managed by Bravura Security Fabric , to be moderated by owners. This means that Bravura Security Fabric assigns the owners of those groups as the authorizers.
Click below to view a demonstration:
Configure status authorizers for groups
You can assign static authorizers to a resource in the configuration settings for the resource.
The AD target system is configured so that groups with owners are automatically managed by Bravura Security Fabric , to be moderated by owners. This means that Bravura Security Fabric assigns the owners of those groups as the authorizers of any requests pertaining to their groups.
In this example, you will add one extra static authorizer for the ENG-MANAGERS-owners group:
Log in to the Bravura Security Fabric Front-end (PSF) as superuser.
Click Manage the system > Resources > Groups.
Select the AD target system to view its listed groups.
Search for and select the ENG-MANAGERS-owners group and take note of its settings.
Click the Authorization tab.
Set the Minimum number of authorizers to
1.This means that any one of the authorizers you map to this target may approve the request.
Set the Number of denials before a change request is terminated to
1.This means that a change to an existing account is canceled if one of the authorizers deny the request.
Notice that the owner of the ENG-MANAGER-owners group has already been added as an authorizer.
In the Authorizers table, click Select… .
Search for and select HARRYJ.
Click Select .
The ENG-MANAGERS-owners group now has one additional authorizer added so that requests to join or leave the group can be approved or denied by either one of the two authorizers listed; MOHAMD or HARRYJ.
Configure authorizers from the workflow menu
All authorizers that are mapped to resources are listed in Manage the system > Workflow > Authorizers. From here, you can select individual authorizers to configure notification and additional security settings, and view the resources to which they are assigned.
Let’s assume you want to give the company president, BRYANW, additional authority when assigned as authorizer:
Click Manage the system > Workflow > Authorizers.
Bravura Security Fabric displays a list of authorizers. So far, all group authorizers are listed.
Search for and select BRYANW.
Select the Denial blocks entire request checkbox to allow the authorizer to block an entire request, rather than just part of a request.
Select the Input is required before request can be approved checkbox to require the authorizer’s approval before any request to which he or she is assigned can proceed, regardless of the number of authorizers who have already approved the request.
Click Update.
For requests where BRYANW is an authorizer, the request will not be approved until BRYANW has provided his authorization. If BRYANW denies the request, the whole request will be denied instead of only the part that required his authorization.
Here is an example of how the denial process works for this advanced privilege:
DARAK puts in a request to join the following groups:
Group
Authorizer
ENG-QA-GENERAL
No approval required
FIN-GENERAL
TRAVIC
EXEC
BRYANW
Even though the ENG-QA-GENERAL group does not require authorization, the membership is not added until the authorizers for other groups approve or deny the request.
TRAVIC decides to approve the request. The membership for the FIN-GENERAL group is also not added yet because the request is still waiting for approval from BRYANW.
BRYANW denies the request and so none of the three group memberships are added.
If we were to consider the alternative scenario where BRYANW approves the request and TRAVIC denies it, you will see how the denial privilege is only partial for TRAVIC. Here is the same example, but with BRYANW approving the request and TRAVIC denying it:
DARAK puts in a request again to join the following groups:
Group
Authorizer
ENG-QA-GENERAL
No approval required
FIN-GENERAL
TRAVIC
EXEC
BRYANW
Even though the ENG-QA-GENERAL does not require authorization, the membership is not added until the authorizers for other groups approve or deny the request.
BRYANW decides to approve the request. The memberships for the EXEC and ENG-QA-GENERAL groups are not added yet because the request is still waiting for a response from TRAVIC.
TRAVIC denies the request, so only the membership for the FIN-GENERAL group that he is responsible for gets denied. This demonstrates how regular authorizers only partially deny requests where there are multiple authorizers required, since they only deny the resources that they are authorizers of. Both the ENG-QA-GENERAL and EXEC group memberships get added successfully as only approval from BRYANW is necessary.
