Posted May 13th, 2009
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. Continue reading "Nailing Down the Definition of “Entitlement Management”"...
Posted March 17th, 2008
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. Continue reading "Considering identity consolidation"...
what others say