Day 1: A focus on IdM evolution

I don’t know if this was par for the whole conference, but at least in the IdPS track, each half day was devoted to a particular theme. The first half of day 1 was a landscape update as usual, and focused on some of the interesting developments in the space, like Oracle’s pending acquisition of Sun (that’s all I’m going to say on that topic), the integration of DLP (data leakage prevention) with IdM programs, and the emergence of some commercial Identity Oracles.

I especially liked Bob Blakley’s discussion on Identity Services, since it resonated with a lot of what I have been talking about on this blog and the work I have been doing at Oracle. In his talk on the subject, Bob pointed out that cloud-based identity services will challenge the fundamental architectural notions of IdM infrastructure. The large blocks of IdM functionality that we are used to – access management, provisioning etc – will get broken down into smaller, modular pieces – like identity proofing, enrollment, identity risk assessment, breach remediation – that can interplay within enterprise environments as required. This is pushing the market towards smaller, specialist vendors that handle specific services rather than the large IdP that is a one stop shop for all identity needs. And these services have to work in concert with each other to provide the enterprise the value they are looking for. The vendors that have emerged in this space are delivering their services via various deployment models – ranging from on-premise SaaS to cloud-based services – but mostly stick with the per-user/per-transaction billing model. And all of them are going to get a big push when some of the cloud security issues currently holding enterprises back get resolved.

The second half of the day focused on a big part of IdM’s evolution – the mainstreaming of role management and the ascending discussion on the nature of Entitlement Management. Role Management is now widely accepted as an important part of any comprehensive identity management practice, and Kevin Kampman’s talk on the subject highlighted the importance of positioning it as a business problem instead of a technical problem. In discussing the results of a survey Burton conducted with customers that did role management projects, Kevin laid out the premise that the tools are actually secondary when it comes to implementing role management. First and foremost is the need for customers to understand the business processes that impact the design and use of roles, and document the same so that a practice could be built around them.

And as role management has taken hold in the conscious of IdM practitioners everywhere, entitlement management is rearing its head as a disruptive topic. In what was a theme for the conference, Burton laid out a terminology issue that exists around the term “entitlement management”, which is often used to describe tools that deal with runtime evaluation of fine-grained authorization decisions (like what Oracle Entitlement Server does), and neglects the lifecycle management practice around entitlements and their assignments. As customers dig deeper into their role management projects, they are finding that what they really want to do is entitlement management. And the tools to help with the lifecycle side of this equation are just not there.

The day finished at the hospitality suites, where a lot of the evolution being discussed here was on display. There was also a very successful interoperability event demonstrating SSO for cloud-based applications, a first step towards management of the extended cloud-based enterprise by enterprise IdM deployments. All in all, day 1 was quite satisfying. But the best was yet to come.

Tags: Burton Catalyst Conference, Catalyst09, Entitlement Management, Identity Services, Role Management

Tags: NIST, RBAC, Role Management

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.

Tags: RBAC, Relationship Management, Relationship-Based RBAC, Role Management

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.

Tags: Burton Catalyst Conference, BurtonGroupCatalyst08, NIST RBAC, RBAC, Relationship-Based RBAC, Role Management

Predictions are risky business, especially in the slightly schizophrenic world of IdM. On the one hand, things tend to move way too slowly; on the other hand, things emerge out of nowhere to take center stage. So I tend to shy away from making predictions. But I will talk about what I hope to see happen in the coming year. These are not impractical, fantasy wishes that will require me to find a magic lamp buried in the sand. These are things that have a good chance of happening if we as an industry stay focused.

Integrating Risk Management with Identity Management
Recent events have brought to light the need to build comprehensive integration between risk management and identity management software. Oracle’s acquisition of Bharosa last year was a response to marketplace demand to bring more context into the identity management process. There is a better understanding of the complex heuristics that need to become part of identity management decisions, and how to encapsulate them as workflow and rules. The coming year should bring more tools and more capabilities in these areas.

For the longest time, people would talk about integration in the context of product suites. The focus will now shift to integration in the context of pre-canned and pre-defined solutions and workflows.

Role Management Comes Into Its Own
Over the last couple of years, we have seen Role Management become an established part of identity management. But its real value will be realized when it stops being an explicitly deployed and managed part of IdM (a la access management) looking for consumers, and evolves into a business tool that is deployed within the enterprise context of provisioning, entitlement management and ERP. A number of other folks have already challenged vendors to do this, and hopefully a lot of work going on in this area will come to fruition.

The Evolving Identity Framework
There are a couple of things I hope to see happen this year that will help us move towards our ultimate vision of how identity is used.

