How Much Utility Does Today’s Identity Governance Administration Tools have?
I frequently speak with leaders at organizations who think of Identity Governance Administration (IGA) programs as automating provisioning into all of their business critical systems. In most cases, the actual process of performing the provisioning of the access is done on only a small subset of the applications integrated into the systems.
Identity governance solutions are so much more. Over the years, we have implemented various IGA tools at organizations in many different verticals. While educating professionals at these organizations, we break provisioning and deprovisioning processes into three primary aspects: the request, the approvals, and the fulfillment. Each aspect can be implemented individually and, in most cases, is not dependent on the others.
Some of the early benefits of IGA solutions are realized before the first connector creates or modifies an account in a connected system. Those who seek to implement provisioning systems for compliance purposes appreciate the value of having a centralized repository of who owns what account in a collection of disparate systems. A cumbersome task that is often overlooked in Identity Management is the termination process. When an identity needs to be deactivated across an enterprise, many organizations have to manually search each system for an account and disable it. Highly manual tasks such as this are prone to error.
The fulfillment step of the process can be in one of a few states for each application. Not all applications will go through the full maturity, because there it may not make business sense to go further in the maturity process. Ultimately, before adding more functionality to the fulfillment integration, each business must decide as to whether the amount of manual work automated, organizational risk reduced and other factors can provide enough return on investment to justify the cost and effort to add more features.
We are here for you
Allow us to help you pick the best of breed solution for your IAM Issues
Fulfillment Examples Of Provisioning And De-Provisioning Processes For IGA Tools
This level of integration requires read-only access and is very quick to value. The data necessary to perform this function is already available in many cases. Compliance teams audit the controls of the provisioning and deprovisioning process in many organizations, which requires data on all accounts in the business critical systems. This data can leverage to automate the compliance team’s certification processes as well as to assist the provisioning teams to have an authoritative source for where access is provisioned for the termination process.
Many organizations handle manual processes through ITSM tickets. There are forms that are filled out, which result in a ticket being assigned in an ITSM being assigned to provisioning teams for the various applications. This level of integration creates a reusable fulfillment mechanism that can open tickets to assign tasks to the necessary teams. This removes the manual task associated with creating the tickets. When combined with some other functionality, like the automatic assignment of access based on roles, this can help remove quite a bit of repetitive manual tasks that are error-prone. It also serves to bridge the gap between the manual pre-IGA state and the end state. While more full-featured connectors are being built, other processes can be integrated.
The read-only connectivity is a subset of full provisioning. Full provisioning is the most difficult to achieve and should be reserved for the highest organizational risk and highest manual effort systems to ensure a full return on investment is achieved. The difficulty in doing full provisioning is that, outside of large, common enterprise systems, such as Active Directory, many other applications do not have specific connectors designed for them. To put things into perspective, there are tens of thousands, if not hundreds of thousands of applications used by businesses all over, whereas most IGA solutions have about 100 connectors prebuilt by the vendors. In most cases, the connectors available from the vendors are a few specialized application specific connectors, and the rest are for technology standards, such as databases and web services.
When dealing with a connected system with no application-specific connector available, the IGA development team must learn the API. In many cases, there are no APIs available, and this leads to reverse engineering the application, which puts the support of the application from the vendor at risk. Then, after the application is integrated, there is no IGA vendor support for upgrades of the application, so the full lifecycle of that connector is now the responsibility of the organization.
Before invoking any fulfillment, there are two other processes that can be handled in an IGA tool. The entry point into the system is the request method. When thinking of request, most people only think of their manual form that must be filled out to request access. In an IGA tool, that form should be taken away and replaced with a self-service shopping cart-like functionality. Various users can browse through catalog rights for different systems in different ways. They can search by which system, which application, what business function (or role), as well as a variety of other ways to help people find what they need.
Depending on the person in the system, scoping can be leveraged to show different things in the catalog based on what they should be able to see. It can also be configured to allow people to make requests on behalf of others. In many businesses, there are constituents who will not do their own self-service. If the business knows who these folks are and decide to allow it, they can designate who can initiate those requests.
The second method is typically defined as roles based provisioning. Many organizations strive to reach this level of request. In the early maturity stages, requests can be difficult for non-technical users. Even with context, most users do not understand the IT aspects of what they are requesting. Roles are intended to bundle together all of the individual pieces that make up a business function or business role and allow them to be requested together to ensure there is minimal confusion as to what is needed.
For example, a hospital may be using Epic as their EHR system. Within Epic, access consists of templates and sub-templates in most cases. However, many hospitals host Epic in a Citrix environment. If the physician is accessing Epic from a remote clinic, they may also need to VPN into the network first. In recap, a physician in a remote clinic may need a VPN account, MFA token, network account, AD groups for Citrix access, as well as the templates and sub-templates for Epic to log in and perform a single function. How is the physician supposed to know that? That is where roles can be helpful. The request can be “Remote Clinic Pediatrician,” which has everything necessary in a single request. No additional technical knowledge is necessary, everything is requested in a single shot.
The third method of request is the most powerful, rules-based. Rule-based requests allow organizations to programmatically request things automatically. This includes things such as birthright roles. Birthright roles are great because it allows an organization to automatically provision access to users with all approvals completed in advance. With birthright roles, once a person is hired into a specific job role, position, department, location or other function, the HR or payroll data can be used as an authoritative source, and the role will be granted.
This is especially helpful to handle one of the harder provisioning use cases in an organization, often referred to as the “mover.” Mover is defined as the process of transitioning a person within the organization. When a person moves within an organization, in many cases, their access should change as well. It is very common for access related to their old job function to remain and the new access is added. This causes issues for security and compliance, but can often be difficult to handle, due to the business wanting to maintain continuity for that person. To shut down all of their access and recalculate it manually can be very time-consuming. By having birthright roles, the changes can be calculated automatically; new access requests can be created, while requests to deprovision what is no longer necessary can be created as well.
Between the request process and the fulfillment process are the approvals. Gaining automation around the approval process can be a quick win, but requires both requests and fulfillment to be integrated in most cases. Creating business processes in the workflow engine can be tedious in some cases, but most vendors have out-of-the-box workflows provided that can do 90% or more of the necessary functionality.
When listing out the approval workflows necessary, a common misconception is to only think of the typical approval chains. If additional data needs to be gathered to perform a provisioning action, such as a license or cell phone number, the approval process can be modified to ensure that these values are captured before provisioning. During deprovisioning, sometimes additional constituents must make decisions, such as mailbox access or redirection before removing an email account. This too is done within the approval process of IGA.
One of the largest gains provided by the integration of the approval process into an IGA tool are the reports. Being able to provide the compliance auditors with a report of all provisioned access, whether it was done manually or automatically, with the appropriate documentation as to why a person has that access can save a significant amount of administrative time. Most processes for providing this data is done on a case by case basis. The compliance team selects their sample set; then teams need to go dig up the tickets in the ITSM system or find the email trails with the request approvals. By integrating the approval process, all requests, approvals, comments and other relevant data are provided on a single report for all users. It can be filtered to the sample set if desired, but all relevant data is stored in a single repository that was designed with the ability to report on this data in mind.
When all three aspects (request, approval, fulfillment) are different levels of integration and automation. As an Identity Governance Administration consulting organization, we recognize that not all applications need be fully integrated into all three aspects. We focus on providing the level of integration in the areas that will provide the fastest return on investment. By using best practices and the frameworks designed by the vendors, we can also help select a tool that will provide the fastest time to value, by ensuring whether or not the selected tool can implement all business processes without the need for customization. While most tools recognized as leaders by the large analyst first can get the job done, they have strengths and weaknesses based on how they decided to implement their framework. In some cases, a particular tool’s framework does not have an easy way to implement specific business processes without significant customization to the tool or a change to the business process.
If your organization is just starting, GCA can provide value by learning your business as part of an Identity Governance Administration assessment. These mutual education engagements help our team of experts learn your business while educating your professionals on the best practices, processes, and tools available. This will help your program avoid pitfalls that can increase the overall cost of ownership as well as the success rate of your implementation.