06.03.2013 by Martin Kuppinger
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.
14.08.2012 by Martin Kuppinger
Axiomatics, a leading vendor in the market of Dynamic Authorization Management systems – sometimes called either Entitlement Management or Policy servers – has recently released a new tool called the ALFA plugin for Eclipse IDE. ALFA stands for “Axiomatics Language for Authorization”.
With that tool Axiomatics allows developers authoring XACML 3.0 policies in the widely used Eclipse environment using a syntax which is close to commonly used programming languages like Java or C#.
This is a pretty nice tool which closes a gap around XACML development. Instead of having programmers creating XACML policies in XACML by hand or using the administrative tools to create the policies with drag&drop approaches, they can create policies the way they are used to – in an environment they are used to.
And ALFA is far less complex to use than native XACML. There is a nice video available which demonstrates creating a 107 line XACML file with 19 lines of ALFA code (pseudocode, to be correct). Some other interesting features are the support for Eclipse functionality such as syntax checking and auto-complete to easily create policies.
Axiomatics again, as with their Axiomatics Reverse Query (ARQ), proves that they are thought leaders around XACML. They address one of the challenges around the use of XACML and Dynamic Authorization Management in general with that tool.
You might raise the question whether the developer really should create XACML policies. The answer is: It depends. In an ideal world, these policies are defined by business in a way that completely hides the underlying policy language like XACML. But there are use cases where developers might create the policies, especially for point solutions. And many of today’s projects are developer-centric and targeted at specific use cases. So there is a clear value ALFA provides. But it needs all of the above: ALFA for developers, tools for administrators with some XACML knowledge, and simple tools for the business integrated with approval workflows and into the overall policy and access management approaches.
For developers, there is the need for having approaches like ALFA. That’s one important piece in making Dynamic Authorization Management easier to implement and use. The other piece is PEPs (Policy Enforcement Points) which allow relying on XACML policies without knowing anything about XACML. So ideally a request to a Dynamic Authorization Management system is little more than a line of code calling a method but should be fully transparent regarding the backend.
Axiomatics is making good progress in making XACML easy (i.e. transparent) to use – by improving user interfaces, by more PEPs out-of-the-box, by ALFA. That is the right approach, I think.
10.05.2012 by Martin Kuppinger
Recently I read a blog post from my appreciated and well known analyst colleague Kevin Kampman at Gartner Group talking about entitlement management. That post had some points which made me wonder. I’ll pick some of the quotes:
- “One of access control’s biggest challenges is that it has often been an academic exercise. Maybe we can move the discussion forward by thinking about what is needed, not just what is possible.”
- “For any object, a set of conditions should be met to provide access such as time, attribute, role, etc. it seems we need a more flexible way to characterize all of the conditions that need to be met for access to be granted. Not attributes about the object itself but what you need to bring to the party to play.”
- “A lot of the focus in the *-BAC world is what attributes IT can provide to represent these conditions. It might make more sense to describe the conditions needed to characterize access.”
There are more, but these are some which I feel the need to comment on. Let’s start with the first one. I would agree that role management in its early days, when it first became mainstream, sometimes really was too much of an academic exercise. But if I look at the reality of projects today, that’s no longer the case. Role management is well understood and there is a lot of knowledge available on how to successfully implement role management in practice.
Going further to what dominates the evolution of Entitlement Management today, we have to look at Dynamic Authorization Management. Here neither the evolution of XACML as the key standard nor of claims as a related and somewhat overlapping approach is driven by theorists. Furthermore, most of the products in the Dynamic Authorization Management market like the ones of CA Technologies, CrossIdeas, IBM, or Oracle are derived from projects and the customer needs therein. They were built for practitioners from the very beginning. Even while they might not be perfect yet, they definitely are not the result of academic exercises. Consider also that Axiomatics, which started with strong focus on the XACML standard (and is one of the most active supporters of defining the XACML standard) is strongly led by customer feedback and experience from real world implementation projects.
My perspective is that the biggest challenge for Entitlement Management today is the organizational and process maturity of the customers, when it comes to defining business roles and business rules and when it concerns identifying the players in the business organization which have to participate. IT has become better in supporting IT business/alignment but still has some work to do on that especially with simple interfaces for defining business rules in Dynamic Authorization Management products and further improving the business interface of Access Governance tools. But this again is not the result of being too academic.
Regarding the second aspect: Despite the criticism I sometimes have articulated regarding XACML as being a standard which is too complex for the end users (which I still believe is true), the underlying concept of implementing business rules is simple. Yes, it is annoying to write XACML, but that is true for any type of XML. Still, any business user can easily define the rules in a structure that can be used by XACML – this is straightforward and simple to understand.
And in that concept (and other approaches for Dynamic Authorization Management) it is very simple to express the full variety of rules, from more technical ones to pure business rules using business-provided constraints or competencies. This is focused on objects – but the objects can again be anything, from a piece of information (like a document) or its representation (like a share) to business activities within business processes. This is all there – so it is fairly simple to use it. And the same concepts can be used for all types of use cases. You can rely on a subset of the same set of policies for versatile, context-based authentication and authorization (which again provides attributes for other decisions) and for the internal authorization in a business application which needs to enforce complex business rules such as for the approval of new insurance contracts.
Having said this, we arrive at the third quote. Don’t we describe the conditions today? I’d say we can do it and we frequently do it, not only within Dynamic Authorization Management but also in more advanced concepts around Access Governance . These concepts go beyond roles today and can use concepts of constraints or competencies. Some implementations are tightly coupled with business activities and business processes.
By the way: Introducing a term of *-BAC doesn’t seem to provide much value to the customer. We have RBAC (which, in the NIST approach, is somewhat academic – but not in real world). We have used the term ABAC (Attribute Based Access Control) sometimes in the industry, with attributes describing any attribute which can be used within policies, including roles as a specific type of attribute. So ABAC covers everything and *-BAC only leads to babel.
Simply said: My view on the state of Entitlement Management, Access Governance, and Dynamic Authorization Management is fundamentally different from the one in that other blog post mentioned above. It think that the industry is much more mature. And not too academic.
09.05.2012 by Martin Kuppinger
Due to a last minute speaker change I had to prepare a short presentation on „Dynamic Authorization Management – Best Practices from our Advisory“ for EIC 2012. When we found a replacement for the speaker, I didn’t give that presentation. However I will do a webinar on that soon and I want to provide some of the content here, as sort of an appetizer.
Dynamic Authorization Management is about dynamically deciding to approve or not authorization requests provided by services (like applications) based on policies and attributes (roles, application used, context, whatever,…). It includes policy definition and management, the access to sources for these attributes like directory servers, databases, ERP systems, and systems for context- and risk-based authentication and authorization. A key standard is XACML. The role of Dynamic Authorization Management within overall IAM (Identity and Access Management) is defined in the KuppingerCole Scenario Understanding Identity and Access Management.
A key success factor in Dynamic Authorization Management is to bring participants from all the different siloes involved to the table. You need people from the business organization, you need application architects and developers, you need IT Security, and you need others. This is a complex challenge.
Another key success factor is to set the right scope and to start small enough to be successful. The design has to cover coarse-grain and fine-grain authorization. It has to look at all types of applications and users. And thinking about the “Identity Explosion”, that means that it has to cover authorization not only for employees, but for many other types of users.
When planning the environment, the positioning of the Policy Enforcement Point (PEP) and Policy Decision Point ( PDP) (more information on XACML, PEPs, and PDPs here) is one of the challenges. Vendors provide a lot of flexibility – and you need to understand the different options to meet the performance and scalability requirements of your environment. This becomes increasingly complicated in cloud environments given that it is hard to run a large number of queries across long distances in an efficient way. So approaches like providing access controls statically to systems might come into play. Clearly, putting a lot of thought into the concepts is a key success factor, especially given that Dynamic Authorization Management has to cover more or less all of your distributed environment.
Acceptance by developers is directly related to simplicity. Keeping things simple for developers is also one of the key success factors. You should start thinking about applying the paradigms of the Open API Economy here.
The same is true for policy definition. The good thing is that the way policies are described in XACML from a conceptual perspective (so without the XML stuff around) is pretty straightforward, simple to understand, and powerful. Nevertheless you have to educate your business users in expressing their business policies and translate this for the IT level. And you shouldn’t underestimate the complexity of auditing and analyzing policies in a dynamic environment.
However, when putting sufficient work into the concepts, you can design a Dynamic Authorization Management environment today which is future-proof. You should also do it because that will help you to become much more efficient in the management of Information Security and much more agile in fulfilling today’s and tomorrow’s audit requirements.
19.12.2011 by Martin Kuppinger
During the past few years, Quest has acquired several other IAM vendors: Völcker Informatik (Provisioning and Access Governance), Symlabs (Virtual Directory Services), Vintela (Linux/UNIX Authentication and Integration), and e-DMZ (Privileged User/Account Management) are just some examples of this shopping spree. The newest addition to the Quest portfolio is Bitkoo, a vendor in the Dynamic Authorization Management space (http://jacksonshaw.blogspot.com/2011/12/quest-acquires-bitkoo-and-dives-into.html).
This acquisition comes as no surprise given that Dynamic Authorization Management is one of the most interesting amongst the emerging segments within the IAM market. Dynamic Authorization Management is about externalizing authorization decisions from single applications and performing them against centralized backend systems, based on centralized rules. Instead of hard-coding security into applications and instead of having to maintain authorization rules in a lot of different applications, Dynamic Authorization Management systems build the backend for such decisions.
Dynamic Authorization Management thus is a core piece of identity and security services and “Application Security Infrastructures”, i.e. the set of services applications rely on when externalizing identity and security. Such services include administration (for example using central directory services), authentication (best based on versatile, context-/risk-based authentication), authorization (Dynamic Authorization Management), and auditing/alerting. The latter is sort of the missing piece, and in that area there is a lack of standards. But that is a topic I’ll cover in another post.
So Quest has acquired Bitkoo. That is not surprising given that Bitkoo fits well into the Windows-centric strategy of Quest. It adds to the portfolio, making Quest one of the vendors with a comprehensive portfolio of IAM solutions. Quest is, from the breadth of its portfolio, playing in the same league as the well-known big vendors in that space like CA, IBM, and Oracle (which, by the way, all have something to offer around Dynamic Authorization Management). Quest has shown a clear strategy in acquiring other vendors over the past years. Now it’s up to Quest to tell this message to the world, proving that they are more than the corner store selling a mish-mosh of tools for administrators. Quest has another portfolio now – and that makes them a really interesting competitor in that market.
This acquisition will most likely also increase the attention on Axiomatics, the most prominent specialized vendor left in the market of Dynamic Authorization Management. Axiomatics is on one hand the independent alternative – and on the other hand the obvious acquisition target number one now that Bitkoo is part of Quest.