• The Identity Services message has been very well received every time I have presented it. In the last year I met a number of individuals, like the folks from the Jericho Forum, the Concordia project, and a number of people at various conferences, who are really committed to changing how Identity becomes part of application development and deployment frameworks. Hopefully the coming year will see some concrete progress made in defining the necessary framework architecture that will enable the externalization of identity from applications
• We have seen everybody and their mother make moves to become OpenID Service Providers, especially the big identity silos. Hopefully this year will see an explosion of services that are OpenID Relying Parties, including some of those same big players. The real adoption of OpenID will come not from the glut of OpenID SP’s, but from the widespread availability of services that accept OpenIDs and do not require registration and username/passwords.
• I also hope to see someone take the Identity Oracle concept and create a viable business out of it. It may not explode right away, but it will start to emerge. It seems obvious that the easiest place for this to happen is in social networking applications like Facebook. They already hold a lot of identity information that they then serve to other applications (those annoying, currently non-critical Facebook apps that clutter everyone’s profile). Putting in place more controls on how my information is shared and with which apps, and then opening the walls to outside applications would be a logical progression in the evolution of identity providers for internet applications. I also hope to see the Identity Governance Framework become part of such a control framework in any Identity Oracle.
  And then hopefully at the start of 2009 I will be commenting on my hopes for the acceptance of internet identity framework tools within the enterprise.

Your Hopes
What are your hopes for the coming year? Leave a comment, or email them to me, so that we can add them to this list. and hopefully take notice.

Tags: Entitlement Management, Facebook, Identity Governance Framework, Identity in Social Networking, Identity Services, IGF, OpenID, Personal Identity Management, Role Management

To many, an acquisition in the ERM (Enterprise Role Management) space was inevitable. ERM has gone from cutting-edge darling of the analyst crowd to a must-have IAM solution fairly rapidly. I have myself blogged about the importance of roles in any IAM architecture a number of times. By acquiring Bridgestream, Oracle is adding their SmartRoles and SmartRoles Discoverer products to our industry-leading IdM portfolio.

Relationship-based (aka Contextual) Roles
When it first came out, Bridgestream SmartRoles introduced the interesting notion of relationship-based roles to the market. Providing a solution for the top-down approach to role engineering, the product allows customers to model a myriad of entity relationships (between such diverse entities as people, organizations, processes, projects and business resources) in it, and then express roles as a traversal of the generated relationship graph. Of course, this is not to imply that it doesn’t handle the more mundane roles we are all accustomed to, which are simply containers of people and privileges. But their ability to model roles on real-world relationships that help solve real world use cases is really what sets them apart from the field. SmartRoles also supports a number of other interesting features, including temporal views of the relationship graph that provides a time sensitive answer to the role membership question.

SmartRoles

SmartRoles also supports the much needed separation between Enterprise Roles and Local Roles (or Business Roles and IT Roles, as Bridgestream calls it). This provides a necessary abstraction between the business side of the enterprise and the security focused application side of the enterprise.

These features allow them to support some really interesting RBAC scenarios that relied on complex cross functional project relationships, as well as role-based provisioning that took the location of both people and resources into account and complex approval scenarios. The BSI relationship with Oracle started with the relationship that was initially established between Thor’s Identity Manager product and SmartRoles, providing a powerful role-based provisioning solution to customers.

Role Discovery
Bridgestream has also made a move into the role mining area with the introduction of its SmartRoles Discoverer product. SmartRoles Discoverer
complements SmartRoles top-down approach by offering companies a bottom-up methodology to kick-start their role management implementation. It provides capabilities to mine data sets from diverse sources and discover useful and meaningful roles. But role mining and verification aren’t enough, so SmartRoles Discoverer also uncovers rules and policies to govern these roles. These candidate roles, along with the discovered rules and policies to govern them, can then be exported into SmartRoles for deployment.

SmartRoles Discoverer

Adding this capability to its suite allows Bridgestream to provide a complete end-to-end process-based solution for role lifecycle management to the market.

The Future
Over time, the capabilities of Bridgestream’s advanced role discovery and modeling capabilities will be combined with Oracle Identity Management’s access provisioning and enforcement tools. So while it will still be possible to buy a pure role management product, the real value will come from the SmartRoles product (which will no doubt be renamed following the standard Oracle formula at some point) providing a richer role environment for the OIM and OAM product lines to base their capabilities on, providing customers a comprehensive solution that covers all the bases.

You can get a lot of information about the acquisition and its value (including FAQs and white papers here).

Tags: Oracle Identity Management, Role Management

