Tag: saml

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

Will the “real” federated provisioning please stand up?

Nishant has commented on my post about federated provisioning.  He has provided two different examples of federated provisioning.  One of these, the advanced provisioning example, involves a company who manages its employees’ access to a service provider service via provisioning.  In this case, Nishant agrees with me that provisioning of this sort is no different than provisioning the UNIX box down the hall.

 

But it is Nishant’s second example, the just-in-time provisioning example, which is a bit tougher.  In this case, the enterprise and its service provider have a federation in place.  Using SAML-based authentication, a new user attempts to access the service provider’s service.  The idea (hope?) is that the service provider recognizes the new user request, provisions the user, and authenticates the user in the same conversation. Nishant does add a degree of difficult in this scenario as he ties the federation service to a provisioning service.  Grabbing attributes from the SAML token, creating a SPML message, and handing that to a provisioning service is possible, but as a commentator points out this sort of interop isn’t spec’ed out so the heavy lifting is left to the service provider.  And even if the service provider doesn’t want to directly link its federation and provisioning services, it still needs to grab that assertion attributes and create the account in the backend system. 

 

It turns out, to my surprise, that there are people doing this.  Parties in a federation agree to which attributes are needed and send those in their authentication assertions.  A process at relying party uses those attributes to provisioning new accounts.  This is a fairly lightweight and effective approach, but there are some catches to be aware of.

 

The first catch, as Nishant points out, is if the service provider needs attributes above and beyond what are in the assertion, there’s not an easy way for the service provider to ask for them.  To deal with this, the service provider has to present a registration screen of some sort to the user.  Compared to the first scenario in which the federate account is already waiting for the user, the second scenario is herky-jerky and will annoy/confuse the end user.

 

The second catch is deprovisioning.  The provisioning process hinges on an authentication event.  Deprovisioning cannot be activated on de-authentication.  This does leave the problem of how to remove accounts when people have left a federation partner.  In the approaches we have seen, when a new account gets built it has an expiration date associated with it that gets updated on every login.  After some period of time without an authentication, the account is suspended or deleted.  Not a bad way to go.

 

JIT Provision may in fact be “real” federated provisioning, but not provisioning, as a dogmatic, dyed-in-the-wool provisioning guy would immediately recognize.  While I take my dogma for a walk, this quarter Lori and Bob are going to looking into some of the intersection point of identity management and SaaS and I think they’ll have more to say on this type of conversation in the coming months.