Moving Identity Management Forward: The Preauthorized and Delegated Access Request Model

COVID-19. A pandemic that will go down in history. Interestingly, it may also be noted in the history of higher education as the true catalyst to global digital transformation.

As we move forward in the months ahead, the goal now should be to begin determining a service delivery model that incapsulates the on-demand needs of the end user population, in conjunction with a secured authentication and authorization model that works for the campus identity management program. Deploying a preauthorized and delegated access request model can streamline the business process and increase efficiencies around fulfilling self-service requests, all while not giving up governance.

Businesses are often faced with a bottleneck for fulfilling requests from an approval point of view. This is often due to the legacy approach of requiring management personnel to submit requests, needing technical reviewers to review the access requests, or simply not having enough people, time, or budget to appropriately staff up to handle the inbound access requests at all. In these COVID-19 times, business and technical operations are most likely experiencing cracks in the foundation due to a decreased workforce and budget, inhibiting investments in the right time and money to maintain a service level agreement (SLA) with end users as it relates to fulfilling requests. During my tenure in the identity management profession, this is a common problem many organizations have discussed with me. And I always suggest the same solution: preauthorization and delegated access requests.

What do I mean when I say "preauthorization and delegated access requests"? This is a concept that employs a governance framework and enforces the necessary security structure to fulfill access requests without the need for N layers of approval. This strategy requires considering an "exploded" authorization model as it relates to who is able to submit and fulfill requests. On the surface, thinking about allowing 25 people to request sensitive access, versus allowing only 5, may sound like a security risk or, at a minimum, a logistical nightmare. This is largely due to the thought that giving more people this ability will lead to more requests that need to be fulfilled by a finite group of people (i.e., the IAM or IT teams). But this is where the thought process needs to change. Exploding the authorized user population for access requests will do the reverse. It will create more efficiency, more predictability, more accurately fulfilled requests, and more security, and ultimately it will streamline the SLA to fulfill more requests from end users.

How does this work? It does so by beginning to understand that the people who ultimately have the knowledge to fulfill the requests and who represent the proper level of access required to enable the permissions necessary for users to do their job are the business unit owners, the application analysts, the access sponsors, and/or the system owners. Those people should be enabled to begin submitting the necessary access requests, instead of having managers submit a request for something they may or may not understand based on what they were told was required. Once both the subject matter experts and those with the ultimate accountability over securing and supporting the end point applications are empowered, an organization immediately gains efficiencies.

How do you govern and secure this model? This is much easier to answer than one might think. Considering the level of authority and privilege already granted to the people noted above, they already are, in a sense, "preauthorized" to administer access for their systems or business units. The security lies in defining who these people are, as well as constructing an authorization model that allows for identity management to limit the types of requests each person is able to submit. For example, if the Director of Application Security is tasked with being responsible for submitting access requests for all applications within his or her purview, most likely the Director is not going to understand the context of the access request—that is, the permissions to be granted to the user. The people who do understand explicitly what access is required are the front-line staff noted above. Of course, one could easily make the case for delegating the approval of the access to the actual application analyst or sponsor. But a better approach is to empower the front-line staff to submit requests on behalf of the application and/or the people they are directly or indirectly responsible for securing and maintaining continuity with.

So, instead of the Director making an access request—which would then flow to a separate entity for review and then to a technical SME for validation that the access requested will in fact get the job done for the person requiring it—the front-line staff should be the authorized individuals who can submit requests. This approach requires a distinct feature: the ability for identity management to recognize that the requestor is also the approval authority. At this point, identity management would be aware that the same person is submitting the request, the same person is authorized to see the application set presented for the request, the same person is the one who understands the security construct of the application, and that same person is most likely the one responsible for managing the access.

In closing, when thinking through how to streamline operations while still maintaining the level of governance necessary to ensure that authorizations and capability conform to the existing information security model, organizations should consider a preauthorized and delegated access request model that enables business units to manage access to their own applications, for their own users.

Dan Dagnall is Chief Operating Officer at Fischer Identity.