Talking Identity

Seems like the recent Catalyst conference led the Eternal Optimist, Pam Dingle, to question how we are doing as an industry. It is true that a lot of the messaging has shifted from what enterprises need to accomplish based on their unique needs to "check-off the list" buzzwords like GRC (which Bob Blakely called a "four letter word"), RBAC and User-Centric.

Pam's definition about why Enterprises should invest in identity is not new, nor has it never been said before. But it seems like periodically, people need to reiterate the message to remind people that they should keep their eye on the ball. Too many times, the people going into identity projects do so because of a corporate mandate, with little understanding of why exactly they need to do it, or what the needs are that they are trying to address.

But I don't quite share Pam's pessimism expressed in the second half of her post. When she asks

The really interesting question will be whether or not the big vendors will ever start enabling truly integrated provisioning and SSO support for the full range of their products. 

I think she asks a question that many have been asking, and some of us are starting to work on. The key word here is "work", because the vision for standardized identity services is still just that - a vision. Reality is that there are a number of enterprises out there that are implementing identity services strategies on their own, but there is no concrete way for COTS and SaaS applications to rely on identity services for these critical functions. Even Oracle's work in this area (which I have been blogging about for a while) is proprietary at this point, and very much driven by the vision for Fusion Applications that is articulated in Pamela's hope for stack offerings with an "integral adherence to an identity vision, instead of bolted-on adherence". This is one of the main reasons why I have joined the Identity Services Working Group that the Burton Group is running, to work with the community on defining the missing pieces that can make identity services a cohesive solution that all applications can be built on.

I got news today that MySpace is joining the OpenID revolution. This supposedly brings the number of OpenID-enabled accounts to over half a billion. Maybe it looks like good news for OpenID, but isn't this actually a problem? Isn't the intent of OpenID to reduce the number of logins we have? Why am I moving from having 50 username-password credentials to 30 OpenIDs instead of 5?

I wanted to go on a rant, but I see that Adam DuVander over at monkey_bites beat me to it with a much more eloquent one than I could have come up with. I found this part especially priceless:

But Yahoo stopped short — they aren’t letting people use their non-Yahoo (Open)IDs to log in to Yahoo. That’s not OpenID support. That’s essentially Passport 2.0.

James McGovern has challenged my position that applications should not be written to go directly against AD. And he got the backing of Jackson Shaw in this argument. James says:

If pretty much every Fortune 500 enterprise has Active Directory, why should any of them consider yet another product?

Martin (no last name) left a comment on my post that included the following point:

AD is the directory in just about every organization running Windows. Let me see. What does that work out to be? 99% of them out there?

Here is my point. Martin says "AD is the directory...". I say that "AD is a directory...", and that too because Windows forced it on those enterprises, not because of their Identity Management needs. Yes, almost all the Fortune 500 have AD, but are they using it as an Identity Store, or as a Windows Account Store (which is very different)?

Obviously our opinions are shaped by our experiences. My experiences, coming from the provisioning world, would be different from James or Jackson's. In a lot of the projects we were involved in, AD was a downstream repository, a target of the provisioning system and not the source of identity data. That was usually an HR system or, more often, a Sun directory. Most of the time, the provisioning system would push the bare minimum attributes to AD to enable the Windows environment to work.

In a few deployments, we actually were responsible for populating a directory with identity data so it could act as an identity store for other applications. Most of the time, that directory was a Sun directory. So while AD may be more widely deployed, I would contend that based on my small but relevant sample size, Sun is dominant in the Identity Store business. And that is really what we are talking about here - what should applications be going to for their identity data. Sure, AD being more widely deployed positions it to be used as an identity store, but that is seldom the case, primarily because AD administrators often closely guard their environments and do not want it overloaded with data or consuming applications.

