Posted 1:52 PM (0) comments

Identity-centric

Pam Dingle has a bit of a rant today about the term "user-centric." Well, not about the term itself but about people's desire (e.g., the entire Burton Group) to get away from it.

"Sure, there are a few blind worshippers of the cult of user-centric out there, but I firmly believe that common sense has to win out in deployment scenarios, and that various technologies should and will be used where applicable to solve problems. "

"If, on the other hand, all this is about is finding a positive, all-encompassing touchy-feely name to give to the systems-formerly-known-as-user-centric so that isn’t all about conflict, fine — pick a new name already. I only ask that if you’re going to diss the current buzzword, can you please at least supply an alternative suggestion. Otherwise we end up in limbo where nobody wants to use the old term, but nobody has a new term either, making us all look like indecisive idiots."

I think it's about more than just a term, more than just a feel-good quality, Pam. The "User-centric" term was coined, initially, to try to differentiate internet-based individual identity protocols from those used within the enterprise. But it's really all identity, and there doesn't need to be a distinction. That's why I wrote, last month, "Why there's no 'user-centric' or 'enterprise-centric' identity," where I said:

"Enterprise-centric identity management, we postulated, is really all about tying together all the activities and attributes of a single entity into a readily accessible (and reportable and auditable) form; while user-centric identity is about keeping various parts of your online life totally separated so that they aren't accessible and no report can be drawn.
So how do we have a framework that allows for both tying together all of a user’s activities (enterprise-centric) while at the same time allowing distinct separation of activities as decided by the user?
We start by defining identity as a group of “personas” (see 'Defining identity, persona, role'). Any persona can be made up of a group of personas or roles. Each of those personas can be linked, or separated, as the entity identified by them wishes. One of those personas is (or, rather, could be) an 'enterprise persona.' That one brings together '…all the activities and attributes of a single entity' performed for or related to that enterprise '...into a readily accessible (and reportable and auditable) form.'
So there is no 'user-centric' or 'enterprise-centric' identity. There is just an entity with AN identity made up of various personas some of which may be controlled or limited in some way by an outside organization – not only by the enterprise but also by governments, social organizations, etc. The ability to keep these personas separate, where legally able to do so, must be a given. Each persona will have different identity needs and requirements, of course, but that’s what will drive the 'identity economy' as vendors seek to satisfy those needs and requirements in accordance with the laws. The government’s laws, the enterprise’s 'laws', the fraternal and social organization’s 'laws' and the Laws of Identity as laid down by [Kim] Cameron. "

Labels: Burton Group, digital identity, enterprise, identity, Laws of Identity, persona, roles, user centric

Posted 8:06 AM (0) comments

Getting NISTy - UPDATE

Oracle's Nishant Kaushik has a great post today attacking the NIST RBAC standard as fatally flawed.

He asks the question, "Is the NIST RBAC standard fundamentally flawed, given that it is missing a key element in access control decisions - relationships...?" and answers himself: "It is, and companies looking to the NIST RBAC standard as the template for how to approach role management are going to end up missing the boat."

I'll simply say that I find NIST's RBAC to be about as useful as the ISO network model - a great tool to tailor a discussion around, but really worthless as a practical implementation. Alternatively, you could thing of it as being in the same relationship to actual role implementation as the Dept. of Defense's ADA programming language is to Java or C#.

There has to be a better way.

UPDATE: My sometime drinking buddy, Archie Reed from HP, has posted a good summary of the current thinking, planning and drafting of standards for role management and RBAC.

Labels: RBAC, roles, standards

Posted 8:21 AM (1) comments

The role of roles

Ian Glazer has just released his first post since signing on with the Burton Group, and it's a good one, about the wrong-headed notion which appears to be taking hold in the market place that roles and role management are needed before provisioning can occur. As Ian puts it:

Implicit in the idea that an enterprise cannot attempt user-provisioning because it is not ready for role management is the notion that user provisioning has no value to the enterprise without role management. This is an outdated argument that is simply not true.

In fact, the opposite is true - roles, while not requiring it, will benefit from a good provisioning implementation.