What caught my eye was this post a while back by Securent CEO Rajiv Gupta, that touches on the type of debate one often sees at the inception of rival approaches to a problem. While the RBAC vs. EM debate does not compare to the aggravating Blu-Ray vs. HD-DVD format war, there are similarities in that both are forcing some consumers into a “wait and see” attitude, and emotions fly high whenever this topic is brought up.

Despite repeated requests in the blogosphere I have resisted the urge to discuss EM’s place in IAM, primarily because I did not feel knowledgeable enough about the space to comment on it (people who know me know that I am cautious to jump into any debate, but once I have an opinion I am in it as much as possible). One gating factor in my involvement and a possible factor in the ongoing debate – the lack of industry agreement on what exactly we mean by the term “Entitlement“.

Vagueness in the definition of a term can be to the advantage of the players in the associated space, as it gives them flexibility to sell into more customer scenarios (something we at Thor saw happening plenty in the provisioning space back in the day). But it also engenders the kind of debate now raging, where there are folks who believe that RBAC and EM are rival methodologies to solving the access control problem (remember when access control simply meant SSO?).

Roles and Entitlements are both abstractions that have been created to make access rights management of identities easier. It would seem to me that the difference between the two is one of perspective. Entitlements often encapsulate into a meaningful singleton the set of privileges (usually across different tiers – UI, business logic, data layer) needed to perform a specific action. So the perspective is that of the application. Of course, that does not prevent anyone from breaking an entitlement down into more atomic pieces, or aggregating entitlements up into higher level entitlements (that may span applications). Roles start from the (very human) need to somehow put a descriptive moniker on an identity’s abilities in context (of the enterprise or the application). They therefore tend to be from the perspective of the identity, and in some sense fulfill a social imperative to quantify a person’s context.

If we buy into this argument (and I am not suggesting we do that just yet), roles and entitlements intersect in the middle. One of the problems that existed in the early days of role management (not that we are in late days right now) is the role explosion problem. This existed primarily because of two reasons – (i) the simplified definition of a role as simply another multi-valued attribute and (ii) the need to map roles to low-level privileges. That is why folks implementing roles would end up with the kind of roles Rajiv refers to in his post – “Sales Manager EMEA“, “Sales Manager Asia Pac” and “Sales Manager EMEA before 5pm“. It also was the reason why roles failed as a business description of the context of an identity, since the constituents of the role were unintelligible. As roles have gotten more sophisticated (supporting attribute-based dynamic membership, relationship-based contextual membership, even session data based membership), they have become more usable as tools in the expression of policy.

And entitlements add an extra layer of indirection, making it possible to reduce the complexity of the role definition itself, while providing manageability around the definition and control of access rights from the application developers and application owners’ perspective.

To try and conflate the two is to miss the point. True scalability in IAM is achieved only by putting a delegated model for administration in place. Roles and entitlements allow you to put the right controls into the hands of the right parties. In a simple world, application owners can define application entitlements, business owners can define roles, and governance folks can define the mapping between the two. Of course, the world is seldom simple, and the administration lines start to blur, leading to notions of application roles (the early precursor to entitlements) and enterprise entitlements. And that is where one wonders how all this comes together.

The primary reason behind the debate is encapsulated in a question asked (quite often now) by our customers and prospects – “Where is the ONE place I can go to and see my access policies from end to end?“. And therein you will find the heart of the problem. As long as there are different components in the solution, it is hard to provide a complete end-to-end view. And that is why I do not expect this debate to die down any time soon.

Of course, my views here could be completely off target. I would love to hear your thoughts on this.

Tags: Access Control Management, Entitlement Management, RBAC, Role Management

Maarten Stultjens (of Bhold company, which is a vendor of RBAC solutions) agreed with Roberta that role management systems will become the central point of compliance shortly. But he further qualified his perspective: “of course (this is) ‘only’ with regard to authorization management. The main reason for this is not so much the IT perspective Nishant is mentioning in his blog, it is the business perspective which is driving Role management systems. To find patterns and get these approved via attestation is an IT perspective towards authorization management.”

Now, one thing I take great pride in is my being able to always maintain a business perspective of the IAM problem. I have never thought of it as an IT problem (but one that requires and impacts IT infrastructure). So I promptly challenged Maarten to duel for besmirching my reputation (Just kidding).

