At any rate, we are 7 days away from Burton Group Catalyst EU! In the 7+ years that I’ve been involved in one way shape or form with Burton Group, I’ve never been to a Catalyst [...]]]> I’ve been a bit quiet on Tuesdaynight lately… sorry – it has been a bit crazy around here lately.

At any rate, we are 7 days away from Burton Group Catalyst EU! In the 7+ years that I’ve been involved in one way shape or form with Burton Group, I’ve never been to a Catalyst EU – so I am very excited. For those of you joining us, you are in for a treat – John Seely Brown will delivering the keynote for us. Besides Mr. Brown, the IdPS team has got some great content waiting for you:

• Bob will kick things off with a look to the future identity architecture
• I’ll be talking about the IdM market as a whole
• Lori and I will have a serious conversation with our dear friend – provisioning

Fun for the whole family…

For those of you not heading to Prague, follow the conversation on Twitter. We’ll be using the #cat10 for the conference and the identity conversation will be on #idps.

See you there either in person or virtually…

This does bring the number of analyst firms focused on identity, privacy, and relationships down to a very [...]]]> So you’ve probably seen the news – Gartner is acquiring Burton Group. Looks like we’ll be kept whole in a variety of ways; see this note from Gene Hall. I’ll let you know more as I know.

This does bring the number of analyst firms focused on identity, privacy, and relationships down to a very small number. It will be interesting to watch how the market responds.

What is with Tuesdays in my life? 9/11 – a Tuesday. IBM buys Access360 on a Tuesday. Gartner buys Burton Group on a Tuesday. In keeping with this odd streak of Tuesdays, I think I’ll be at Toledo Lounge tonight – see you there?

My hope is that the overall ICAM initiative is successful—not because I have [...]]]> A friend in the industry recently asked me for my thoughts on OpenID, InfoCards, and the US federal government’s work to consume non-government issued credentials. Letting the question rattle around in my head for a while, here’s what I’ve got so far.

My hope is that the overall ICAM initiative is successful—not because I have been eagerly waiting to interact with the federal government using some form of authenticated credential—but because we (citizens, enterprises and government) are at a pivotal moment in the history of the web. With the US government working with both the OpenID and InfoCard Foundations, there exists an opportunity to change how individuals interact with large organizations, both public and private. For the first time, individuals would be able to (even encouraged to) interact with a large organization (such as the US federal government) using an identity asserted, not by the large organization, but by the individual. In this case, the State is no longer the sole provider of identity. This breaks the monopoly that the State has had on credentials and is indicative of the future to come.

But there is a long road to walk before getting there. There are numerous concerns with these plans. Among these are notable security concerns, especially with OpenID, that the identity community is not blind to. These are not my primary concerns.

My primary concern is with the establishment of standard user behavior that could prolong existing problems. Today, after decades of enterprise training and a decade of consumer training, people naturally expect to see two text boxes on web sites. One is for their username and the one with the little stars is for their password. This behavior is ingrained. Changing this behavior is no small feat – just ask the OpenID and InfoCard groups. But it is a change that must occur to normalize people using something stronger than username and passwords to authenticate themselves.

My concern is that the behavior that is being established as a norm – the use of either an identity selector or some other user interface means – will become the username/password for the next generation. This isn’t a hypothetical problem; the writing is already on the wall. Currently, OpenID will only be accepted for low-value transactions with the government known as Level of Assurance 1 (LOA1). Activities like filing tax returns requires a far greater assurance that the person is who they claim to be and thus require a Level of Assurance 3 identifier. And there is problem. The way people use an LOA3 credential may be very different than how they do so with an LOA1 credential.

If we, as an industry, normalize user behavior that meets LOA1 needs but not LOA3, we are training in behavior that has to get untrained in a near future. What the government and its partners are on the path to doing is effecting real cultural change. This kind of change doesn’t happen often and is hard to do, and especially hard to undo.