Look at it this way, even without computer-based Identity Services people need to be provisioned into the resources they will use. eProvisioning simply automates that task. While the concept of roles may be present, roles-as-a-tool is only useful within a digital context.

Acquiring, piloting, prepping and rolling-out provisioning services should really be a no-brainer decision, especially today - almost 10 years after eProvisioning was first introduced - when so much of the setup and rollout is scripted, wizard-ed, template-ed and cookie cutter-ed. It's easy to demonstrate the efficiency gains (and the budget gains) from provisioning apps & services. There's also the fact that the successful launch of a provisioning service establishes a baseline and a platform for creating the rest of a full-blown identity services implementation, even beyond role management. Govenance, Risk Management, Entitlement Management, Security Audit, Simplified Signon, Priveleged Account Management and more have a much better chance of being successful if they follow a well executed provisioning rollout.

Labels: Burton Group, provisioning, roles

Posted 9:01 AM (2) comments

Cisco gets entitled - updated

Cisco Systems announced this morning a definitive agreement to acquire entitlement management leader Securent, Inc.

I've disagreed with Securent CEO Rajiv Gupta on some issues, notably the use of role management in identity and entitlement systems, but I can't disagree about this move - it makes a good deal of sense from Securent's perspective.

Entitlements, usually linked to applications and the rights and privileges users have within those applications (as opposed to standard operating system rights to access the application), should also be linked to the field of Network Access Control - NAC (which Cisco calls Network Admission Control). From that point of view its also a good move on Cisco's part.

Whether or not it advances Identity Management at all, though, is open to question. Cisco, certainly, has a view of identity that's very much at odds with other major technology vendors. As a hardware company, it tends to focus on the platform, not the user. It's important to remember that all those "things" in the network have identity, but not at the expense of the people using those things. By the same token, Securent might be thought of as focusing too narrowly on the rules and not seeing the users who the rules are built to support.

I don't think this signals a round of acquisition activity for entitlement management companies, but only time will tell about that. In the meantime, keep working on your Role Management rollout.

UPDATE: As someone pointed out to me, Securent will join Cisco's "Collaboration Software Group" which, as far as I can tell, is the group responsible for WebEx and not much else. The group is headed by Don Proctor, formerly Senior Vice President of the Voice Technology Group, a remarkably unsuccessful branch of the networking powerhouse. In looking around the Cisco web site, in fact, they seem more of a candidate to become a Securent client rather than an acquirer - unless John Thompson Chambers (thanks, Ian!) wants to keep the technology all to himself!

Labels: acquisition, entitlement, roles, security

Posted 3:31 PM (0) comments

Oracle to buy BridgeStream?

Dan Primack, over at PEHUB, threw out a rumor the other day that Oracle was about to acquire BridgeStream, the role definition and management company. I've followed the privately held San Francisco startup for the past couple of years, and even just last summer believed that acquisition wasn't in the cards just yet:

"With some preaching a top-down approach of creating roles based on business rules and practices while others advocate a bottoms up approach emphasizing audits and data mining of what people actually do, there's no definitive "best practices" for role creation. While it seems obvious that, eventually, a synthesis of these methods will emerge as the standard way to create and manage roles, there's still enough diversity in the marketplace that the big identity management vendors aren't willing to bet on the final outcome. Instead, they'll partner with many different role creation companies. That means that folks like Bridgestream, Eurekify, Trusted Network Technologies, BHOLD, Blackbird, Engiweb, Prodigen, SecurIT, and Vaau will maintain their independence for now with only the remote possibility that should any of them founder with customers their investors might seek to sell out at fire sale prices."

But I think I can give a fair amount of credence to Primack's rumor for two reasons:

1) Oracle is still on an acquisition roll, and getting deeper into roles makes sense for them;
2) Role management needs to be intimately connected to the IdM suite of products, something that simply parternering with an independent role management company doesn't give a major vendor.

Look for this to become official over the next week or so...

Labels: acquisition, bridgestream, oracle, RBAC, roles