As we go into 2025, I’ve seen a number of different articles and posts around what is going to be critical this year in IAM. I think a lot of what I have been seeing and consensus has been Non-Human Identity, passwordless / adaptive authentication, identity verification, and (interestingly) dynamic authorization. I could see everything in the list, but the curveball I saw was the authorization. I’m not disagreeing by any means in terms of it making the list, I participated in a few webinars / posts around authorization and risk signaling and think it’s one of the most underrated, miss understood, and challenging areas of IAM so think it should be there, was more just interesting to see if come up. In seeing this, I started asking questions of why now, why is this becoming important, and what are the challenges in implementing it. I’ve got a few projects I’m working on that have authorization components, but figured would be good to start the conversation in terms of how I look at dynamic authorization and simplifying it. Hopefully, by the end of this post I’ve helped explain why now / what dynamic authorization is and how it can simplify your life and help reduce risk, reduce overhead, and improve security.
I think authorization has always been in the forefront of planning, but the main driver that is bubbling up the conversation now and how we think about it is two-fold in my mind.
- We are accelerating cloud moves, micro-services, and service driven models which is requiring more and more complex authorization which current implementations cannot handle. We’re trying to include too many claims, groups, etc. in tokens or just not doing it at all (security through obscurity?).
- AWS made a big splash in the market with their Cedar / Verified Permissions service to externalize authorization within AWS and external applications that want to integrate with AWS.
Both of these are forcing people to start looking at authorization and how authorization is done in their applications.
To start, and to align expectations a bit, authorization at its core is defining allow / deny based on situation, event, target, etc. All things being equal, can I or not! Simple enough, but why is authorization today so complex? I could say that we’ve built too many models, groups, entitlements, etc. which has ballooned the complexity, but I think those are all masking the crux of the problem. When I look at dynamic authorization, I look at the simple idea of ‘asking the question: am I authorized or not’ and who you ask this to. Traditionally, we’ve not asked that question and therefore built local authorization models and systems in applications and infrastructure to apply permissions at the local level. Yeah, we may consume some attributes (e.g. groups) to help make those decisions, but ultimately most applications are making local decisions based on data they master or extend from external sources. This has worked to a certain degree but does not scale when you start looking cross-platform which means more groups, roles, etc. that need to be made. Additionally, is an authorization level in a local application going to be extended to another application that wants to check / validate it?
Why is it important to ask the question? I kind of equate this to any ask, unless you ask the question you never know the answer and must make your own decisions. So, to simplify dynamic authorization, we simply need to start asking the question. Is a user / process / principal authorized or not? Once you can start asking that question to a central authority, you can start applying consistent policy across application, infrastructure, and organization boundaries.
To put this into perspective and why asking the question is important. Lets take an example of 2-3 applications that are part of an organization. In a traditional authorization model, organizational policy defines that need-to-know principals and least privilege access must be applied. To implement this, each application may have user repository that defines the user, their authorization level, and fine-grained permissions in the local applications. There may be a central group, role, etc. that is managed by a governance platform that does coarse-grained authorization (e.g. can they launch it) but the remainder may be managed and enforced locally. In this model, a user change, permission change, policy change, for the most part may require changes at each individual application. Now, looking forward, if you have a central policy that can make and define decisions (e.g. is employee, is in department, is approved for access), each application can ask the question of the policy (authorization service) to check if a principal is authorized in that moment AND what they are authorized to do. Now, going cross application / platform, you have a single authority / policy that can define who is allowed / denied if and when needed.
To further extend this idea and to reinforce the improvements made here, once you have a central authority that can respond real-time, you can start looking at central context and risk signaling. Why is this important? Using the previous example, if I want to only allow access to data / elements based on locations, MFA levels, etc. then that may require changes in each application to detect and enforce that. In a central authorization model, that decision can be made if / when asked based on the current risk signaling for that principal. E.g. I log into an ERP platform from outside corporate walls and all sensitive data in obfuscated until I connect to VPN / affirm MFA.
With all the groundwork established and the understanding that we simply need to start asking the question, the second challenge is going to be picking a standard for the language and central authority. While around for a long time as an idea, and even implementation (think the old Oracle Entitlement Server (YIKES) and XACML work), we are still seeing different standards for the policy language. You have things like Topaz, OPA / Rego, and Cedar (along with XACML) all competing and providing similar functionality. Additionally, you now have the AuthZen specificication that was recently proposed in 2024. Which is the best to use? Honestly, its going to be an implementation decision on where the authorization policy is stored, is it accessible in the oauth / oidc provider, how are attributes and data derived / resolved for decisions, etc. The best bet here is to start defining what authorization needs, technology, etc. you have and look at the below recommendations on doing prep and evaluation.
When you start looking at authorization for your 2025 and beyond planning and centralization of decisions, the critical ideas you need to establish that will help in your decision making should include:
- Who defines the policy (coarse grained and fine-grained) for authorization today? If you have multiple disparate authorities (between departments / business units / applications), you should inventory these authorities and decision making on authorization levels.
- How is authorization defined today? Do you have row / attribute level, location, coarse / fine grained? All this is going to play into how you move this to a central policy and authorization decision.
- Where is the data stored to help make authorization decisions? Is this in a single repository, is it resolvable over REST / web services or in database? All this needs to be resolved so that authorization decision data can be resolved if / when needed.
- Do you have organizational requirements for contextual authorization that may have internal / external factors (e.g. geo-fencing, training requirements, etc.)?
- How and when are you going to ask the question? Is this at login with enrichment, at access time, and enforcement points?
While is a simple idea in terms of thinking about authorization, as you can see the questions above, it can get complex as you start unraveling things. But, moving to central model for authorization decisions will help consolidate this effort and rely less on distributed disparate implementations of authorization.
If you’re looking to read more into authorization for your own learning, below is a few links and vendors I find helpful and are always publishing good content.
PlainID Blog / Webinars: https://www.plainid.com/identity-security-posture-management-learning-hub/
Aserto Blog: https://www.aserto.com/blog
Open Policy Agent (OPA) / Styra: https://www.styra.com/resources/