Again, when James asks about practical futures, my hope is that the future eliminates all such arguments about directories and metadirectories by having applications code against Identity Services APIs, like the IGF APIs or the Higgins IdAS APIs. James asked what we at Oracle are doing to help application developers. Clayton mentioned our work on the IGF, and the APIs that are being defined as part of it that eliminate the need for application developers to have to worry about LDAP, instead providing simple APIs that use a provider model to get the data from where it needs to. And I have joined the Burton Groups Identity Services Working Group (now that it is open to vendors), where I hope to work with the community to help advance the concepts and reality of Identity Services. Hopefully, soon, this will be a question that nobody will need to ask any more.

By the way, why is it that architectural purists don't ask when Microsoft will make it possible for Windows environments to work against any directory and not just AD, but Oracle Applications must support directories other than OID? In the end, both Microsoft and Oracle are wrong to push proprietary stores into deployments, contributing to the mess we have.

Ian Glazer thinks that I have opened Pandora's box by talking about the need to bring context and intent into the area of RBAC by using relationships (one of many ways to express context). I think it's a topic ripe for some discussion, so I'm glad to be the one taking the lid off.

Mat Hamlin left an interesting comment on my previous post, in which he tried to understand what exactly I was trying to say. He asks:

In your scenario, is Patient Y in a particular Role that has a relationship with the Attending Doctor Role?  Or is it attribute based?  Role to Role relationships could be modeled, but real-time, logic based Role to attribute (or individual) relationships fall outside Role definition, IMO.

There are too many scenarios pertaining to the relationship of the two individuals (and the surrounding conditions).  What if Doctor X is not allowed to treat infants, and Patient Y is an infant.  Or what if Doctor X is a contractor and is not allowed to treat patients with a certain insurance? Or has this patient ever reported a complaint against this doctor? What if this data changes often?

Let me explain how relationship-based roles are defined, and how they address the scenario I posed in my previous post.

When discussing Relationship-based RBAC, one will usually find that, by necessity, the access control policies are defined by people different from the people who will manage relationships. Thus, the admitting nurse or the triage desk may create an "Assigned Doctor" relationship between Dr. X and Patient Y when Patient Y is admitted. These people, working the front line, are unaware (as they should be) of access control issues and needs. Their job is to simply find a doctor to assign the patient to. They are usually the ones making decisions about the creation of the relationship based on things like whether the patient is an infant, what specialization the doctor has, etc.

The folks designing the access control policies in the back-end systems want to set up a policy that defines what the doctor assigned to a patient has access to in the system - charts, history, personal information, etc. So they define an access control policy that states that anybody in the "Attending Doctor" role has access to resources "Charts", "History", "Personal Information", etc.

The real meat is in defining the "Attending Doctor" role, and how it is used in the system. A relationship-based role is a new kind of structure, different from statically defined roles, or dynamically-defined (Attribute-based) roles that we see commonly in systems today. Most roles simply have a member concept, and an authorization decision based on a role simply looks to see if the interacting user is a member of the authorized role. However, a relationship-based role has a member relationship concept, with each relationship having two end-points. So in Relationship-based RBAC, the authorization decision is based on looking at the member relationship of the role, and determining if the interacting user is one end of the relationship, while the protected resource is connected to the other end of the relationship.

Thus, you can have 100s of doctors connected to 1000s of patients using the "Assigned Doctor" relationship, but 1 "Attending Doctor" role that knows how to handle those many 1000s of relationships in its authorization context.

This is a very powerful concept, especially as social graphs start making their way into enterprise application contexts. So we are going to see more need for systems that handle this kind of need.

Well, I think I am done talking about directories now, especially after reading Ian Yip's hilarious recap of the debate, as it were. Having now appeared as a significant bit player in this drama, I have decided to leave it in the hands of more capable people like Clayton and am moving on to familiar (and hopefully fertile) ground.

