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.”
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.