#Identity as continuity. Thoughts inspired by #CISmcc.

I didn’t get to go to Cloud Identity Summit again this year. At least, not physically. I was there at a distance, attending via the very full twitter feed on #CISmcc. My experience was choppy. There were few slides. Ideas were filtered through the varied perspectives of the people tweeting. Then something odd happened in the middle of the whole experience. It changed the way I assimilated the ideas. Since attending at a distance also cuts off the nightlife, I spent the evening between the two major days of presentations knocking off a long standing item from my Netflix list. I watched a documentary based on conversations with Noam Chomsky called “Is the Man Who Is Tall Happy?” As always, listening to Chomsky talk linguistics and philosophy is a bit mind blowing. Then all these cascading connections began to form between the philosophical ideas and the identity ideas. That’s where the fun began. What struck me was a deep sense of irony. There is a stark contrast between the way ideas are progressing in identity and the advice contained in those ideas.

Walking into CIS, many were already primed with notions swarming around IRM (identity relationship management). That noise reached its pitch with Ian Glazer’s thoughts and the reaction to those thoughts (the links are only examples, there’s a ton more out there). Both implicitly and explicitly it felt like this debate was very present. Thoughts were flying by fast, but I sensed a tension that felt familiar. The notion that focus on relationship was paramount versus a focus on identities (or users) had a dynamic I recognized. It was only watching Chomsky that shook loose where I had felt that before.

At one point, the documentary talks about cognitive science. It treats the subject briefly. But I’ve studied it pretty deeply. That’s where the link is. There are schools of thought that focus on a homunculus based approach to mind, looking at the entities that make up thought mechanisms (e.g. brain cells, ideas). There are other schools of thought that focus on the connections (e.g. networks of neurons, or constellations of notions). I should say here that I know I’m slaughtering the heart of both of these schools of thought for the sake of brevity. Feel free to make me pay for it in the comments. But don’t think that will stop me now – in for a penny, in for a pound. This homunculus versus connectionism dynamic suddenly became very like the identity notions of user/identity centered versus relationship centered. The reasons I rejected the dichotomy of these cognitive science ideas began to seem relevant. The battle line between focus on the points versus focus on the lines that connect the points seems to be too artificial to me. In my mind, you only get realism with all of it included.

Imagine the difference between Abbott and Costello discussing the Middle East versus Mahmoud Abbas and John Kerry discussing the Middle East, or, if you prefer, the difference between Abbott and Costello doing “Who’s on first?” versus Mahmoud Abbas and John Kerry doing “Who’s on First?” Clearly, the people and their relationships both matter when you want a full understanding of how you should react to something. We can’t have a full understanding of how identity should react (in authentication, in authorization, in entitlement management) without understanding both the identity and the relationships in which that identity are currently involved. Both the current state of being and the current state of relationship of Abbas/Abbott and Kerry/Costello are informed – even formed – by the past states of being and the history of their relationships. To imagine understanding either the men or their relationships in some idealized, ahistorical setting is ridiculous. To me, it’s the same with identities and their relationships. It’s all or nothing. You need it all to answer the basic questions. Who’s on first? Exactly*.

I said there was a deep irony here. We need to go a level deeper to root it out.

By the way, if you want a bit more irony, you can go read about how Chomsky is actually a fan of discontinuity in the context of humans acquiring language while still maintaining the importance of continuity as a feature of how we conceptualize the world.

That artificial division of concepts, the burst and stop twitter feed, these discontinuities underlined another idea Chomsky brought into the discussion in the documentary: continuity. Continuity was discussed in many ways, but the basic idea was encapsulated in a children’s story. Sylvester the donkey becomes a rock, and then is turned back into a donkey later. Chomsky uses this to show how children don’t bind words and concepts tightly. If you ask a child if Sylvester is still a donkey, even when he’s been turned into a rock, they will say yes. The identity of Sylvester transcends his physical form. Chomsky calls this continuity. In the child’s mind, and I bet in most of ours, Sylvester is a being that is a donkey and having been turned into a rock doesn’t change that. The story’s dramatic tension is the contrast of form and identity. We’re happy when things are all right: Sylvester is again a donkey in form and identity.