Day 2 of the Catalyst Conference turned towards the more pragmatic topics of role management and provisioning. It was with a great deal of interest that I heard Tim Weil discuss a standards effort he is leading to promote the implementation and interoperability of RBAC components. As I understood it, the goal is to make it easy for roles defined in one system (say ORM or SailPoint) to be used in another system (OIM or Sun IM), without having to do massive integration projects. Burton's Kevin Kampman has blogged about this if you are interested.

Tim's perspective on this is very relevant, having dealt with such practical issues through numerous implementation projects while at Booz Allen Hamilton. It was this very perspective that I wanted to tap into by asking him a question that vexes me a lot, but he gracefully sidestepped since it wasn't directly related to the talk he was giving. However during a Twitter exchange with Ian Glazer I promised to explain my side fully in a blog post, so here goes.

My Question To Tim

Is the NIST RBAC standard fundamentally flawed, given that it is missing a key element in access control decisions - relationships, the very thing that Burton spent day 1 of the conference stating was the missing link for IdM to tackle?

My Thesis

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.

My Rationale

In a conversation later with Ian and Lori, I illustrated my case with the following access control examples:

Scenario A

A doctor wants to enter a hospital he is assigned to, presumably using a physical access device like a Honeywell card. In order for the doctor to get into a hospital, all he needs is for his identity in the system to have a "Doctor" role that is checked for when he enters the hospital. This is a simple scenario that the NIST RBAC standard can easily take care of.

Scenario B

However, in order for that doctor, Dr. X, to view the medical charts (electronically) of a particular patient, Patient Y, the good doctor not only needs to have a "Doctor" role, but also needs to have the "Attending Doctor" role WITH RESPECT TO Patient Y. In other words, the Access Control around the medical charts is based on a specific relationship established between Dr. X and Patient Y, that could be expressed as a relationship-based role. NIST RBAC seems to be wholly unequipped to handle this use case.

NIST RBAC is an important tool to any discussion on role structures. But it should not be treated as complete by any means, merely a start. The use case illustrated in Scenario B is rapidly becoming the more common use case, as Fine-Grained Authorization needs and Data Security come front-and-center in the discussion around Access Control. Yet work on resolving such scenarios is currently excluded from discussions on RBAC and left up to the ABAC (Attribute-Based Access Control) crowd. Having two different mechanisms to implement security (often in the same systems) will surely lead to more holes than a chunk of swiss cheese.

Those that feel this is promotion for our ORM (formerly Bridgestream) product should know that it is not, since the relationship-based roles concept that they created has so far been limited to approval use cases, and has not made its way into any access control discussions. One reason I feel this isn't happening is because it seems no one has figured out how to express this in an XACML policy, which can easily handle ABAC, but not Relationship-based RBAC. This led to the next controversial question I asked at Catalyst, which I will bring up in a later post.

I'd love to hear other perspectives on this, so leave me some comments.

Ashraf Motiwala has called me out for saying that the way applications are supporting AD directly as the identity store is by using Virtual Directory, both in a comment on my post, and on his blog. I guess in my enthusiasm to get a response out to Matt's post, I wasn't careful enough about my words and mis-stated what I was trying to say. But that's the beauty of the blogosphere for you, there's always someone around to correct you (slap you around a little). And at least now I know that my feeds are working post-migration :-)

I did not in any way mean to imply that the majority of applications that are coming out with support for AD do so using a Virtual Directory. What I was actually trying to say (poorly in the end) was this: "And how are more applications looking to support AD anyway? A lot of that has to do with the emergence of Virtual Directory solutions". Let me talk about this separately in the context of Custom and COTS applications.

There are a large number of custom enterprise applications that support LDAP that were tied to a particular directory, usually something non-AD (most application developers would develop against free LDAP systems like Sun). This was a reality that proved to be a boon for provisioning vendors (like us), but a curse for provisioning implementers, as we then played the role of populating these non-AD directories from the main AD infrastructure. A lot of those same applications are now looking to support AD in addition to (or in place of) what they already supported OOTB, and from what I see, they are doing so by shifting to a Virtual Directory based approach. This shift seems to be specific to custom in-house applications (where Virtual Directory lock-in, a great point raised by Jeff Bohren, is not considered as big of an issue) and is prevalent in heterogeneous directory environments, where AD may be dominant, but is not the only directory available. Virtual Directory provides a nice abstraction to avoid having to deal with the heterogeneity of the environment, and allows consolidation of the spread out data into a single view. This is not really a concern in pure AD shops, but there are few large enterprises that are purely AD.

