Yesterday CA announced its acquisition of IDFocus, a small Israeli company. Among other abilities, IDFocus provides a finer-grained segregation of duty (SoD) analysis engine. CA has previously integrated this engine into Identity Manager, their user provisioning tool. This is an interesting wrinkle in an ever-changing market. CA now possesses a preventive-controls engine with the ability to look further into the security stack of an application. This engine allows customers to make SoD decisions below the role or group level, at the lower ACL/security object levels. Provisioning vendors have until now done this by calling external services provided by Enterprise Application Controls Management (EACM) vendors. On one hand, CA has partially obviated the need to integrate with an SAP, Oracle, or Approva by integrating the IDFocus capabilities into CA Identity Manager. On the other hand, CA’s move may have made things more confusing for customers. By increasing the number of controls repositories that a customer has to maintain, integration of IDFocus makes compliant provisioning deployments more challenging. What would be really slick is if CA could find a way to work with the EACM vendors to synchronize SOD tests so that a customer could use the same test for both detective and preventive applications. I was speaking on this very topic in Europe last week. I commented on the various architectures for integrating EACM into user provisioning to provide compliant provisioning services. (For more on this subject, check out Lori’s report on the matter.) CA has now introduced a fourth deployment model in which the provisioning engine owns the entire compliant provisioning event from the request through the SoD test to the provisioning event itself. An interesting alternative. I’ll be curious to see where CA takes this. (Originally post on Burton Groups’ IdPS blog.)

Matt Hamlin, over at Sun, mentioned a conversation we had last week about a topic in identity management which doesn’t usually get a lot of airtime: the correlation of accounts to people. The exercise is the first step in answering Matt’s simple question of “Who has access to what?” Matt writes:

This step is the foundation for Access Certification, Role Mining, Entitlements Management, Policy Evaluation, Identity Auditing, and numerous other custom services developed by our customers.

Kevin Kampman has added his opinion to latest RBAC thread. Kevin makes an interesting point:

Another challenge is to clarify what a role represents. A business role is an articulation of a business relationship or responsibility. A technical or IT role is a set of privileges or tools that are used to accomplish the business role. Business roles map to IT roles. If you try and merge the two into one, you come up with an IT role. It becomes difficult to ascertain what it was or is intended to accomplish, and it becomes inflexible, bound to an application.

Check out Ian Yip’s hilarious summation of the recent meta and virtual directory conversations across a bunch of blogs. Great stuff!

At the end of Tim Weil’s presentation on RBAC at Catalyst last month, Nishant asked a basic question: is the NSIT RBAC model sufficient and complete? Not receiving a satisfactory answer, he has taken his question to the blogosphere. Nishant’s question touches upon two of the hobgoblins of identity: context and intention. I talked about issues of context years ago in an unrefined form. This week I have been out here in Utah working at Burton Group’s headquarters trying to figure out what I will be researching in the coming quarters. I have not found my research topics yet, but in conversations with the team it is becoming clear to me that lurking behind a lot of the topics we’d like to dig into are the problems of describing context and recognizing intentionality. We’ll see what the coming months of research uncover.

My first post as a Burton Group analyst is now up over at the Identity and Privacy Strategies blog. (Helps if I actually link correctly… doh!)

I have interacted, both socially and professionally, with Burton Group in a variety of ways over many years. The quality of people, their integrity, and the quality of their work have always impressed me. In short, Burton Group is the kind of place I want to work for and the people are the kind of eccentric, entertaining people that I love being around. After a few years in the making, I have joined Burton Group as a senior analyst on the Identity and Privacy Strategies team. The first day at a new job is always a little gut churning. When that first day is the first day of the Catalyst conference it gets even more interesting. Today I found myself on stage with the rest of the team during the Identity Management market overview presentation. Stoically silent, I scanned the room for friends in the industry. Needless to say there were more than a few very surprised people. As my first real act as an analyst I recorded an introductory podcast - Not bad as an intro. Obviously, there will be more to come as I take on my research projects. Stay tuned!

It is that time of year again: Catalyst. I know that Nishant and two Marks (Dixon and MacAuley) are headed to San Diego. Who else is going?

This is my fifth or sixth Catalyst conference and will be a bit different for me. I’ll explain more next week.

See you there.

Between her open letter to application vendors and roles versus rules, Pamela Dingle is kicking up a lot of dirt. I tend to agree with most of her points as I have written about here. However her following point bothers me; I’m not saying I disagree with it completely but it sits oddly with me:

In the case where two roles are assigned to the same person, but should never be simultaneously applicable, Enterprises have limited choices. If, however, there is a layer in between the consumer and the provider that lets you mask roles based on user-chosen context, in my mind this problem goes away. I don’t see how you can do it without the user part — but perhaps I’m just not thinking hard enough

James has provided me more to work with…

Identity consolidation says that I figure out how to get user stores out of my enterprise application and instead get these applications to bind at runtime to a directory service such as Active Directory.

Ah, so identity consolidation is centralized authorization. Got it.

I am making the assumption here that when James says user store he means authorization store. (Applications in this model still need some modicum of a user store if nothing else for auditing purposes.) I am assuming the implication here is that after authentication comes a round of authorization that the directory service provides. The application would consume this authorization data, at runtime, and act accordingly. Theoretically, an enterprise policy (XACML) store could theoretically reproduce the authorization models of every application in the enterprise today and that policy tools would interact with this store. Though I think this is a very viable model for customer applications (especially J2EE and .NET), I do not see it as an enterprise approach where complex applications like mainframe security and ERP roam free.