I see continuity echoed in so many of the themes from CIS – and the wider identity threads with which we all weave our thoughts. My friend Nishant (if one can call a man who depicts you as a bizarre mix of Jedi and nun in front of large crowds a friend) raised the ever present specter of killing IAM, making the ultimate break in continuity. Bob Blakley (who gets a halo, not a habit, from Nishant) again pointed us to a future of continuous authentication. The heart of a dichotomy like IdM versus IRM suggests a lack of continuity. Make no mistake, the breaks in continuity also fit the trend. Chomsky brings up continuity specifically because so many people wish to set up a dualistic relationship between ideas labeled by words that map intimately to “real” objects in the “real” world. But, if Sylvester the “donkey” is still a “donkey” when he is a rock, that sort of dualism doesn’t fly. The map is in the mind and it’s drawn using the continuity we all sense. When we want to label things neatly, as we so often do in technical circles, we try to break the messy continuities that come naturally in a messy world. Identity is a messy business. Anything that attempts to sum identity up neatly must betray its core features. Sylvester is always a donkey because being a donkey is part of his identity. I am always Sander regardless of my company, my relationships to other people at given times, or the avatars with which I present myself to the world (habits and Jedi robes notwithstanding). We get so frustrated with these messy threads and the knots they tie us into that we want to burn the whole thing, kill IAM off in favor of a new shiny thing that will fix all the problems. Identity is an attempt to bind a narrative that spans a lifetime to single concept. That means we will have to deal with messy continuity, and all the things we killed trying to neaten up our ideas will rise up like zombies to join us again.

Continuity is a core feature of identity. The attributes, the relationships, the actions, the entitlements, the policies, the authentications have all been about something that has been a continuous thread. You can choose to describe it through the lens of its kinetic relationships and actions; you can choose to describe it through the lens of its associated attributes. The thing you describe remains the same. It’s the continuity of that thing which binds all those other concepts. This is where the irony sets in. As we try to capture this continuity over time, we try to break the threads, disrupt the stories. We worry about picking one of the two lenses, when we need both to correct our collective vision. We want to destroy what we’ve built to rid ourselves of the messy parts we didn’t like, but those are the parts that likely came closest to the essence of what we wanted to capture. “Things that let you do anything make it hard to do anything” said Ian from the stage. And I agree. Does that mean we look for a simple solution? What if we need to get close to that level of fluidity, that ability to do anything, to truly capture the kind of continuity that can let a rock be a donkey that’s physically a rock at the moment? If that sort of extreme continuity is a core feature of identity, then our identity management teapot needs to be strong enough to hold a tempest that strange. We can’t run away from the hard bits of our approaches to identity. Those may be the bits that are the best reflection of how hard it is.

This is not meant to be a Luddite’s cry. Bring on new standards. Bring on new ideas. Bring on new technologies. It is a word of caution. If our new ideas are simply about banishing the bits we didn’t like in the old ones, if we forego dealing with the messy continuity in identity or the complicated wisdom that may be buried in our old ideas, then we’re simply falling in love with novelty. We are hopping from one engineer’s honeymoon to the next. Here we find the deepest irony. It is ironic that we would take identity, which attempts to bind with continuity a myriad of disparate things, and attempt to break it up into neat pieces. The advice we scream at those building new systems is do not simply pick up the easy, familiar identity bits they know or fall in love with the novelty of a shiny new library. We tell them to consider the larger, likely messier whole. Use the standards even if that’s a bit harder for you right now. Take from the complicated (in appearance) fabric of identity that already exists in your organization or the wider web. Do it for the sake of continuity so you can reap the benefits later. It’s advice we should all keep in mind.