As for COTS application vendors, I mentioned what Oracle is doing with regards to their strategy on how to support multiple directories. And from talking to a few other application vendors, they are also tired of having to maintain connectors for every single major directory out there. This is one of the main reasons why there is an on-going effort to see if Oracle Virtual Directory can be made an embedded component (as opposed to its own server), something that is part of the middleware stack, so that it can act as a "directory connector" service in the application environment, freeing up applications from having to code against the idiosyncrasies of the individual directories. It is also a reason why so much emphasis is being put on some of the standardization efforts in Higgins and IGF.

Now, this is not to say that a lot of applications are not being built to go directly against AD, with little regard for other directories. All I meant was that from my vantage point (and it may be a skewed one because we are Oracle, so I am more than happy to have people contradict me or correct me on this), a lot of people are looking to support AD without getting locked into AD, and that is driving demand for both OVD and other alternatives.

James asked some good questions with regards to what Oracle is looking to do to help resolve this issue. I'll get to those in my next post.

Update: Clayton has chimed in with some articulate and well-thought through responses, complete with examples, to this whole discussion. I should have just waited for him to come back and take this up instead of sticking my little neck out there :-)

I doubt it. I doubt that there will be a last word on metadirectories for a long time to come. Technology that works has a way of sticking around, even when they have outlived their purpose, and are forced into the substrate of a new and improved "solution". But I did want to respond to a couple of things that Matt Flynn brought up in his post "Metadirectories Aren't Dead (They're Just Aging)".

First, he outlined a use case that he (I think) postulates is best solved by Metadirectory. I won't recount the whole use case here (read his post to get it), but it involves three identity stores (HR, AD, and a DB) and synchronization between them of attributes that each one is authoritative for. My answer to his question "Is a virtual directory the best solution to meet these needs?" is "No, it isn't, but Virtual Directory + Provisioning is". Which is exactly what my post that he was replying to posited.

Now, I'm not trying to be glib here. Metadirectory can definitely solve this use case. But it will be a point solution. The "Aging" that Matt refers to comes into play when you consider that this use case will inevitably be added to with requirements for approval workflows, compliance and privacy controls and upgrade issues. Metadirectory (and Virtual Directory alone) would never be the right solution for those needs because (like Virtual Directory) it is simply an IT tool lacking the Business layer that Provisioning provides. So, the solution will require provisioning. In my experience, there is always a need to look forward to what is coming next before deciding on the solution, which is why in my (relatively medium-term) career, I have seen way too many customer requirements that try to bolt-on provisioning onto an existing metadirectory deployment because it was falling short. A number of times, the metadirectory was stripped down to a mere shell of itself as most of its functionality was moved into the provisioning solution.

I may be biased here (coming from a provisioning background), but nobody is simply looking for point solutions any more. And in any case, my hope is that eventually all of this will go away as we move to Service-Oriented Identity (as Burton calls the Identity Services concept).

Matt goes on to state:

There has been a ground swell of apps that directly support Active Directory as the user store. So, maybe the next versions of the HR and LOB apps in the above scenario would attach directly to AD eliminating the need for any solution here. As prevalent as AD has become, that seems more likely than mass-consumption of virtual directory technologies. And it's probably what Jackson was alluding to (Quest enables *nix systems to leverage AD).