Maarten further elaborated: “The main reason why role management systems are so important to achieve compliance with regard to authorization management is that role management systems are able to (1) store and maintain the company policies and (2) enforce these policies (through provisioning engines or manually) and (3) audit if the policies are actually implemented. Compliance is all about ‘defining a policy’, ‘enforce the policy’ and ‘proof that the policy is implemented’. There is nothing to audit when there is no clear policy. Sometimes we – IT people – overrate ourselves by talking about compliance and audit. This is the job of auditors.”

Again, I have no argument with the statement that RM systems are “important” to achieving compliance, just with the notion that they are the focus. Roles have long been viewed as the Holy Grail of IAM – true role-based identity management will solve all problems. But like the Holy Grail, it is really hard (nearly impossible) to achieve. So I tend to have approach blanket statements with some perturbation. I don’t disagree with Roberta or Maarten on how important role management is to compliance. I just want the message to be balanced, and not get exaggerated to the status of “all important”.

Looking at Maarten’s position, I agree with point (1), but disagree with (2) and (3). RM systems will not be able to do those because they present only a partial picture of the reality of a business. If I can simplify an example to make my point, it is fairly common for people to be given privileges in an ad-hoc, but entirely proper, manner. This is invariably done through a request-based, approval enforced mechanism that today is handled by provisioning systems (OIM, for instance). These privileges are therefore out of policy, yet are not exceptions. And a role management system should not have to deal with this kind of scenario (even if it could).

Yes, compliance is the job of the auditor, but an auditor is only as good as the tools they are given, which is where the various IAM solutions come in. Auditors care about the roles because knowing the roles a user has tells them about what access the user has and does not have. But they also care about the out-of-policy privilege grants, and want to know that the correct procedures for approving, tracking and attesting those privileges are being followed. They care that audit trails are being maintained, and that there are no loopholes in the business processes.

Another person sent me an email saying “Role management is vital method to achieve compliance while user provisioning is a method to deliver proper user- and permission-information to distributed environments and applications. (yes, UP also collects information from distributed sources for the centralized Role Management)”. This points out one of the main misconceptions that I have been trying hard to fight, and which is probably at the core of the misunderstanding of the space. Too often, provisioning is viewed simply as (to quote) “the bus to deliver this user-permission information, with all required attributes, to all those environments where it is needed.” This really is the IT-centric view. Provisioning systems today (OIM in particular) are actually much more of a business solution than an IT solution, providing rich policy definition and enforcement, and end-user and administrative request-based, approval driven tools for managing privileges in a fluid business environment.

To me, role management is an essential part of IAM. In fact, in today’s environment it is probably the most important part of a compliance-driven IAM solution. It should not, however, be the focus of a IAM-based compliance project. Any good IAM strategy must be a mix of role-based, rule-based and request-based management (think of the old 80-20 rule, just broken down to 50-30-20), with a good overlay of audit and compliance tools. At Oracle, we feel that Identity Administration, Provisioning and Role Management are the three pillars on which (the newly emerging) identity GRC tools are overlaid to provide the foundation of a good identity audit and compliance practice.

(Of course, knowing how IAM is constantly evolving, I am sure we will be adding more “pillars” to this diagram soon, so take this position with a pinch of salt)

This is driven by the reality of modern business – one that is fluid, ever-changing and way too complex to only codify in the structured system that role-based management represents. Over the last few years, I have dealt with a number of customers that have made the effort to incorporate role management into their IAM projects. Invariably I encountered the following:

• No one agrees on the definition of a role
• Most of them only manage to use roles in a limited manner

The mantra of the day is balance. I think Dave Kearns response to my post was best: “While I do agree that RBAC is the ‘wave of the future’ and is, indeed, necessary to good IdM and compliance, I think of it as being one of the foundations of compliance, not the tool that compels or insures compliance. And certainly not a tool for attestation…”

Tags: Compliance, GRC, Role Management

Jeff was referring to a practice that is very common in a lot of enterprises today. When a user is getting created and provisioned in the enterprise, system administrators and/or managers basically rely on a common short cut. Instead of trying to figure out what privileges that a new user Bob should have, they essentially say “give Bob all the privileges that Alice has, because Bob has the same job as Alice”. As Jeff so articulately pointed out, the result is the propagation of bad or unneeded privileges from one user to another. One can easily see how privileges that Alice accumulated over her lifetime of service end up in Bob’s profile, even if some of those privileges were legitimately assigned to Alice only for a short period of time, after which they should have been taken away. And as we are learning, enterprises are actually quite fluid and the privileges that a user has actually reflects how much a user’s actual responsibilities differ from the base definition of their “job”.