If you’ve read this far, then congratulations for navigating the deep waters of my odd mind! It’s taken over a week to get this out. If you think this was complex, you should ask for some of the notes.

---

 

This is linked to from above. It’s an entertaining side note from writing this I had to share. When I quoted “Who’s on first?” as saying “Who’s on first? Exactly.” I didn’t realize I was mixing up the actual script of “Who’s on first?”, where “exactly” never appears, with the lines from Purple Rain where they mimic “Who’s on First?” The funny synchronicity is that in Purple Rain the theme they use to mimic the routine is about remembering a password! Identity really is everywhere…

What I learned at @kuppingercole’s #EIC11: #identity #IAM #privacy and secrets

I must admit to being very selfish at this year’s EIC. Instead of going to the sessions that would likely have been most useful to Quest, I went to those that spoke most strongly to my own curiosities. The first thing I did was explore how vendors, users, and analysts feel about standards. It seems like it’s a chicken and egg subject – still. Users wait for vendors to adopt standards. Vendors wait for users and analysts to put force behind them. And in the mean time, only obvious success (SAML) and obvious need (XACML) seem to get standards investment and attention. The most interesting moment of this leg of the journey was when @OASISopen‘s Dr. Laurent Liscia asked from the keynote stage how many people in the audience were vendors to “make sure we’re not talking to ourselves.” Apparently we weren’t, but it was an interesting glimpse into how the whole notion is perceived even by those most dedicated to that cause of standards.

I also went to an absolutely fascinating deep dive into EU privacy and data protection law, which was hosted by Dr. Jörg Hladjk of Hunton & Williams LLP. Perhaps the most interesting thing I walked away with was a new sense of how fragile these protections really are. I think people in the US tend to think about these laws as being very intimidating and forceful. But that likely comes from the vastly complicated contract, audit, and procedure (paperwork) that is needed to deal with the laws. However, two shocking things became clear over the course of the day. First, any reasonable legal basis can be used as a basis to get at the data. A person can sign away all the protection in a single stroke – as anyone who agreed to the terms to get an iPhone in the EU has done in some part. And, because the framework is so much more comprehensive, things like a EULA, which is routinely cast aside in US cases since it’s seen as so flimsy, is much more forceful in the EU since the user is deemed to be so much better informed and protected by the framework. Second, there are cases where protections in the US are stronger than in the EU. A good example is when it comes to breech notification, where a data steward is forced to notify you of some event that may have compromised your PII. It seems that between NSTIC, efforts at the state level (like California’s new proposed “social media” law), and other things in the works, the US may actually come out ahead of the game in a practical sense within the decade.

The last lesson was a pleasant surprise: nearly all identity minded people are closet philosophers. Anyone reading this is likely to know my undergraduate (and only) degree is in philosophy, and perhaps also that I still indulge that impulse heavily as often as I can. Dr. Emilio Mordini, CEO of the Centre for Science, Society and Citizenship (CSSC), gave a keynote on the nature of secrets that was a HUGE hit. Not to say everyone agreed with all his views. In fact, @NishantK and @ggebel both took shots at his ideas from the same keynote stage later. The idea that drew the most criticism was Dr. Mordini’s very unpopular conclusion that one shouldn’t worry about securing data, but rather tracking data. He feels it’s less important to worry about keeping a secret than keeping track of who knows the secret. All of this flows from his central thesis that all secrets are Pulcinella secrets – not really secrets but rather, like a secret in a small town, something everyone knows but no one says so long as the parties involved have the power to motivate everyone to not say it in the town square. Tim Cole goes into all the details of the Pulcinella story on his own blog. The truth of all of it is left as an exercise for the reader. But the thing that made me happy was the abstract conversations in the hallways and bars for the rest of the conference as everyone digested the deeply interesting issues that were raised and what they meant in our shared context of identity, access, privacy, and technology.

Policy Translation – The Art of Access Control Transcends RBAC, ABAC, etc.

