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.

AD Bridging gets respect at Burton’s Catalyst09

day two at catalyst09 was very on target for me. the identity track was all about leveraging existing resources for bigger ROI and that’s all we ever talk about in PM meetings around here. Burton’s Mark Diodati presented about the AD Bridge space, a name he may have invented, and then there was also a customer case about the practice of doing AD Bridging for Unix, Mac and Linux systems. the best part was when a person in the audience took the mic during Q&A and thanked Mark and Burton for taking the AD Bridge products seriously and the whole audience erupted in applause.

i’ve got lots of notes and thoughts about everything that went on. i’ll likely be posting reactions to catalyst09 over the next week.