Posted April 8th, 2008 Between her open letter to application vendors and roles versus rules, Pamela Dingle is kicking up a lot of dirt. I tend to agree with most of her points as I have written about here. However her following point bothers me; I’m not saying I disagree with it completely but it sits oddly with me:
In the case where two roles are assigned to the same person, but should never be simultaneously applicable, Enterprises have limited choices. If, however, there is a layer in between the consumer and the provider that lets you mask roles based on user-chosen context, in my mind this problem goes away. I don’t see how you can do it without the user part — but perhaps I’m just not thinking hard enough
Granting the user a choice, in fact, requiring the user to choose their context is not something that an enterprise in this day and age can do lightly. It requires a constant monitoring capability. It requires a method to unwind the user’s privilege set at any point in time into business digestible policy statements. It requires a way to map user action, their total privilege set and enterprise/business policy to each other – not easily done. Trust, verify and then cross-validate. In this litigious hyper-audited world, I am not sure that enterprises can realistically enable user-chosen contexts without a raft of infrastructure that, today, is not well integrated enough.
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"...
Posted March 16th, 2008 James recently picked up on my Identity leprosy or identity zombies post and writes:
Ian believes that identity needs brains but falls into the trap of thinking about identity solely from the perspective of provisioning and while avoiding runtime aspects. I wonder if he would blog on why enterprises should consider identity consolidation over identity management?
Before I respond I’d like to get some clarity. James, give me a more to work with and I’ll happily write more. Help me understand that which you are contrasting between “identity consolidation” and “identity management.” Help me understand how provisioning doesn’t have runtime implications.
Posted March 10th, 2008 Jackson, in discussing the demise retrenchment of HP’s identity business, had this little gem:
We talk about Identity 2.0 in the context of Web services and the evolution of digital identity but our infrastructure, enterprise identity “stuff” is decrepit and falling apart. I have visions of identity leprosy with this bit and that bit simply falling off because it was never built with Web services in mind.
Bits falling of, eh? I’ve never heard of someone losing their core directory services because someone forgot to add XACML support. I’ve also never heard off someone loosing an ear because their provisioning system didn’t support SPML v2. Enterprise identity “stuff” is more like a zombie. It lurks in the dark corners of your enterprise. It staggers out at you at inopportune moments. Two other aspects of this ridiculous image that are valid:
- The identity zombie is incredibly hard to kill.
- The identity zombie needs BRAINS!
“They stab with their steely knives…” Once deployed, even in rudimentary forms, enterprise identity systems are amazing difficult to uproot, to kill. Homegrown systems are notoriously tough to maintain as well as replace. Even worse were those early attempts at vendor provided solutions. Before IBM/Tivoli bought Access360, it had Tivoli User Administrator. TUA… one of the banes of my existence. The thing wouldn’t die. The customers who got it running were actually in love the rotting smelly thing. They kept it on a steady diet of scripts (BRAINS!) that served as connector definitions and entitlements all rolled into one. It just ran and ran and ran. From what I heard, early BMC Control/SA customers are much the same. Continue reading "Identity leprosy or identity zombies?"...
Posted November 14th, 2005 I was thinking about the role management panel at Digital ID World in New York this weekend. My first reaction to the panel discussion, which consisted of BearingPoint, Prodigen, Bridgestream, and Thor, was that roles are finally growing up. The idea that roles require lifecycle management just as identities do is, at first, a little shocking but then makes a great deal of sense. Working in the enterprise provisioning market for years, I got used to hearing how hard it was to complete a role deployment. At the same time you had Burton Group and others professing the value of roles. Customers were fighting both the difficulties in deploying identity management solutions as well as the difficulties in understand and leveraging roles. As the industry provided better automation for the provisioning problem, we saw deployment times go down. But, roles were still tough to deal with. We are now seeing tools to help truly automated the role lifecycle management problem.
One of the points that was agreed upon by the panel members was that business roles are separate from IT roles. Who I am in a company is very different than my privilege sets in target systems. Some provisioning products attempt to make this distinction. By elevating roles to a discipline that truly needs its own tooling, we will be able to manage that distinction far better than we can today. I do wonder if potential customers will still look at roles as too difficult and not address them appropriately. “Roles are hard. See… they have to have tools to deal with them,” I can hear a potential buyer say. To this, I often respond with a wink, “IT would be simple if we didn’t have end-users.” Continue reading "Attack of the YAMS: Thoughts on the Role Management Panel at Digital ID World"...
|
|
what others say