After some holidays, lots of internal meetings, and some insane travel schedules, things are settling back down this week just in time for me to head to TEC. So I can get back to spending time with Quest’s customers, partners, and having great discussions with people. In the last week, I had three excellent conversations, one with a panel of folks moderated by Martin Kuppinger from Kuppinger & Cole set up by ETM [link to podcast site], another with Don Jones and an audience of folks asking questions set up by redmondmag.com [link to webcast], and the third just today with Randy Franklin Smith [link to webinar site]. All these discussions revolved around managing identity (of course); they focused on the business’s view of IAM, wrapping proper security controls around Active Directory, and controlling privileged user access, respectively. Even though the subjects seemed quite far apart, a common question emerged: how do you translate the policy the business has in mind (or the auditor has in mind) into something actionable which can be enforced through a technical control? Put another way, the problem is how to take wishes expressed in business terms and make the come true with technology. To me, this is the central question in the IAM world. We have many ways to enforce controls, many ways to create compound rules, many ways to record and manage policies. But the jump from a policy to a rule is the tricky bit.

Let’s take an example and see what we can do with it. Everyone in the US and many around the world know SOX, and most that know it are familiar with section 404. There is a great wikipedia article about SOX section 404 if you want to brush up. Section 404 makes the statement that it is “the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting.” While this makes sense, it’s hardly actionable. And businesses in the US have relied on many layers of committees and associations to distill this. What is that process? It’s lawyers and similarly minded folks figuring out what executives can be charged for if they don’t do things correctly in the face of vague statements like the one above. So they come up with less and less vague statements until they have something they feel is actionable. Of course, what they feel is actionable and what some specific IT department sees as actionable may be quite different.

From the filtering at the high levels of the interbusiness activities you get a statement like “Understand the flow of transactions, including IT aspects, sufficient enough to identify points at which a misstatement could arise,” which comes from the work done by the SEC and POCAB to interpret SOX section 404. That approaches something IT can dig into, but it’s hardly actionable as is. But now a business can take that, bring it inside the organization, and have their executive management and IT work out what it means to them. Of course, there are scads of consultancies, vendors, and others who would love to assist there. Your results may vary when it comes to those folks, or your own folks, being able to make these statements more or less actionable. With this specific statement about the “flow” of data and not allowing “misstatement” to arise, there is general agreement that having IT staff with administrative powers that could, in theory, alter financial data is a risk that needs to have a control. And from that general agreement has risen an entire market for privileged access management products that allow you to restrict people who need administrative rights to do operational tasks in IT infrastructure from using those rights to somehow change data that would be used in any kind of financial reporting (or use that access to do any number of other things covered by other sections of SOX or other regulations like PCI, etc.).

What should be apparent is that things like RBAC, ABAC, and rules based approaches to access control are all simple and straightforward when compared to taking policy and making it actionable. Putting an RBAC system into place is taking action. But, as anyone who has been through an RBAC roll out will tell you, the hardest bit is figuring out the roles. And figuring out the roles is all about interpreting policies. So what is the answer for all those folks on these webcasts who wanted to know how to master this art? The short answer is like the old joke about how you get to Carnegie Hall: practice. The medium length answer is to find a consultancy and a vendor that you trust and that have had the right amount of practice and make them do it for you. The long answer is to follow the path I took above trying to explain the question. You need to analyze the requirements, break them down, and keep doing that until you start getting statements that look slightly actionable. Of course, that takes a huge amount of resources, as evidenced by all the money that’s been spent on SOX alone in the US (that same wikipedia article quotes one study that says the cost may have been 1.7 trillion USD). And the final trick is to take your actions and breakdowns back to the top, your auditor or CISO or whomever started the chain, and validate them. That’s a step that gets skipped all too often. And then you see million dollar projects fail with one stroke of an auditor’s pen.

ghosts of the interscaler directory at #cat10; let’s do it!

