Approver Lists
Approver lists is where IGA administrators define the individuals that will be involved in approving access. Fischer offers multiple types of approval list configurations. It is important to understand each type so you can make the right decision regarding how you define your approvals and most importantly the people that will ultimately receive an approval request. It is important to note that you are able to define multiple approver lists and apply those lists to the escalation and approval conditions to define your approval workflow in the context of the people that will need to be involved.
The Approver list configuration is accessible via the Administration User Interface as seen below:
When defining an approver list, you will start by selecting "Add" from the list of buttons.
Fischer offers multiple "List Types" that can be defined. The following table will define each list type.
User List Type
A user list is a statically defined list of approvers that are manually configured. This list is available but should be reserved for very small scenarios. It's important to understand that if a static list is utilized and Identities are either terminated or their role changes, IGA Administrators would be required to access any static user list and make sure the user is removed from the list and potentially replaced with the new person responsible. This approach is useful for smaller scale approvals, but should be the option of last resort when defining approvals. There are other more dynamic options that should be utilized, however the user list type is available if you feel you want to use it. Below is a screenshot of configuring a user list type. You'll notice you will see a list of users.
|
|
|
Where do the users in the list come from and how do I limit or expand the list? The list is populated with any identity that has the "approver bit" enabled within their profile. This value is set automatically by passing "Identity-Approver=1", or you can set it administratively by searching for the desired approver and checking the approver bit which will automatically flip the bit in the database. Here is a screenshot of a user with the approver bit checked:
|
Dynamic List Type
The dynamic list type is by far the most highly recommended way to build out your approval configurations. The dynamic filter provides organizations to build what we like to call "entity-based" approval lists. This means that instead of statically selected a particular person to define as an approver, you are selecting criteria, or attribute/value pairs that will authorized an individual or group of individuals as approvers at run time.
What does this accomplish? This accomplishes many things, but most importantly it provides the ability for organizations to define approvers in the context of their role. By leveraging the dynamic list type, IGA administrators do not need to change the approver list at all when life cycle events happen such as an identity transferring out of the role once responsible for approving and into a new role that may require authority to approver different types of requests. The dynamic approach also immediately resolves to the individual that replaces the position vacated by the previous person because the resolution of the approval authority is based on attributes and not on the actual person. This is a very efficient way to build your approver lists, and is also a way to ensure that you remain compliant to the defined business process and corresponding policies that define who has the authority to approve what. Below is a screenshot of the dynamic approver list configuration screen:
Hierarchical Approver List
The hierarchical approver list is an option for administrators to configure a dynamic, serialized approver workflow that will flow up the chain of command. This feature offers an exit point so the approval will stop when necessary. This feature is good to use when you follow a strict hierarchy for approving access. As you consider using this feature, you will want to think about what is being approved, and how far up the chain you need it to go. Configuring the filter is similar to the dynamic filter above, with a few differences:
You'll notice there is an exit condition section. This is the condition you will configure when you want it to stop.
Resource Owner Approver List
Aligning with the concept of resources, Fischer provides for the ability to define resource owners. If resource owners are defined, and a corresponding resource owner approver list is setup the product will automatically route the approval requests for any resource with a defined owner, and an approval workflow with an approver list type set to "Resource Owner".
Here is a screenshot of a configured approver list utilizing the "Resource Owner" approver list:
You'll notice two configuration options on the right side of the screen. By default, this privileges are off for any approver list that is defined. Select "Approver can Edit" will provide the approver(s) with the ability to edit certain portions of the request. Primarily the access period and any permissions that may be requested. The second option is "Show Optional Attributes". Selecting this will show the approver the additional attributes that may be required to be provided during the request process.
System Owner Approver List
The System Owner approver list is the same concept as the resource owner approver list. Fischer has a concept of a system owner which is defined at the connected system layer of the solution. Once system owners are defined, an approver list type of "System Owner" will automatically route any approval requests defined where the connected system is involved. For example, if I am defined as the system owner for Active Directory, and a request is made for an Active Directory account Fischer will route the approval to me since I am designated as a system owner and the approval workflow defined and associated to the resource request is leveraging a system owner approver list.
Here is a screenshot of a configured approver list utilizing the "System Owner":
Sponsor Approver List
The same concept is applicable to a sponsor approver list. Sponsors can be defined at the resource layer. When defined, Fischer will automatically route any access requests with a defined sponsor to the sponsor. Here is a screenshot of a defined sponsor approver list:
External LDAP Group Approver List
Fischer offers extensibility and scalability by providing organizations with the ability to abstract the approver list definition to an integrated connected system. If you decide to utilize the External LDAP group there are a few pre-requisites you must setup first. Below we will define the steps necessary to setup an External LDAP Approver List.
The first step is to ensure that you have defined an External LDAP group. To do this, you must access the "Security Tab" and create a dyanmic user group. This group is defined here:
Next, you'll want to select "Add Member" and select "External LDAP" from the group type drop down list. Once you select External LDAP you will be automatically re-directed to the dynamic filter definition screen seen below:
From this screen, you can select the connected system to be used to resolve the users. Remember, the system must be a defined connected system in Fischer. You can then define the member user filter as well as other granular LDAP configuration options that will ensure you are resolving the correct group of users for your approver list. It is highly recommended that you leverage the "Test" functionality as this will allow you to see if your filter is resolving correctly. Once the group has been defined...
Once you've completed the definition of the external LDAP group, you can then return to the approval configuration and define an External LDAP approver list. The final configuration will look like the below screenshot:
