The importance of having a centralized Access Management system (AKA: Authorization-as-a-Service)

In the domain of Information Security, Identity and Access Management (IAM) is the field that aims to ensure that the right users have appropriate access to different resources (data, applications, etc.). In other words, it guarantees that these users can only access what they have been authorized for, in line with risk-based decisions made by the owners of those resources.

This is the principle, anyway. But that principle can be implemented in different ways:

If your organization uses (or offers) multiple applications, you can simply have each application independently managing user access (that is: who can do what).

Or you can manage that level of access centrally, in what is known as an Access Management (AM) system. This way, your applications will just ask that system whether a specific user can carry out a given action or not. This AM system becomes the brain for Authorization decisions, a single solution where access is defined and maintained, and exposes its capabilities to consuming applications and other services. These capabilities embody the concept of "Authorization-as-a-service", meaning that client applications can simply consume this service and better focus on building its core-mission features.

As we will see, using a centralized AM system is the only future-proof solution for the new digital era in terms of security, scalability, manageability and governance. But even though I believe the grounds for this will be clear on the page, it is still surprisingly often that I encounter strong challenge from application owners and administrators:

“We already control our user´s access directly within our application. Why do we need to change this now, and invest some effort in order to do the same thing by using this new Access Management solution?”

First off, I'd like to clarify that I love the engineering mindset. This kind of challenging and inquisitive mentality is what prevents us from implementing the wrong things, it keeps us from building systems just for the sake of doing it and it keeps us honest, for we need to ensure that we have the answers to the questions that we know are going to be thrown at us (and to some others that we don´t expect yet). So it is a fair question indeed: What are the reasons for a centralized AM solution? In my experience, they can be summarized into the following points:

1. Applying strategical restrictions. The root for this particular challenge is a very simple and common misconception: "We already know who should get access". Or, in other words: "That decision remains fully with us, as resource owners". As owners, the decision for who gets access to the resource, does belong with them. But the decision for who does not, might also come from higher instances in the organization, and it could exceed the understanding or the scope of the resource owner. As an example, let´s say that this owner states that every lawyer within the company needs access to their application. However, after our company acquires another brand which turns out to be a competitor to some of our customers, the Risk department establishes that, for legal and competitivity reasons, nobody in the newly acquired brand must get access to these customers’ data. Do we expect the resource owner to be aware of this decision? In fact, do we expect ALL resource owners to stay alert and informed of ALL of these types of decisions? After all, most of the restrictions won´t be applicable to most of the applications. Furthermore, do we expect to inspect all of these applications to verify and gather evidence that such restrictions have been properly implemented everywhere? A centralized AM solution will take care of this, since the restriction only needs to be defined in one single place. As a result, a subset of the user population authorized by the resource owner will effectively obtain access, intersecting all defined criteria to make sure no inappropriate access is allowed.
2. Enforcing cross-system Segregation of Duties (SoD). Even if resource owners had the capacity to analyze and timely respond to all of these strategical restrictions, there is another type of restriction that will always slip through their fingers. Some business processes require preventing the same user from carrying out different steps in the process (For example, in order to avoid fraud, you cannot approve an expense if you are the one who submitted it). Sometimes, this also means that the user cannot access a particular resource if they already have access to some other conflicting resource, potentially in a different application. In other words, these SoD conflicts are very often based on information that is not locally available to the application, so the only way to ensure cross-system SoD restrictions is to use a centralized AM solution. Again, the application will not need to worry about those conflicts anymore, and simply needs to ask a question (can the user do this?) and act on the Yes/No answer.
3. Sharing existing permissions. Authorization-as-a-service also means that we might have several applications doing the same thing from an Authorization perspective (For example, “Can the user view the customer’s name?”). If this is the case, a central AM solution allows having a single consistent permission that multiple applications consume, as opposed to duplicating it across all of them, which would guarantee inconsistencies and discrepancies down the line.
4. Having a single pane of glass. As organizations grow in size and complexity, the information about “who can do what” becomes an asset in itself, to be leveraged for security, compliance and legal reasons. If the legal team asks “what do Recruiters in the IT department have access to?”, having a centralized AM solution gives you the opportunity to provide a holistic and swift answer. Otherwise, it becomes a painful process of submitting requests to multiple applications (in the range of the hundreds or even thousands of them, depending on the organization), following up on them, checking on the completeness of the results, harmonizing them for consistency, etc.
5. Implementing consistent governance. Identity and Access Management is an extremely critical function, always at the core of Information Security. As such, it is under close scrutiny from governance and regulatory compliance. Often, multiple controls need to be put in place in order to ensure that risks are mitigated and minimized according to the appetite of the company. Having a single AM solution means that these controls need to be implemented only once, centrally and in a consistent fashion, instead of doing so for each of the consuming applications, thus replicating effort and introducing inconsistencies in the governance approach.
6. Improving usability. Clearly, offering users a single interface where access requests can be managed and submitted will be a much friendlier experience than expecting them to interact with hundreds of applications, with inconsistent processes and usability. Making it easier for users to perform these access management activities will only result in less waste (that is, inappropriate access) in the long term.

Once such an AM solution is in place, we manage to transfer all of these IAM-specific concerns to a central component, and we can allow the consuming systems to ignore them and carry on with their actual purpose. Of course, we have not focused here on the actual requirements and implementation details of such a solution, which is by all means no easy feat. But I trust that the fundamental concept of “Authorization-as-a-service” is clear and its benefits self-evident in order to allow organizations to grow and step into a new reality where flexibility and dynamism are going to be paramount.