There were a lot of points at Catalyst 2010 where Kim Cameron’s Interscaler, Federated Directory and Identity Schema came up in my mind, though went unmentioned by the speakers. I know I wasn’t alone, either. It was there like a ghost in every discussion. When Anil John spoke about Background Attribute Exchange (BAE), one of the first questions was about how to ensure schemas would be in sync. When Nishant Kaushik spoke about federated provisioning, again questions had everyone talking about how directories would be able to rely on attributes being “exchangeable” across domains. And when the folks from GM gave their talk the second or third question was about how they decided what attributes would be included in their avatar identities and which would not.

How does this move forward? I get dizzy when I look at all the standards bodies around identity. I’ve got a lot of energy to offer around this and don’t know where to push it. It’s not about a product or a vendor. I’d like to see this be an industry thing that everyone can benefit from.

#eic10 part 2: lacking policy, lagging XACML, authZ not so externalized

I’m not sure why, but the theme for me at EIC10 was policy. It wasn’t that the sessions or discussions were intent on going there. If anything, it was quite the opposite. I sat in on one of the “pre-conference” sessions that was titled “Moving beyond the Perimeter: Identity & Access Management for a Networked World“. That was what set the tone. I went in expecting a lot of discussion about how organization could, should and have been able to overcome the tricky policy barriers to open themselves up and manage access. The reality was that we spent a lot of the time discussing how to get over the challenges of making IAM work inside the perimeter so they can start thinking about the outside. For those that had some established outside presence for identities accessing other resources or accessing their own (and it was only a few), they were set back on their heels by my questions about policy and challenges to explain the legal implications of those access points. Later on, in a session titled “It has been Quiet around Federation. Is this a good Sign or a bad one?“, asked what challenges were faced by your organization when trying to federate, I answered that we (Quest) had faced numerous legal challenges to getting federation done. Each time has been a meeting with lawyers and lawyers meeting with lawyers and so on. The shocked looks from the general audience didn’t quite drown out the few nodding heads that clearly knew exactly what I meant. It shouldn’t surprise me that technology outstrips policy and that technologists don’t see the policy lagging behind until it’s too late, but somehow it always does.

Of course, technology is still my preoccupation so I was equally into the technology of policy that seemed to pervade EIC10. XACML was everywhere. Or maybe it only seemed that way because I attended so many of Felix Gaehtgens‘s sessions. However, there were a few stark contrasts that struck me. First, there were no fewer than 5 vendors on the floor offering XACML based or compliant solutions for externalized authorization. Despite that, I didn’t see one keynote mention it, nor customer story talk about having that be built into their architecture. Even the big vendors, when directly questioned about it, immediately submersed it into an acronym soup of SAML, claims, and other federated related stuff. It seems like many are now using “federated” interchangeably with “externalized”, which is sensible on some level but seems to lose some of the important distinctions between the two (e.g. trust is explicit with federation and implicit with externalization). By far my favorite externalized authorization moment was in a panel titled “How to make your Software Security Architecture Future-Proof” when Felix asked Kim Cameron, who had just made his interstellar announcement, the following: “if the application has to have internal logic to handle claims, then the authorization has not been externalized, right?” Kim made no real answer. But I think Felix said what a lot of people were thinking. Claims are the bees knees, but WIF still embeds all the authorization logic right in the application itself.

This will be the last on the conference. It was a real blast and I got to meet some of the folks who have haunted my mind via twitter for a long time in person. Good stuff.

#TEC2010 thoughts

Last week was #TEC2010. It was my second year at the event, and I was again stunned by the unique vibe it has. Since TEC is focused on education for the folks in the trenches of managing directories, the crowd is markedly different from many other events I attend. There were some senior management types around, mostly owing to the Microsoft centered nature of the event and their shops being very heavily Microsoft focused. The vast majority were people who architect, deploy and maintain directories, though. And it was far from just Microsoft directories. I heard every type of directory mentioned by the folks in the crowds, from RACF to Novell.

