Dynamic Authorisation was one of the most misleading terms in IAM space, at least for me. The word dynamic implies a capability for the ‘on the fly’ changes and while it’s true, it’s not providing a full picture of the concept, which is much wider. For complex organisations for example it’s a very cost effective way of achieving authorisation in the Zero-Trust model.
So, what’s important in the dynamic authorisation these days and what do experts mean by it?
Building blocks of authorisation
Let’s have a quick look at the basics. We’ll be using those abbreviations later, so here are the building blocks of authorisation.
Policy Decision Point (PDP)
That’s the where the decision is made. This is the brain of the operation. For example, a bank officer who approves your mortgage application. The officer will look up the information about our credit score, check our history within the account, our financial capacity etc. and make the decision. In this case it’s a binary ‘YES/NO’, but in the context of authorisation there may be a grey area. I always make a joke and refer to it as ‘YES/NO/COULD BE/MAY BE’. You may receive certain conditions or obligations from the PDP, for example, you can get a new mortgage if you pay off your credit card.
Policy Information Point (PIP)
That’s the fountain of knowledge used to make the decision. On its own, may not be enough to make the call. Let’s go back to our example of the average Joe trying to get the purchase of a new house financed. The bank officer (PDP – policy decision point) checks the credit score system to ascertain the risk of issuing finance to that person. Furthermore the officer may want to check for any convictions or proceedings that are underway in relation to financial crimes. Those two example databases will be the policy information points equipping the decision maker with the tools to make the right call. The important bit is that there may be (and usually is) more than one PIP (policy information point).
Policy Enforcement Point (PEP)
That’s where the decision is enforced. It’s quite obvious in IT, but let’s try to link it to our example earlier. The bank representative we would see in the branch, usually won’t make the decision. She or he will enter all the details into the system and pass it on for the decision to be made. Usually it’s taken care of by a specialist team, who only deal with mortgages. The process is then approved (or not) and the representative is passing on the decision to the customer. The representative is the Policy Enforcement Point (PEP).
Policy Administration Point (PAP)
That’s where we set the parameters and the structure of the policies. A firewalls’ user interface is a PAP for the network filtering solution. You can think of it as of a governance team, too. Going back to our example, a bank would have a group of experts who would define risk levels the bank is happy to operate within (this could be regulated) or the level of security checks the applicant has to undergo in order to get a finance application approved. The PAP (policy administration point) would define that in order for A to happen, B has to be in place. A and B are delivered via PIP (policy information points) and the rule is fed into the PDP (policy decision point), so it can be enforced in PEP (policy enforcement point).
Subject, object, context, action
If we dive deeper into the policy, we encounter 4 main parameters. Subject is the who (the bank’s customer – the average Joe), object is the what (the finance, the mortgage), context is the narrative (the conditions under which the request is made, for example if the person is applying for the credit in their branch or in a branch 200 miles away) and action is the consequence (in our case it’s the bank financing a purchase of the new house).
The three components of a modern dynamic authorisation service
1. Attribute Based vs Role Based Access Control (ABAC vs RBAC)
A classic RBAC (role based access control) says if the user is a member of the administrators group, she or he can restart the system (power cycle). This is very restrictive and lacks granularity, too. For example, we may allow the admins to restart our servers but ONLY outside of business hours. This may well be a regulatory requirement in financial markets. Let’s look deeper. I want to make a change to a payroll system in which a wage of a specific employee is going to go up significantly. Do I need to create 20 roles to group those employees and feed them into the policy, so I am ONLY allowed to do the thing I am supposed to? In the role-based world, usually the decision point needs to change in order to alter the behaviour of the decision process.
What’s the ABAC (attribute based access control) then? Well, in attribute-based approach we make the decisions based on specific attributes assigned to the subject or the object. This may be a group membership (a remnant of RBAC), but it may well be a list of applications, which we load dynamically into the policy or a specific attribute of the user itself. Imagine, a policy that says THOSE USERS can access THESE APPLICATIONS, if their role is a MANAGER. We don’t need to add the users into the manager’s group and check the membership (RBAC), all we have to look into is the profile of the user to find if they’re a manager – of any sort.
The fact that we dynamically load these attributes also means that in order to make a change in the policy decision point – PDP (influence the decision), we don’t actually have to touch the policy at all. We just change the attributes of the subjects or the objects. For example to add an application to a list of software allowed on our MDM (mobile device management) managed phone, we add an attribute to the app itself and not the policy.
2. Fine vs coarse grained authorisation
The granularity. These days, it’s not enough to say you can open this file or this data set and do whatever you like. We now may have many more conditions, for example: I may be able to access a database to read customer’s information, but only those who are non-government organisations and only within UK business hours. A good dynamic authorisation engine allows for the fine grained logic of SUBJECT – OBJECT – CONTEXT – ACTION. For example: payroll staff – employee wages – during yearly salary review (January-February) – make changes. Let me write that in a human readable form. A member of a payroll department is able to change how much one earns (give payrise hopefully) but only during the corporate wide yearly review process which takes place every Jan-Feb.
3. Externalised vs integrated decision
In other words authorisation as a microservice. Decoupled from the application itself. The application uses it in order to maintain appropriate security levels but is reduced to what we rudely call a ‘dumb endpoint’. Let’s have a look at an example. I am going into my office, which is open from 8am to 6pm. I have a contactless pass (an ID) that lets me into the building. I put the card against the reader at the door, which is connected directly to the electromagnetic lock, which in turn activates, releases the door and lets me in. Now, the reader itself doesn’t make the decision whether to let me in or not. And it’s not so simple either. After all I may be able to enter the office because I work in the building, but only within business hours or I may only be able to access specific areas. The reader (the application, in our case a policy enforcement point – PEP) connects to the security system (policy decision point – PDP) and provides all the necessary information the who (a person), the what (the specific door), the context (what time) and the consequence (let the person in). The security system then checks its PIP (policy information points) for an information about the person and makes the decision. In this case it’s a binary YES/NO.
Why is this so important and what’s so special about it? Well, it means that the developers don’t have to do anything in their applications to comply with authorisation requirement apart from asking the external system for a decision. Policy decision points aren’t usually code orientated, so the business logic is configured and managed even by non-technical staff. It means that we can channel the efforts into what the application is about and have a reusable pattern for authorisation, no matter how complex or specific it is. It also means that it’s somewhat centralised. If we need to add a new policy information point – PIP (for example a new credit check service), we only have to do it in the decision point regardless of how many applications we run.
The how – sideband vs in-line
If you think about all the logic from the payroll example, being handled by the application itself, that’s a lot of code… Instead, imagine the world where the user requests the data via a proxy of sorts (an API gateway for example). In the authorisation realm – a PEP (policy enforcement point), rather than directly from the application. The proxy checks for the decision, and receives the following: this user can only read customers information who are privately owned. Remember the ‘dumb’ endpoint, I mentioned earlier? That’s the application. The proxy requests all the data on behalf of the user from the app itself (gets everything) and then, based on the earlier authorisation decision forwards the output – MINUS the information which should NOT be provided. Neat, right?
There are two ways to achieve the above behaviour. In line is where the proxy is effectively two in one. A combined decision and enforcement points (PDP+PEP). A sideband setup is where the policy enforcement point is separate from the decision point and asks for a decision based on parameters and then processes the request.
Hopefully it all makes sense and you can now see the benefits of dynamic authorisation and how it could be applied in your organisation.