Approvals serve more than just access control governance, however in the context of IGA they play a significant role in maintaining a compliant IGA solution. An approval workflow can be inserted into any one of the above features to provide authorization from the appropriate business, process or data owners. The approval feature is very robust and provides organizations with the ability to define N layers of approval and include any entity in the approval process that is required. Approvals are an important part of any IGA solution, as it provides for the proper authorization mechanism to officially approve access for end users. Approvals are used in different ways by different organizations. Below are some key scenarios and concepts that you need to understand.
How the feature is constructed:
The feature is constructed to be built, bottom up. This means that when configuring approvals, administrators would start from the bottom of the interface and work their way up to the top. There are 5 distinct functions of the approval feature, each serving as an interdependent object. This is done to maximize re-usability and decrease redundant configurations. As you build out your approvals, it is important that you consider building out the context of what access is to be approved and by whom. It is important to undergo a discovery process and build a catalog of what access will be approved and the entities that are required for approval. This will help to build out the feature properly and efficiently. For example, if you find similarities in the particular entities that are required to approve distinct resources, you should build out a single (dynamic) approver list that can then be re-used as you define the master approval workflow(s). This approach (re-usability) limits the number of iterative configurations required and can streamline your configurations to maximize efficiency in design as well as drastically decrease change control and change management activities as it relates to the evolution of the business unit (i.e. life cycles for individual identities as well as the actual resources themselves). The below screenshot is a focused view on the the functions required to be configured in order to build out a functional approval worklfow:
Per the screenshot below, as you build an approval workflow you would configure the feature as follows: (1) Notify Conditions (2) Approver List (3) Escalate Conditions - if applicable (4) Approval Conditions and then (5) Master Approvals. The sections below outline the configuration options available within each function of the approval feature.
Feature Functionality
This section will outline the functionality Fischer currently supports for our approval feature.
| Escalate Conditions |
| Escalations allow approval processes to be transferred to a separate set of approvers to take action. Escalation conditions are extremely important, and must be defined within an IGA program. Since an IGA program is about securing access to organizational assets, authorizing only the appropriate personnel to perform tasks, streamlining business processes and most importantly to provide oversight and governance, escalation conditions are an absolute requirement. While Fischer does not require escalation conditions to be defined for an approval, all organizations should consider them a foundation pillar of a successful IGA program. Escalation conditions provide organizations with the ability to define a process that will be initiated as needed when an approval process is executing. Escalations can be triggered manually, or automatically depending on the situation. Refer to "Configuring Approvals" for more details. |
| Delegation |
| Fischer provides approval delegation. Approval delegation is a setting that is configurable for each designated approval authority. This feature is available to approval authorities that have a desire to delegate their approval authority to another entity. It's important to note any delegate must also be authorized as an approval authority. Delegation can occur at a single level only. This means that if you have been designated as a delegate, you will not be able to delegate your approval queue. |
| Approve / Deny / Reassign |
| Fischer offers the standard actions required to ensure the approval process can proceed. Approving the request will move it to the next step. The next step may be another layer of approval or it may result in the allocation of the requested resources. This is solely dependent upon how the organization's approvals are defined within Fischer. Deny will deny the request, and if authorized to do so, the approval authority can reassign the request to another approval authority. |
| Request Info |
| Fischer provides a feature called "Request Info". This is a powerful feature that allows for communication among the parties involved in a particular approval request to stay within Fischer and not force a phone call or external email to be sent that cannot be tracked by Fischer. All organizations should leverage this feature as it is a best practice approach to governance and oversight warranted by an effective and secured IGA Program deployment. When activated, this feature is used to send requests for information directly through the approval itself. This approach offers an efficient mechanism to streamline the business process as well as a way to track the commentary that occurred during the approval process for archiving and auditing purposes. |
| Request Editing |
| Certain approval authorities can be granted the ability to edit the inbound request. The information that can be edited is limited to changing the access period and/or the actual resources submitted for request. An approval authority with the authorization to edit the request can change the requested access period (either increase it or decrease it accordingly), edit any optional attributes that were added to the request, as well as editing permissions that may be associated with a request. |
| Approval Process Visibility |
| Fischer provides all parties involved in a given approval request to view the status and ongoing updates. This is accomplished within the Self-Service Portal under the View Requests tab. Furthermore, Fischer provides IGA Administrators with a global view of the status of all approval processes (pending, denied, completed, error or otherwise). |
| Bulk Approval |
| Fischer provides a feature within the approvals that allows for approval authorities to execute bulk approvals. This feature is one that can help streamline similar requests for different Identities. The approval authority can "select all" approvals and take bulk action on all items in their queue. |
| Bulk Denial |
| The same bulk capabilities available for approval is also available for denying requests in bulk. |
| Automated Exception Handling |
| An extremely important function of Fischer's approval feature is the ability to configure automated exception handling. When employed, this feature offers an AI-type experience where it can automatically detect failure within the approval process itself and will re-route the request according to the defined automated exception handling that is defined. All IGA Administrators should leverage this feature as it was purpose built to help keep a business process moving forward instead of it failing and potentially falling through the cracks. When deploying Fischer's approval feature, it is of paramount importance that this feature is leveraged wherever possible to help maintain business continuity and agility. |
| Approver List Definitions |
| Fischer provides multiple methods to define the list of individuals that will be grouped together for a given approval process. |
| Profile Modification |
| Approvals can be activated for Identity profile modifications. This feature provides attribute-based governance within an Identity Profile. Often times, help desk personnel or other designated authorities may make changes to an Identity profile from within Fischer. These changes may or may not affect the user's access, so it may be necessary to initiate an approval request before the attribute value is allowed to be changed. While this feature can be overused, it is important that IGA solutions scale to this level, dynamically the way Fischer does to ensure that when necessary, attribute-level governance can be activated within an organizations IGA Program. |
| Profile Approval |
| Fischer's concept of a profile approval is a strategic way to provide oversight before Identities are introduced into the Registry. This feature is built out in the Studio and is used to monitor inbound SoA payloads as well as any other logical business scenario where an organization may want more granular oversight. An example of how this feature is used is when Fischer detects a massive amount of records introduced into an organization's SoA and there is a threshold the organization has put in place to allow processing to proceed as normal. To further this example, if all of the sudden, an organization introduces 10,000 changes all at one time, Fischer can introduce a profile approval step that will initiate an approval request because the organization stated that if Fischer see more than N number of events at a single time, do not process those events through the system in favor of stopping processing and initiating a notification to the appropriate personnel, along with subsequent initiation of an approval to proceed with processing. The reason this is important is because sometimes events may be erroneously triggered as result of something that went wrong with the SoA data repository and Fischer detects more events than should be processed. If Fischer were to blindly proceed with processing it cause a series of unintended consequences such as de-provisioning Identities. |
Global Configuration Options |
|---|
Fischer's administrative user interface is built in a such a way that a series of properties associated with a particular feature are all bunched together under the "Configuration" tab. Specifically the "Configuration (tab)" → "Configuration Function Menu" option. Below is an outline of the available properties that WILL affect how the approval feature operates:
First of all, here is a screenshot of where the configurations are located in the administrative user interface:
Configuration Options
| Administrator Email | |||||||||||||||||||||||
| Fischer provides for the assignment of Approval Administrators. Approval administrators can be individuals that simply manage and maintain the feature itself from a technical aspect, or it can be a combination of technical and managerial personnel that can oversee all the happenings related to the employed approval feature. There are various locations where approval administrators can be notified. | |||||||||||||||||||||||
| Allow Approvers to Reassign Requests to | |||||||||||||||||||||||
|
This global approval feature will affect all approvers and all layers. This is a program level decision that needs to be made regarding if and how approval authorities can reassign any requests in their queue. This combo box has multiple options, which will breakdown here: Available Options
|
|||||||||||||||||||||||
| Allow Approvers to Request For Info | |||||||||||||||||||||||
| This is a boolean configuration. It can be either True or False. A true setting will allow for the Request Info feature to be leveraged by approvers, a false setting will hide this option from the approver screen. It is strongly recommended that this feature be employed by organizations as it provides the ability to keep all communications related to a particular request embedded within the request itself. As a IGA provider, Fischer should strongly suggest this option be policy for any organization using the Fischer product due to the governance and audit ability it provides our customers. Leveraging a phone call or external email will break the audit trail as it relates to any communications that may have occurred when deciding whether or not to grant the requested access. This information can be important during an audit or attestation campaign. This is a global option to all approvers and cannot be turned on for certain approvers and turned off for others. | |||||||||||||||||||||||
| Allow Delegation | |||||||||||||||||||||||
| This is a boolean configuration. It can be either True or False. A true setting will allow approvers to delegate thier approval queue to another authorized Identity. A false setting will hide this option from the approvers Self-Service Portal and they will not be able to delegate. This is a global option to all approvers and cannot be turned on for certain approvers and turned off for others. | |||||||||||||||||||||||
| Allow Delegation Approver to Edit | |||||||||||||||||||||||
|
If approval is required prior to an approver delegating their queue to another Identity, this global option helps organizations control what aspects of the approval can we edited, if anything at all. The available options in the combo box are as follows:
|
|||||||||||||||||||||||
| Approval Action when Beneficiary is the Approver | |||||||||||||||||||||||
|
This is a very important global option. It pertains to providing the necessary oversight for approvers that may be the beneficiary of access for which they are the designated approval authority. This global configuration option is one that provides the level of governance required to ensure a secure operating environment is in place. This feature WILL impact approvers submitting requests for their own Identity. There are multiple options Fischer provides to help organizations control how they want to handle this extremely important scenario. The options available to organizations that may run into this scenario are as follows:
|
|||||||||||||||||||||||
| Approval Action when Requestor is the Approver | |||||||||||||||||||||||
|
There are scenarios where the approver may be the actual requestor. Fischer has built out the necessary scalability to ensure that organizations can make the choice that is appropriate to them in this scenario. The baseline use case is the classic OBO scenario where a manager by be requesting access for a direct report. In this scenario, Fischer provides 3 options for organization to employ: Check boxes Indicate Use When employing this feature, you will see check boxes next to each available function. The box must be checked to be employed. The act of checking the box will activate the function and the corresponding filter attached will serve the conditional basis as to when to leverage the selected option. Also note that all three options can be activated, hence the need for the filter to ensure that organization's can build out the different scenarios when each of the selected options will be employed. It is also important to note that at execution time, if all three options are active for this feature, it will evaluate the Escalate option (and corresponding filter) first, then it will evaluate Approval Required, and finally Auto Approved. this is what it looks like in the admin UI:
When clicking "Select" the following filter will be displayed:
So what is the filter intended to do? The goal of the filter is to provide a way of defining granular criteria when a particular function is invoked. For example, if Approval required was selected as the action to take when the approver is found to be the requestor organization's can define a filter with exceptions to the selected governance rule. If the filter is left blank, then anytime Fischer's engine determines the approver to be requestor and one of the above options is active (i.e. the box is checked) then it will take global action on all requests. Given that the options evaluate in order from top to bottom (as seen in the screenshot above) and no filters are supplied would result in all scenarios that would hit this oversight mechanism would all default to escalating the request. If filters are supplied, the goal is for the filter to determine upon which Identities action should be taken. So if Escalate is checked and a filter is applied, it will invoke reviewing the filter and any Identities that are resolved within the filter will be the Identities that will meet the escalate criteria. The same applies for the other options. If Approval Required is active, and there is a filter supplied, only the Identities resolved by the filter would be governed by this function. So anyone that resolves in the scenario where they are the requestor and the approval, and the Approval Required option is active will require an approval process to complete before access is granted. For Auto-Approve, if left blank and selected in conjunction with one or both of the other available options any users that would not meet the filtering criteria would fall to the Auto Approve option and the request would be auto approved and it would not be escalated and it would not require approval. |
|||||||||||||||||||||||
| Approval History Display Option | |||||||||||||||||||||||
|
During and post approval process, Fischer offers a "History" view. This view translates to the step-by-step events that occurred during the approval cycle. Fischer feels it is important to show this historical information as it can benefit both the beneficiary of the access request as well as those tasked with approving it. During an approval process it provides essential details and commentary related to the in-process request. Approvers that may be at a higher level can see other approvers that may have approved (or denied) the request before they take action. It also provides the requestor and beneficiary with a real time view of the on-going process. This can help streamline communications for businesses as well as help to eliminate follow up requests outside of the standard process for scenarios when approvals may sit for a few days before they are processed. Overall, it is an impactful feature to make sure is active an available to an organizations IGA solution. The options available for this global setting are as follows:
|
|||||||||||||||||||||||
| Approval Required for Delegation | |||||||||||||||||||||||
|
This is a boolean setting and can either be True or False. If set to True, any approval delegation request will require an approval.
It's important to note that this global option is also tied to "Approval Rule Used When Delegate Resigns" as well as "Approval Rule Used when Approver Delegates".
If "Approval Required for Delegation" is set to "True", separate approval rules need to be set for approvers to delegate, and delegates to resign. When set to True and 'Approval Rule Used when Approver Delegates' is set to None, delegation requests will be processed without an approval. If set to True and 'Approval Rule Used When Delegate Resigns' is set to None, resign requests will be granted without an approval.
|
|||||||||||||||||||||||
| Approval Rule used When Approver Delegates | |||||||||||||||||||||||
| This global property is where you define the approval process to be followed when an approver attempts to delegate a request. If Approval Required for Delegation is set to True, you will want to make sure to configure an approval for this item. | |||||||||||||||||||||||
| Approval Rule used when Delegate Resigns | |||||||||||||||||||||||
| This global property is where you define the approval process to be followed when a delegate attempts to resign from delegation. Note that Approval Required for Delegation must be set to True. | |||||||||||||||||||||||
| Approver Comments | |||||||||||||||||||||||
|
This feature is for organizations to determine whether or not approvers must comment on any approval request that is assigned to him or her. The available options in the combo box are as follows:
|
|||||||||||||||||||||||
| Delegate Search Criteria | |||||||||||||||||||||||
| This feature is intended to provide organizations with governance over who approvals are allowed to be delegated to. IGA Administrators can create a filter which will display only those approval authorities that meet the filter criteria. An example would be if there are 10 Identities designated with approval authority, and an organization only wants 3 out of those 10 to be an eligible delegate, the filter built in this feature would need to resolve those three individuals. Then, once an approver attempts to delegate their approvals, only those 3 eligible delegates will appear in the list of available delegates. | |||||||||||||||||||||||
| Invalid Approvers found Notification to Administrator | |||||||||||||||||||||||
| There may be scenarios where organizations have defined static approver list and the Identity or Identities within the list are no longer active. This is a great reason to never use static approvers lists, given the manual intervention required if an Identity is disabled within the solution. However, if there is a case where an approval process is initiated and a static list is designated to be used, and one or more of the Identities in that list are no longer active, this feature will provide a notification to the global Approval Administrators that they have a configuration problem. | |||||||||||||||||||||||
| Notification for Delegate | |||||||||||||||||||||||
| If an approver delegates their approval queue successfully, organizations can configure a notification to be sent to the delegate. Organizations are not required to send a notification. If they did not want to send a notification, this function should be set to "None". What will happen if no notification is sent is the next time the delegate access self-service, they would see a new card in their Approvals interface showing they have become a delegate for Approver XYZ. | |||||||||||||||||||||||
| Notification for Delegation End to the Approver | |||||||||||||||||||||||
| When a delegation period ends, Fischer will automatically revoke delegation based on the date's specified within the delegation request submitted by the original approver. Upon revocation, the original approver can be notified of this event via email. This feature is helpful but not necessarily useful from a governance point of view. It is an added layer of communication to ensure the approver knows he or she is now once again responsible for any assigned approvals where he or she may be a part of. | |||||||||||||||||||||||
| Notification for Delegation End to the Delegate | |||||||||||||||||||||||
| Similar to the Notification for Delegation End to the Approver, a notification can be sent to the delegate informing them the delegation has been revoked and they are no longer responsible for approving requests delegated by the original approver. | |||||||||||||||||||||||
| Notification for Delegation Request Status | |||||||||||||||||||||||
| This notification can be sent to the approver requesting delegation. It will provide the status of the delegation request if an approval is required prior to delegation. | |||||||||||||||||||||||
| Notification for Delegation Resignation to the Approver | |||||||||||||||||||||||
| If a delegate resigns their delegation responsibilities and an approval is required, this notification will be sent to the approver to inform them of the request to resign and that action is needed (i.e. approving the resignation). This is an important notification to include in a standard IGA solution as it directly correlates to an action that has direct affects on who is approving access, which should always have oversight and granular communication channels open to ensure all parties are aware of the resignation request as it could have consequences if an approval is not required and the delegate resigns and the original approval authority is not available yet. For example maybe the original approver delegated because they were going on vacation and they are not back yet, but the delegate resigns. If no approval is required and no notification is configured approvals could go stale, timeout and start escalating up the chain which can create roadblocks from a business process point of view as no one would be informed of the resignation. | |||||||||||||||||||||||
| Notification for Delegation Start to the Delegate | |||||||||||||||||||||||
| This is another important notification that should be considered a standard part of any IGA solution. It is important that the delegate is made aware that delegation has started. While when they login they will see it on their approvals view, it is important for the delegate to know they are in fact now responsible for the approval queue of someone else so and they should immediately check their queue to see if there are in fact any pending delegated requests to address. Without this notification, the delegate would eventually realize they are responsible for the approval queue of a colleague when they log in. But they may not be aware of when the delegation started. This is specific to the scenario where an approval is not required for delegation. If there is no approval required for delegation, this notification is an absolute necessity for governance, oversight and business continuity. | |||||||||||||||||||||||
| Reassign Comments | |||||||||||||||||||||||
|
This feature provides an option for approvers that attempt to reassign a pending approval request to another approval authority. The organization can provide a governance mechanism that forces any reassignment to be accompanied with a comment from the original approval authority. Fischer recommends this always be set to "Required" as it cultivates the level of communication necessary to maintain and streamline communications among distinct entitiies and removes the situation where someone may forget to mention some of the details or the reason they decided to reassign the request and it provides an audit trail as to why the request was reassigned or at least why the original approver felt compelled to reassign it to someone else. The options available to this feature are as follows:
|
|||||||||||||||||||||||
| Reassign Search Criteria | |||||||||||||||||||||||
| Fischer provides a governance feature that enables organizations to limit the number of individuals that are eliglble for reassignment of approvals. This is not to limit the approval authorities that are able to reassign, that is a global feature, rather if the reassignment feature is available to approvers, upon clicking "Reassign" within an active approval process, the list of approvers to which the request can be reassigned to can be controlled by this filter. This helps organizations to provide automated oversight regarding who is able to be the recipient of a reassigned approval. This is an important feature to consider if organizations want to control how access requests are processed and more importantly who is allowed to be involved. | |||||||||||||||||||||||
| Submitted by Value for System Generated Requests | |||||||||||||||||||||||
| This feature provides organizations to specify a name or entity that will appear when approvals are generated by the "System". By System, this is a specific scenario where approvals can be generated by the workflow studio for approval of Identity profiles. When set, this will be the "Submitted by" column within the approval itself as well as associated administration screens. An example would be "Submitted by: Business Operations" or something similar so it can be tracked by the entity within an organization that is directly tied to the approval generated at run time, via the Studio. | |||||||||||||||||||||||