One of the main highlights for me was Conrad Bayer‘s keynote about Active Directory and the future of identity services at Microsoft. It was very refreshing to hear someone from the top of the technology food chain at Microsoft saying a lot of things that have been true for a while. Conrad directly acknowledged the breakdown in the concept of using structured hierarchy to represent the relationships between identities and organizations in today’s world. He also gave a nod to the difficulties there are with peer-to-peer federation approaches, though he said ease of use should mitigate that, which I do not agree with. He also pointed out the competitive advantage Microsoft sees in RMS when compared to other identity vendors. I found that odd, but very interesting. Lastly he called out that most clients he speaks with thinks that identity is one of the last things they would move to the cloud, which is something I hear a lot as well.

The other session I enjoyed very much was Brian Puhl‘s. Brian is from Microsoft’s own MSIT division and is in charge of identity services. As he put it, his job is “dog fooding” – using what Microsoft makes for Microsoft’s benefit. Likely the most notable thing about the entire presentation and discussion that followed to me was that the word authorization was in the title and never once did the term XACML make its way into the chatter. At points I got the feeling there was some very complicated mental gymnastics going on to avoid the idea that policy expression needs a platform and protocol. At one point Brian said point-blank “my hosting provider needs to give me a mechanism to express the complexity and facets of my required policies”. I almost coughed out “XACML”, but held it back. Two observation Brian made that struck me as totally true were that trust (and policy) often boils down to contracts and that key management is every bit as important and encryption itself. These are two lessons that only someone who has had to wrestle with lawyers or exotic devices’ key renewal protocols would be able to offer.

By far, the best part of the conference was speaking to the hundreds of fellow attendees – and this year I was thankfully just an attendee so I had no booth duty to distract from the fun. I had conversations with the world’s largest banks, small law firms, government affiliated agencies who remained nameless and everything in between. Every one of them had backlogs of issues they were looking to get ideas on, and the peer level advice flying around was worth it’s weight in platinum. If only there was a good way to bottle that – that would be something we could all use.

SAML vs XACML for ABAC & AuthZ

My esteemed fellow Quester Jackson Shaw just blogged about SAML being used for ABAC. I also heard a lot of talk about this at RSA last week in side conversations. I thought I may talk about it a bit; now Jackson’s given me the opportunity. It seems that using SAML to cure the ails of other less mature MLs is all the rage. I’ve also been watching Jeff Bohren‘s posts about SPML and SAML. In that case SPML is set against SAML + LDAP. I think it’s all related.

SAML is taking off. There are a lot of platforms and vendors supporting it, architects and developers are adopting it and it seems to have a mature set of features that are making all of them happy. But then you look to the next set of issues, provisioning (specifically just in time provisioning) and authorization, and you find much less satisfying results. So people have the old “if you have a hammer everything looks like a nail” short circuit and start asking why not use the thing everyone likes, SAML, for those problems, too? The saml.xml.org site gives a clear explanation of how SAML can be applied to ABAC:

SAML is being applied in a number of different ways, one of which is Attribute-based authorization. The attribute-based authorization model has one web site communicating identity information about a subject to another web site in support of some transaction. However, the identity information may be some characteristic of the subject (such as a person’s role in a B2B scenario) rather than, or in addition to, information about when and how the person was authenticated.

Like every hammer brought to bear on a screw, it falls short a bit. If all you need to do is pass attributes into the application, then SAML will help for sure. But if you’re looking for a way express and store policy about the content of those attributes and what the resultant set of decisions should be based on the expression of those policies, then you’re out of luck. That, and more, is precisely what XACML is; as wikipedia nicely states: “XACML … is a declarative access control policy language implemented in XML and a processing model, describing how to interpret the policies.” To really solve the authorization problem, that’s what you need. And you especially need it if you want to solve the even larger issues around having common policy applied across many applications all sharing a common policy set, policy storage and management and policy delivery.

Of course, much of this may be semantics around the idea of ABAC. Ant Allen in his report “Adaptive Access Control Emerges” defines access control this way:

