One of the topics I’ve been evangelizing for years is Dynamic Authorization Management. Dynamic Authorization Management is about externalizing authorization decisions outside of applications. It is about using an “application security infrastructure” which performs the authorization decisions (and manages other aspects of security like authentication, the administration of users etc.). It is about relying on security services instead of implementing security in every application.
Dynamic Authorization Management is often associated with XACML (eXtensible Access Control Markup Language). XACML in fact is a standard to implement Dynamic Authorization Management, but the concept must not be limited to XACML. In fact, Web Access Management systems implement the concept of Dynamic Authorization Management in a coarse-grain approach and some of these systems as well as some of the Policy/Entitlement Server products available provide their own, proprietary APIs.
Before discussing the best approach to implement Dynamic Authorization Management it is important to understand the basic principles and their benefits. Within the concept of Dynamic Authorization Management, an application asks the authorization system for authorization. It provides some information with this request, e.g. the user ID etc. Depending on the implementation, other attributes might be delivered in addition. The authorization systems take this information and collect additional information if required. It might ask an authentication system for more context information, receive roles from a directory service etc. It then uses that information and the business rules (authorization rules) received from a policy repository to decide about authorization. Having done that, it provides the decision back to the requesting system.
The obvious advantage is that applications do not need to manage users, authentications, or authorizations. They just ask a central (logically central, but potentially physically distributed and logically “partitioned”) system. There is no longer a need to manage authorization rules within the application. Thus there is no need to provision that information into that application.
That in consequence means that there is also no on-going need to revoke access. IAM (Identity and Access Management) is not about “ensuring that access is revoked correctly” anymore, because there is nothing to revoke (from applications). There is also nothing to grant anymore within the applications.
Everything is managed centrally. Changes are made centrally and become effective immediately. While Identity Provisioning will decrease in relevance, Access Governance will remain important. Identity Provisioning will have to cover far less targets than today, when few central instances are used as repositories and target systems do no longer hold authorization information locally. Access Governance will have to move from reviewing static access control in target systems to reviewing dynamic business and authorization rules in the central authorization system – a feature which is supported by some early adopters in the Access Governance market.
A strength of this concept is that such systems not only can enforce standard authorization rules but also business rules. Many role management projects suffer when it comes to supporting “competencies” or “constraints”, e.g. limits for the approval of POs etc. This is fairly simple to implement and enforce in Dynamic Authorization Management.
The concept in fact is not really new. In the mainframe world, it has been around at least since the mid ‘70s – you just need to look at tools like RACF, but also several proprietary implementations of large organizations for their “entitlement management systems”.
However, there is no such thing as a free lunch. The obvious challenge is performance – can such a system be fast enough for today’s business needs? The best answer is given by the users of these systems: Large banks and large eCommerce sites are relying on these approaches today.
The biggest challenge in reality is that applications have to change. That in consequence means that the way applications are architected and developed has to change. The mindset of application architects and application developers has to change and these groups have to collaborate closely with the IT Security and IT Infrastructure people. However, done right architecting and coding applications will become easier given that architects and developers no longer need to ‘bake in’ authorization, authentication, etc., but can simply rely on the external service. Obviously, providing lean and simple approaches for Dynamic Authorization Management is a key success factor for this type of technology.
Dynamic Authorization Management is not about a rapid change, it is about moving towards a better model over time. To do that, you should start now. Every single application is a win on that journey. Security risks and complexity of management will be reduced. And Dynamic Authorization Management will allow you to focus on the key issue: Allowing people to do exactly what the business wants them to do (and not more) – instead of technically granting and revoking access per application.
As always, there will be several sessions around Dynamic Authorization Management, XACML etc. at this years’ EIC: Munich, May 14th to 17th.