Well, from the standpoint of a deployer/implementer, I can certainly understand the attraction of the above. But as a product architect and technologist, all I can say is "No, No, No". Why would we want to tie ourselves into a non-competitive, no-way-out scenario that we see repeated over and over in the OS and Mobile Provider worlds? Choice is necessary, nay vital, to innovation and growth. The minute you lock yourself into a single provider model, you are doomed to forever be curtailed by what that provider dictates. Virtual Directory provides a nice abstraction that frees you from having to make these very decisions on which directory to support (something LDAP was supposed to do, but didn't).

And how are more applications supporting AD anyway? A lot of that has to do with the emergence of Virtual Directory solutions. A number of applications in the Oracle stable today claim to support AD as the identity store. The mechanism for all these is moving to Virtual Directory NOT because Oracle has a Virtual Directory product, but because maintaining adapters/connectors/plugins and what have you for all LDAP variants is a colossal nightmare.

Metadirectory is aging, but the IdM industry is a lot like the ruthless fashion world, where age has no place except for a few niche areas.

One of the big announcements at Catalyst that I twittered about was the formation of the Information Card Foundation (take that, OpenID). The purpose of the non-profit foundation is to promote the use of information cards as a secure way to present personal identity information on the web. The foundation has a power-packed set of companies as steering members (Oracle is in there along with Google, Novell, Paypal, Equifax and, of course, Microsoft) and a great Board providing direction with people like Kim Cameron, Pamela Dingle, Patrick Harding, Ben Laurie and Drummond Reed (among others) leading the way.

Information Cards try to mirror the familiar, real-world experience of presenting cards to prove identity and provide information in the online world, and aims to do so in a safe, secure manner that is resistant to phishing, pharming and MITM attacks. Despite having been put into the wild a few years ago, and despite the tireless efforts of people like Kim Cameron and Pam Dingle to make it accessible, there are scant few web sites (of any note, anyway) that actually allow people to use information cards. The ICF (much like the OpenID foundation, which also kicked into high gear a few months ago) is looking to put some weight behind the effort to evangelize the technology and expand its adoption in the marketplace. As it states on the ICF Web site, the foundations purpose is to

Advance the use of the Information Card metaphor as a key component of an open, interoperable, royalty-free, user-centric identity layer spanning both the enterprise and the Internet.

It will be very interesting to see how the ICF goes about doing this, and when results will start to show. But this is undoubtedly the beginning of something big. For all of us.

Links:

• Press Release announcing the ICF
• New York Times article
• SC Magazine coverage

Another Catalyst conference has come and gone, leaving us with a lot of material to chew on and ponder. Burton always forces us to think about what we are doing, especially those of us that have products to deliver. And it's always interesting to see all the new companies that are popping up in the space (Lori's slide this year showing all the identity management companies looked like it needed a magnifying glass to read).

I'm not going to recap all the interesting sessions that I attended. If you followed my twitter postings (and a big "Hi and Thank You" to everyone who tripled my following last week by connecting, including some folks who signed up for Twitter just to follow me), you got a sense of what was being talked about, and my thoughts on the same. For some great reporting on the key sessions, read Mark Dixon's blog postings (this post is a map to the various posts he has written covering the conference).

I'll simply present what I saw as the theme of the conference: Reality Hits The World Of Identity. People are realizing that the only way this identity stuff is going to work is if the online experience and constructs mirror how we operate in the real world. And this opens up a whole set of new areas to explore.