Access control traditionally combines two related, but distinct, functions:

• Authentication – The real-time process of confirming a user’s claimed identity with a specified, or understood, level of confidence.
• Authorization – The real-time process of deciding whether a user can interact with a particular resource in a particular way and enforcing that decision

Though I typically hear people discuss this as if authentication was one thing and access control is used as a synonym for authorization. If people use Ant’s definition, then SAML already handles all of the authentication part and can play in the authorization part as well by supplying attributes. But if access control is being used as a synonym for authorization, then SAML has less to offer since it only supplies the attributes and leaves the application to do the heavy lifting.

Under any definition of authorization, I think it’s safe to say that SAML will only be able to make a significant contribution after some heavy modification to include a lot of the XACML elements or through the emergence of some other cooperative standard that laps XACML and is very “SAML friendly”. Neither one of those is on any horizon I see. And any extension of SAML to be more XACMLish will only bring all the practical challenges that XACML adoption faces (application refactoring, policy definition, inter-application cooperation, etc.). And wouldn’t it defeat the purpose of using your nice hammer to make the handle 20 feet long and the head 50 pounds heavier?

RBAC and ABAC and Roles, oh my.

So I missed the Kuppinger Cole webinar with Felix Gaehtgens on ABAC, but I read the materials and the Q&A was really good. What it got me thinking was that there may not be enough good stuff in the world explaining the basic differences between RBAC and ABAC and why one may be better than the other. So here’s my take on it.

First, let’s set up what RBAC is. RBAC stands for Role Based Access Control. The idea is that instead of granting individuals access to assets the access is granted to a role. Individuals are then associated with the role and thereby gain access to the assets. Like with so many things, there is a decent wikipedia article on RBAC, but it fails to capture some of the basic flaws I see. If you were to draw a picture of RBAC, it may look like this:

From left to right in the above diagram, you have the asset to which access is being granted. Then there is some form of a rule which is controlling access to that asset. If the asset were a file, then the permissions in the filesystem for that file would be the rule. Then you have the roles. The roles can have users associated in a number of ways. Attributes can determine the user being associated. Rules can also be used to determine role association. And a user can also simply be declared to have a role explicitly. Last you have the users and all their attributes. If the users were in AD, then the attributes would be all the attributes of the user object. In this RBAC model, the assumption is that controlling and maintaining access is easier since there doesn’t have to be a direct relationship maintained for every user. The roles act as an abstraction layer. When assets were all files and the rules that governed access to them were very simple, that made sense. Now assets are much more than files on disk, there is almost always a middle application tier involved, and the rules are very robust.

In this newer, application ruled world, there are many issues with RBAC. First, asset owners must be aware of role details in order to make their choices about what roles get access. To grant access to the wrong roles means granting access to the wrong user. So all the logic for the granting of the role must be understood by the asset owner and that means almost no advantage in terms of spreading out load for maintenance – everybody must understand everything. Second, there are now two layers of abstraction, rules and roles. This results in some very complex interactions which make it hard to get a grasp of just how access is being granted, and that is very bad come audit time. Third, access is now dependent on role maintenance. If there is a group maintaining the roles with a complex and locked down change control procedure and a nimble application group which needs a lot of changes, you end up with process timing mismatches that can cost real money. And last but far from least, new use cases for assets means new roles. Because the rules can only result in a pass or fail for roles, if there is a need to have a different access scenario there will be a need for a new role to match it. And that means role proliferation and more maintenance.

For those reasons and more, I believe ABAC is becoming more popular. ABAC is Attribute Based Access Control. It’s picture is much more simple:

Right away, it’s clear ABAC is cleaner. It eliminates the man in the middle and puts the users right in touch with the assets. The abstraction layer RBAC provides has become overhead in the face of the new ways the assets can govern themselves. The rules assets can use via their applications are more than enough to give flexibility to the asset owners. And since the users are likely to have a good set of attributes to draw on for evaluating their claim to access, there is no reason to add the other layer of roles to mitigate. The rules can simply evaluate attributes and be quite abstracted from the actual users. And since it’s much more likely that attribute stores are well maintained since they are linked to HR and other time and legally sensitive business drivers, there is much less likely to be issues with asset owners outpacing the maintenance of their source of access control information.