This is the “Model-As” problem, also known within our group as the “Copy User” problem. It becomes a problem because it assumes that the privilege environment is pristine, and that everyone has only those privileges that they should have. It also assumes a highly rigid enterprise where two people doing the same job will essentially do the same things and remain the same from a privileges perspective.  In most complex enterprises, that is not true, and the result is an unnecessary explosion of compliance violations and privilege creep.

The solution, as Jeff pointed out, is actually quite simple – RBAC. The model-as problem exists because it is the poor man’s RBAC model. In the absence of true role management, and role based provisioning, the manager is forced to identify a model user that is, in essence, the description of the role(s) that the new user needs to be assigned. Bringing in RBAC and role-based provisioning can help clean this up by providing the necessary abstraction and control to the environment. Assigning an ad-hoc or short-lived privilege to Alice no longer pollutes the role definition, and therefore eliminates scope creep. It also allows the administrator to change the role-privilege definition once and apply it everywhere, without having to go and track the model-as patterns and chains. In Jeff’s words, it brings sense and order to the “identity chaos” that exists in the enterprise.

Tags: Oracle Identity Manager, Role Management

The content mostly seemed to be aimed at a crowd more generic than the crowd you would encounter at, say, Catalyst. However, they did have a few interesting sessions. Lawrence Lessig’s keynote on the “Future of IDeas” was really interesting, even if his famous presentation style suffered through two projector outages and a light outage. His talk more or less expounded on the notion of needing an identity metasystem for the internet, and the need for us to do something before the government steps in after some kind of internet calamity.

But the session that generated the most discussion between me and my colleagues was Roberta Witty’s session on User Provisioning (or UP, as Gartner calls it). While fairly informative for the lay attendee, she made two statements that were a little controversial (at least for us UP geeks).

“Provisioning is an interim solution”
The above is what I actually say an attendee at the session writing in her notebook. In her session, Roberta said that the emergence of Web Services and SOA architectures would mean that the need for provisioning would start to disappear, as soon as 2010. Now, those of us in the provisioning space have long been saying that the emergence (hopefully) of the SPML standard would definitely eliminate costly provisioning connectors. We have also been saying that externalizing identity data, authorization and security will also lead to a lesser need for provisioning in automated, role-based or attribute-based scenarios.

However, the fact is that provisioning systems add a whole business layer on top of IAM (see my previous post: ‘Ask Dr. K: The IdM Elevator Pitch‘) that will not disappear. As long as businesses need operational flexibility and agility, the need to support ad-hoc, request-based access provisioning will not go away, and that is where provisioning systems will continue to play an important role. The compliance benefits from control attestation (in addition to access attestation), SoD enforcement and workflow perspective will continue to require a management layer on top.

“Role Management will become the focal point for Compliance”
The second point she expounded on was her view that role management systems will become the central point of compliance shortly. Her view is based on her opinion that since role mining tools need to have information about access privileges in order to discover privilege patterns as roles, they are ideally placed to do compliance activities like attestation and SoD policy violation detection. Again, the point is a little skewed. And I don’t say this because I have a provisioning bias. I am, in fact, also involved heavily in Oracle’s role management strategy.

Yes, role management systems (more accurately, role mining systems) have this kind of data in their repositories, but so do provisioning systems. One of the first usages of provisioning systems in compliance-driven enterprise environments is the deployment of reconciliation connectors to pull in the “who has what” information. This includes not just the names of accounts that users have, but fine-grained entitlement information as well. And the capabilities of provisioning systems (well, at least ours) in this area are long established, with a lot of sophistication built into the reconciliation capabilities. Most role mining systems are limited to flat-file based data imports. In fact, some of the bigger role mining products build “integrations” with provisioning systems to obtain the privilege information from the provisioning systems instead of having to go to the target systems themselves. And tout this as key capabilities.

It is also important to keep in mind that BRM systems are just like provisioning systems in that they don’t need to pull in all access data into their realm of scope for their operation. It is almost never the case that enterprise roles are defined based on the access that users have in all systems. In fact, it is usually a much smaller set of systems than provisioning systems typically have to deal with. Especially if you want the mining operation to have a chance of succeeding. Provisioning systems are often key to helping the enterprise clean up access privileges in preparation for role mining projects, by providing attestation and “who has what” reporting to enable the removal of unnecessary access. Project managers of IdM deployments know to not go near role mining till access clean up has occurred.

On a happier note…
I will say that I didn’t disagree with everything I heard at Gartner. In his keynote, Neil McDonald of Gartner talked about ERP becoming the “new center of gravity for IAM”, making ERP players like Oracle very important in the IdM space. Now I can’t really disagree with that view, can I?

Tags: Gartner IAM Summit, Provisioning, Role Management