I definitely want a future in which I can assert my own identity without validation from the State, but I am very willing to wait for that future to assure that the behavior the industry normalizes is one that will work for generations to come.

(Cross-posted from Burton Group’s Identity blog.)

But, to me, there was something missing from the [...]]]> Among the sessions in this year’s Computers Freedom and Privacy conference was a panel on the recently released National review of cyber-security. Ed Felten presented three related areas that he believes have to be improved in equal measure to improve overall cyber-security:

1. Product development
2. System administration
3. User behavior

But, to me, there was something missing from the list – product design.

Too often I have seen products whose user interface, in fact its entire user experience, was constructed after the fact.   First the special sauce gets codified, then the chrome is put on and product gets a face.  It is easy to recognize products that have been built in this way as they tend to expose their internal data models to users, forcing users to adopt the metaphors of the engineers that built the product in the first place.  These types of products make problems internal to the product problems for the end-user and this can lead to very bad things.  See Three Mile Island as an example.  Poor user experience design leads to so-called “user error,” but is it really user error if the end-user is confronted with meaningless alarms, confusing error messages, and misleading feedback?

At CFP, I talked to Bruce Schneier his research that went into Beyond Fear to get a better understanding of the psychology of fear and its relation to security.  As you probably know, humans (and other animals too) are fantastically bad about evaluating risk. Optimism bias and other factors cause us to either over or under-estimate risks. Combine this with the fact that how choices are presented directly influences how choices are made and you realize the crucial need to build better user experiences for security (frankly, all) products.

“Is everything okay with the mother ship and should we blow up Russia?” This is the question presented Buckaroo Bonzai and I think I’ve seen a form of it as a dialogue box in Windows.  Would it be considered user error if an end-user pressed the “Yes” button and nuked Moscow? Bad design is at the least confusing and at the worst dangerous.

I did talk to Ed afterwards and he acknowledged the role of design in product development. As he said, if we only attempt to improve one of the three areas product devolvement or system administration or user behavior we won’t improve cyber-security; we have to improve all three.  User experience design as a part of an improved product development processes can directly lead to better more informed user behavior. Okay you product managers and designers make your voices heard – better safer products through better design!

(Cross-posted from Burton Group’s Identity Blog.)

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 [...]]]> 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.

Finally, I have a problem with the phrase “entitlement management” (just ask my co-workers). As I have blogged about before, Kevin and I have been in the midst of a large research project focusing on role management. One of the things we have learned from this project is that enterprises do not use the phrase “entitlement management” the same way we do.

A bit of history – three or so years ago Burton Group, at a Catalyst, introduced the phrase “entitlement management” to include the run-time authorization decision process that most of the industry referred to as “fine-grained authorization.” At the time, this seemed about right. Flash forward to this year and our latest research and we have learned that our definition was too narrow.

The enterprises that we talked to use “entitlement management” to mean:
·      The gathering of entitlements from target systems (for example, collecting all the AD groups or TopSecret resource codes)
·      Reviewing these entitlements to see if they are still valid
·      Reviewing the assignment of these entitlements to individuals to see if the assignments are appropriate
·      Removing and cleaning up excessive or outdated entitlements
More often than not, we found that our customers used “entitlement management” as a precursor to access certification processes.

Using a single term (“entitlement management”) to span both the run-time authorization decisions as well as the necessary legwork of gathering, interpreting, and cleansing entitlements can lead to confusion. The way enterprise customers currently use “entitlement management” works well to describe how legwork is vital to the success of other identity projects.  (I’ll be working on a report this quarter that delves deeper into this.)

I am all for a broader conversation on fine-grained authZ versus entitlement management. And as Ian Yip has pointed out on twitter, identity blog conversations have dropped off a bit and I’d love to stoke the fire a bit.  But we can’t have meaningful conversations without shared definitions. So what’s your take? What do you mean when you say “fine-grained authorization” and “entitlement management?”

(Cross-posted from Burton Group’s Identity blog.)