You Complete Me
A key realization that is taking hold is that relationships must be made a key part of the fabric of identity, and that relationships can form the trust basis for identity related transactions. While I don't completely agree with Jamie's assertion that a lot of work in the real world happens before any contracts are drawn up (no contractor can even begin work for Oracle until a contract is signed; similarly I can't work for Oracle and get access to systems till an employment agreement is in place), I do recognize that the value proposition of transactions is a continuum, along which are different levels that require different levels of assurance. Assurance can be built up over time as a function of relationships (user is related to this company, user has X friends, user is certified by this identity provider, etc). Eve Maler gave a very interesting talk on how relationships can be nurtured and made available in the online world, and connected it to some of the work being done on R-Cards and Project VRM.

I Need An Authority Figure
Another sign that real world concepts are seeping into the online world was the increased discussion on the topic of Identity Proofing, and the externalization of Authoritative Identity Providers. Just like in the real world, companies are realizing that in order to scale  and distribute liability, they would like someone else to be responsible for vetting identity data and providing a validated, trustworthy identity into their environments. This is the first sign of a legitimate market emerging for the Identity Oracle that Bob Blakely has defined, and that I have discussed so often in the context of Identity Services. The Liberty Alliance has jumped in here to help out by proposing an Identity Assurance Framework (our old friend Frank Villavicencio is co-chair of the effort) that can define a trust language in this context. And everyone knows that I consider the work being done on the IGF a critical part of such an infrastructure.

I Got Your GRC Right Here (Not!) 
Burton decided to take the IAM vendors to task for using GRC as a crutch to sell all manner of products. Referring to GRC as a four letter word, Bob attempted to blow up the myths surrounding GRC and posited that all the bluster around GRC has made companies lose sight of what they really need to address. He stated that each discipline conflated within GRC should be looked at independently by businesses with regards to its objectives, and that tools and processes should be put in place that address the specific needs identified. The message was clear - there is no such thing as a GRC product; instead there are a multitude of products that provide tools for addressing specific problems that fall under one of these disciplines, and enterprises should take a fresh look at what GRC means to them and how to approach it.

For me, the highlight of the conference was the talk by Nick Leeson, the securities trader who brought down Barings Bank. Not a technical talk at all, his explanation of how his actions exploited failings in the areas of governance and compliance drove home the point about process and tools being complementary parts of the puzzle.

The rest of the conference had some interesting announcements and decent discussions on the usual topics of Authentication, Provisioning and Role Management. I did what little I could to break the monotony and generate some controversy, but I'll cover all of these in my upcoming posts.

We'll see about the improved part. But the long awaited migration of the blogging platform (check out some details here) to Movable Type has finally gone live (phase 1, that is), and I am back to blogging again.

Being knee-deep in Catalyst last week means that I missed the week-long period where we could check out the new platform, get trained, and fix the production instance before go-live. So my apologies to everyone who will have to bear the brunt of the glitches that are bound to show up while I get used to the new platform. I have spent the last 2 days burning the midnight oil trying to get everything set up correctly on the new platform (this included me going through every post and adding tags to them, plus checking images). My blog sidebar is new and improved, and I have been able to do some real interesting things there, like:

• Putting together a tag cloud of my top 15 tags, with a link to the complete tag cloud
  
• Finally having recent comments show up
  
• Adding a Blogroll powered by my subscriptions in Google Reader (so you actually see what I read)
  

Update to My New RSS Feed URL
If you subscribe to my blog using RSS, the old feed should continue to work. However, you will have to encounter a nasty glitch where all my posts will get marked as fresh new posts, so they will get downloaded again. Sorry about that, but it's a side effect of the upgrade.

That said, in an effort to improve my feed and get better statistics, I am finally using feedburner to source my feeds. So if you still feel like subscribing to my feed, please update the feed URL to this new one: http://feeds.feedburner.com/TalkingIdentity
(Again, seems like a lot of feed readers don't provide a way to simply update a feed url. You have to unsubscribe from the old and re-subscribe to the new url, unless you want to keep getting duplicate feeds).

Also, thanks to Feedburner, I can offer email subscription to those that don't use RSS readers, and simply want to get an email in their inbox any time I post. Just follow this link and provide your email address.

Leave Me Some Comments
Again, since the upgrade just went live today, and I am still working out the system, let me know if you encounter any glitches. I appreciate any and all feedback. Oh, and feel free to be the first to leave me a comment on the new platform. Comments was one of the things that didn't work very well on the old platform, and it really prevented me from getting a dialogue going. I would much prefer to have a discussion with my readers than do this all one-way.

Back At Work