Of course, roles are not simply going away. The role of roles is changing. The new picture is really more like this:

The roles are not directly involved with access control rules – except perhaps that they may show up as an attribute of the user and be used in the rules evaluations. But the roles are very useful in the administration of massive sets of users. They are also very useful in the attestation, auditing and other security and identity processes around entitlement management. Maybe it’s time to think of RBEC, Role Based Entitlement Control. The idea being that entitlements, the security view of business rules for access, are governed and audited via roles. But we can keep the OLTP side of access control, the effective controls, in an ABAC form.

That’s a lot of typing. Hope someone finds it useful…

entitlements and access – separate but equal?

So I’ve finally had the time to digest a lot of the materials and notes I collected at catalyst 2009. Though the identity track had a lot of content around many topics, there was one theme I kept hearing again and again. Access control is king. That’s not news, but it seems like everyone is just coming back from role management, provisioning and other IAM projects to find that the core issue is still waiting to be solved.

The other thing that seemed to emerge, at least to me, was a distinction between the definition of entitlement management and access management. Entitlement management is the practice of deciding what business functions a person should have access to. So a statement about entitlements would be: “Sally Brown the Accounting Director may sign off to close the books at the end of a quarter”. That may be recorded in a system. And I think that is the ultimate goal of systems like Aveksa, Sailpoint and CA/Eurekify. But what seems to happen in those systems in a practical sense is that people record things at a technical level. So they end up with statements like: “people belonging to a group with an ID of 3345 may execute the sys_plx_camp_fog procedure in the PROD system”. Of course, that is useful to know. But it is still something that needs to be decoded. To their credit, all the systems let you put friendly names around these things, but that doesn’t address the core issue. The core issue is that people are using an entitlements tool to solve access issues. It is a process issue.

Access management is the practice of encoding and enforcing entitlements in the IT infrastructure. It’s where the rubber meets the road. So things in your access management solution should actually be able to touch your infrastructure and make it listen to policy. This type of tool has been around forever. Quest’s own ActiveRoles Server, Privilege Manager for Unix and others perform this role in various types of infrastructure. Another prime example is Keystone from BiTKOO, which does this using all the new OASIS pizzazz of XACML, PDPs, PEPs and such. And just like the entitlements tools get abused by the IT staff to do technical duties, you also see these tools getting pulled by the business to try and to entitlements work.

Of course, all of this goes back to that ever present prime mover in identity – compliance. Not the only reason people do IAM work, but one of the major drivers to be sure. And so the use of one product to do entitlements and access work is natural because people are trying to get things done under time constraints to avoid failures in the next audit and also under budget constraint since they (IT) are spending someone else’s money to do it.

what’s on the mind of people seeking IAM solutions

Mark Diodati from Burton Group put together an article about what he sees his clients asking about. what surprised me were some of the categories he used. something like “Access Management” is so broad that it acts as a catch all. not surprisingly it gets second place after “Authentication” with 14.4% to authN’s 22.5%. Of course, authN is also pretty broad, but “Access Management” can cover just about every topic relevant to IAM given the chance. to be fair, i’m not sure what you can do about an issue like this. when you’re asking people to classify their comments, there’s only so specific you can get before you confuse or bore.

complaints about methodology aside, there was not much that’s surprising here. a lot of it mirrors our own 7 projects, those tactical goals that are the eggs and juice of the IAM healthy breakfast. If there was any surprise, it was “Federation” at 5.4% and “Authorization and Entitlement Management” at 4.4%. It seems like that’s all IAM folks and many clients want to talk about. But maybe a lot of that buzz got sucked into “Access Management” where it could rightfully belong.