Tag: xacml

Anyone can kill off a protocol a.k.a XACML isn’t dead

There’s a little bit of a kerfuffle going on in XACML-land. A non-Gartner analyst made the claim that XACML is dead. Such a claim doesn’t go unnoticed; so Gerry, Anil, Danny, and Remon have all responded that no, XACML isn’t dead. It is not pining for the fjords. It isn’t even zombified.

Anyone can declare a protocol dead. Last year it was SAML. This year, apparently, it’s XACML. Now as someone who killed off the entire IAM industry, I think I’m in a position to comment about this.

It’s easy to say X is dead. SAML, SPML, DSML – doesn’t matter – you declare it dead, write your blog post, and call it a day. But what’s hard to do, and what is necessary to do, is, if you kill something off, you have to offer an alternative. In the case of IAM, I believe we are seeing the hazy outline of what it will become reborn as start to emerge: something more nimble, developer-friendly, and more indistinguishable from business services.  In the case of XAMCL, no alternative was provided.

Just a few things to keep in perspective when thinking about XACML. First, separate externalized authorization management (EAM) from XACML. Enterprises have been doing EAM for decades. The pattern of using something like RACF as a decision-as-a-service facility is a well established practice. Although enterprises may not be using XACML, they are doing EAM and that will only continue.

Continue reading Anyone can kill off a protocol a.k.a XACML isn’t dead

Nailing Down the Definition of “Entitlement Management”

Ian Yip’s take on access management versus entitlement management can be partially summed up with this equation:

Entitlement management is simply fine-grained authorisation + XACML

I have four problems with this.

First, definitions that include a protocol are worrisome as they can overly restrict the definition. For example, if I defined federation as authentication via SAML, people would quickly point out that authentication via WS-Fed was just as viable as a definition. So in terms of an industry conversation, we need to make sure that our terms are not too narrow.

Second, I fear that this definition is a reflection of products in the market today and not a statement on what “entitlement management” is meant to do.  Yes, most of today’s products can use XACML. Yes, they facilitate authorization decisions based on a wider context. But who’s to say that these products, and the market as a whole, have reached their final state? Along these lines, I wonder if externalized authorization stores are a required part of an “entitlement management” solution?

Third, there is something missing from the definition – the policy enforcement point. A fine-grained authorization engine provides a policy decision point, but that still leaves the need for an enforcement point. This holds true whether an application has externalized its authorization decisions or not.

Finally, I have a problem with the phrase “entitlement management” (just ask my co-workers). As I have blogged about before, Kevin and I have been in the midst of a large research project focusing on role management. One of the things we have learned from this project is that enterprises do not use the phrase “entitlement management” the same way we do.

A bit of history – three or so years ago Burton Group, at a Catalyst, introduced the phrase “entitlement management” to include the run-time authorization decision process that most of the industry referred to as “fine-grained authorization.” At the time, this seemed about right. Flash forward to this year and our latest research and we have learned that our definition was too narrow.

The enterprises that we talked to use “entitlement management” to mean:
·      The gathering of entitlements from target systems (for example, collecting all the AD groups or TopSecret resource codes)
·      Reviewing these entitlements to see if they are still valid
·      Reviewing the assignment of these entitlements to individuals to see if the assignments are appropriate
·      Removing and cleaning up excessive or outdated entitlements
More often than not, we found that our customers used “entitlement management” as a precursor to access certification processes.

Using a single term (“entitlement management”) to span both the run-time authorization decisions as well as the necessary legwork of gathering, interpreting, and cleansing entitlements can lead to confusion. The way enterprise customers currently use “entitlement management” works well to describe how legwork is vital to the success of other identity projects.  (I’ll be working on a report this quarter that delves deeper into this.)

I am all for a broader conversation on fine-grained authZ versus entitlement management. And as Ian Yip has pointed out on twitter, identity blog conversations have dropped off a bit and I’d love to stoke the fire a bit.  But we can’t have meaningful conversations without shared definitions. So what’s your take? What do you mean when you say “fine-grained authorization” and “entitlement management?”

(Cross-posted from Burton Group’s Identity blog.)

Considering identity consolidation

James has provided me more to work with…

Identity consolidation says that I figure out how to get user stores out of my enterprise application and instead get these applications to bind at runtime to a directory service such as Active Directory.

Ah, so identity consolidation is centralized authorization.  Got it.

I am making the assumption here that when James says user store he means authorization store.  (Applications in this model still need some modicum of a user store if nothing else for auditing purposes.)  I am assuming the implication here is that after authentication comes a round of authorization that the directory service provides.  The application would consume this authorization data, at runtime, and act accordingly.  Theoretically, an enterprise policy (XACML) store could theoretically reproduce the authorization models of every application in the enterprise today and that policy tools would interact with this store.  Though I think this is a very viable model for customer applications (especially J2EE and .NET), I do not see it as an enterprise approach where complex applications like mainframe security and ERP roam free.

Identity management says that I should go create a strategy around provisioning of identity and leverage tools such as Sun’s IDM, Thor, etc where I still fundamentally allow enterprise applications to have their own user stores and takes me down the path of building lots of connectors… [snip]  I am of the belief that identity management (provisioning) propagates and encourages an otherwise bad architecture.

I look at user provisioning as dealing with the reality (and foreseeable future) of the enterprise landscape.  That landscape involves lots of user and authorization stores.  For reasons I discuss below, that is not going to change any time soon.  It is better to provide flexible, short time-to-value solutions, as identity management does, that address the reality of today than to wait for the ideal enterprise landscape to arrive at its glacial speed.

I disagree with James’ assertion that user provisioning requires the construction of connectors.  The connector wars of the provisioning world are over.  Connecting to systems like a complex bespoke application or RACF or SAP has become a science, not an art.  On the whole, provisioning doesn’t require connector construction; it requires configuration.  Each provisioning vendor worth their salt has a way of quickly connecting to “unknown” systems that don’t require core engineering efforts.

The one thing that I would also love insight into is how to get vendors who still insist on having their own user stores (e.g. Documentum, Alfresco, etc) to see the error of their ways and to take quick steps towards remedying them.

I think you’ll find the reason the vendors give on maintaining their own user and authorization stores is much the same reason why they have yet to adopt Service Provisioning Markup Language in a meaningful way.  There is nothing in it for them.  Nada.  The only vendors who might stand to gain (and thus adopt) centralized authorization are mega-vendors like IBM who have dozens upon dozens of applications.  For these vendors, producing a common auth store with the requisite halo of tooling becomes a path to customer lock-in.  “Ms. Customer, you can use AuthStore 5.0 to manage all of the authorizations for all of our products.  And here is AuthManage 6.0 to help you do just that.”  And if the customer ports their bespoke applications to the common auth store, the vendor gets big-time lock-in.  Want to get rid of XYZ Vendor?  You’ll have to reincorporate authorization stores into your applications. I have to imagine externalizing an auth store for a homegrown application would be painful, undoing that work even more so.

Stepping back to what I originally wrote about: no amount of centralized user and authorization management will make up for a lack of strong organizational and business process understanding coupled with appropriately defined controls.  That is the fuel for identity management and, frankly, identity consolidation as well.