Dialogue on Enterprise Role Management Integration Challenge

Ian Glazer, in a recent dialogue to his “TuesdayNight” blog makes this comment to a previous comment of mine, on The Enterprise Role Management Integration Challenge.

“I may not have been clear. What I meant by integrating role management into user provisioning as a no brainer is that from a product and market strategy position. It is a straightforward decision for product managemers and marketers.

I don’t agree with your point that the majority of user provisioning technology is intended for synchronization. If that were the case, then user provisioning products we be worth nothing more than a meta-directory with a pretty face. The ability to add policy governing who gets what is a core part of user provisioning. Role Management can ease the provisioning policy construction and can certainly provide a great deal of value is the person to role mapping process, but in these capacities are acting as augmentation to a user provisioning systems policy and workflow capabilities.”

Ian, thanks for getting the dialog going.
I am in general agreement with your assessment that from the marketing standpoint the integration is logical and plain. The two components must be integrated and collaborate.

The purpose of my comment (perhaps a little bit extreme) was to highlight that when integrating user provisioning and role management, most policy related functions can’t be managed by the user provisioning component.

In fact, current user provisioning products have the ability to add policies, but cannot handle the complete view of an Identity management solution (that includes aggregation, storage, and management of business relationships, roles and related resources, multiple views of the business based on policy-driven roles, supplies relevant privileged data of enterprise systems, meet compliance and auditing requirements, ..).

The current systems implement policies using rules both at the central level and, unfortunately, rules directly coded in the connectors themselves. Since this cannot be scaled an already difficult situation becomes impossible to manage: no high level tool , no global vision, no comprehensive compliance management.

Why? Mainly because they were designed for “historical” synchronization needs; and when policy requirements arrived functions were added-on without first discussing the general picture.
Actually, other aspects on this integration are covered in my post: A Role Management Manifesto.

Finally, (again using an extreme metaphor) it’s like implementing an HR system using Microsoft Excel. YES, nobody can tell you that’s impossible, but what are the costs?

What are the perspectives from user provisioning vendors? I would welcome a dialogue on this topic going forward.

A "Role Management Manifesto"

Alberto Ocello, general manager of Engiweb Security has just released a position paper, called “Identity Management: searching for the Promised Land “ that aims to open a constructive debate within the Identity Management community.
As the recent acquisitions demonstrate, roles and role management exit from their niche and move to become the central elements of IAM projects: the real value will come from supplying “intrinsic” richer role environment, providing customers a comprehensive solution that covers all the bases.
Do you agree on what is stated? What are your ideas on Role Management - User Provisioning integration? Any other arguments?

In the following you can read the document (that you can also download here):

-------------------------------------------------------------------

Identity Management: searching for the Promised Land

Identity & Access Management has entered a new era.

Traditional User Provisioning is now a vague shadow of the past. The classic model principally thought of as a synchronization tool consisting of users, permissions and at times roles, is proving itself to be limited in managing complexities associated with the modern concept of Identity & Access Management. Gartner and Burton both ratified the new IAM model (the need for role management) and big Identity Management players are gearing up to improve their offerings. The acquisitions of Bridgestream on the part of Oracle and VAAU on the part of SUN give concrete proof that the transition has begun.

However, as the tide shifts there is particular confusion; not so much about new functionality supporting “new” Identity Management, but rather, which model must be at the foundation. It is neither proper nor sufficient to merely speak about new, required features. Instead, it is imperative to reinvigorate dated Identity Management models with rich, exhaustive support for new functionalities. This goes beyond a set of algorithms that efficiently handles complexities of the model. It is in fact well known that RBAC, as defined in the standard, cannot support the new functionality requirements associated with Role Management. The RBAC model therefore must, out of necessity, be enriched.

Role Management companies are the ones that should be delegated to propose and implement these new models. Unfortunately, neither the model nor algorithms used have been explicitly described by anyone. From the analysts’ side, there has never been an ad hoc study addressing such themes for a constructive comparison of the solutions. Thus, with the aim of initiating such a constructive comparison, Engiweb Security has chosen to reveal, in detail, the models and algorithms they have developed and implemented in their own Role Management product.

The “cost-based” RBAM algorithm used in the Role Mining product has already been described in a paper soon to be presented. (A. Colantonio, R. Di Pietro, and A. Ocello. “A cost-driven approach to role engineering”, In Proceedings of the 23^rd ACM Symposium on Applied Computing (SAC ’08), Fortaleza, Cearà, Brazil, 20-16 March 2008). A following paper will present the scientific community with our Role Management model, “COFFER” (COst-based Framework For Enterprise Role Administration). COFFER extends existing frameworks, enriching the RBAC model with organizational and business elements through concepts such as “Object-based SoD”, “SoD Domains” and “Relaxed SoD”. The paper will also describe algorithms used to maintain the model. By means of the “generalized cost function”, such algorithms determine an economic value for every operation in terms of administration cost.

In order to open a constructive dialogue within the Identity Management community, we will now introduce some concepts on which the Engiweb Security framework is based.
The importance of business modeling in role management has long been understood from scientific literature. There is a list of various attempts to extend the RBAC model to further include such elements as business processes, organization structure, etc. Undoubtedly, the most famous are the ARBAC family of models proposed by Oh and Sandhu, the Nyanchama and Osborn Role Graph Model and the Crampton RHA model. Despite the validity of these models, none characterize ALL the business aspects necessary for efficient and effective access management. According to our point of view, a “new” access control model should consist of, at the least, the following sub-models:

Role Model: users, roles, permissions, role hierarchies and relative user-role and permission-role relations as described in the RBAC standard. All these elements have to be enriched with additional elements supporting the role-engineering phase, both top-down and bottom-up. Using the “administration cost” concept it is possible to appraise the “quality” of the proposed model and consequently identify possible areas for improvement.

Organizational Unit Model: concept of organizational unit hierarchies and relative user-OU and role-OU relations which efficiently strengthen “need-to-know” and “least privilege” concepts. This sub-model supports not only the role-administration phase but also the role-engineering process.

Activity Model: business role representation deconstructing business processes down to an activity hierarchy. It is important to highlight that a Role Management tool must not represent a complete instrument describing all facets of business processes. Rather, it must offer the possibility to capture only the relevant aspects necessary for access control. For example, one can hypothesize permission-activity or OU-activity relations, using concepts well established in literature such as the permission activity structure. This sub-model, like the organizational unit model, offers information indispensable for role definition and administration.

Separation of Duty (SoD) Model: according to this model, incompatibilities are not directly defined between pairs of permissions or roles as usually done in IAM / Role Management Solutions. Rather, as is considered to be more accurate, the incompatibilities are defined within the activity model, particularly between activity pairs. The quality of this approach is evident when considering that such a representation simplifies the association of permissions to SoD groups much like RBAC roles simplify the association of permissions to users. This sub-model enables effective description of both strong exclusion (Static SoD) and weak exclusion (Dynamic SoD) constraints. The introduced “SoD Domain” concept partitions the graph, thus drastically reducing computational complexity.
With this versatile sub-model one can easily deduce various types of conflicts between entities (e.g. user-user, OU-user, role-role, permission-permission, user-role and role-permission). This sub-model also enables introduction of new concepts such as “Relaxed SoD”.

The complete model will be described in the next paper to be published.

To conclude, we would like to make some remarks as a starting point for a genuine discussion of the topic:

1. We are of the position that it is necessary to consider as a minimum the entities outlined above and the relations between them in order to accurately express the true necessities of an Identity Management project. Based on personal experience, simpler models such as the RBAC standard prove to be inefficient, especially for large organizations.
2. In order to correctly and efficiently represent a model defined in terms of entities and relative relations, RDBMS are necessary. There are some solutions on the market which continue to insist on managing this information using hierarchical LDAP. Hopefully these are just premises motivated by marketing. Nonetheless, our community needs the courage to affirm that this option no longer makes sense.
3. In a concrete Role Management solution, business modeling is not an option. The RBAC model is not sufficient for effective management of real business needs. For example, it is impossible to think of modeling SoD constraints using only a set of incompatible permission pairs. Experience shows that dealing with hundreds of thousands of permissions often results in millions of pairs of conflicting permissions. We need to admit that this is not a viable approach and is absolutely unmanageable.
4. All the described entities obviously have relations among themselves. Yet, we cannot expect to manage these relations with various tools.. From that point of view, integrating User Provisioning and Role Management components is far too complex an effort. We hold that only the technological portion of User Provisioning (connectors towards the target systems) must be used. Those proposing such complex tool integration approaches need to have the decency and transparency to explain how they accomplish these while avoiding needless and dangerous data duplication.
5. The resource provisioning (connector) needs to be partially revised in order to be efficiently utilized in more complex models compared to traditional User Provisioning. Although the majority of such technology is intended for synchronization, we need to strongly affirm that Identity Management is not mere synchronization. Take, for instance, the typical example of inconsistency management. When a bi-directional connector carries out an operation directly on the target system (e.g. permission-user association) it is still the central system that must define the policies to be applied. Clearly, in a User Provisioning system (users-permissions management) everything boils down to synchronization or, at the most, a “go/no-go” policy. In a multilayer model as just described, such an action can lead to the modification of many relations and decisions depend on many factors that will be shaped into appropriate policies. Actually, many resource provisioning systems (connectors) are not even equipped with an “anti-loop” system for events they themselves generate as it is not necessary for simple synchronization actions. In fact, they are of little use in more complex contexts.

This message is both an invitation and a strong appeal to the entire Identity Management community to constantly maintain the distinctive qualities of transparency and intellectual honesty even in this difficult Identity Management market.

High Renaissance in Role Mining

This metaphor was used in a presentation to better illustrate how possible candidate roles-sets can be determined. I like it: it exhausts the position of the Role Engineer, even if his creativity is constrained…

As Michelangelo chisels away needless pieces of marble, bit by bit, an exquisitely beautiful shape emerges, similarly a Role Mining tool reveals embedded de-facto roles, clening up privileges, and the unavoidable “noise” – authorization exceptions and errors.
However, a simple chisel is not enough. Did Michelangelo follow a hybrid approach too?

The Pietá is generally considered to be the masterpiece of Michelangelo’s early years, deeply poignant, exquisitely beautiful and more refined than his later works were to be.

A white paper on "Role Engineering"

This blog has also been set up to pass along supporting documents from people working at Engiweb Security, to send news and get feedback from the IAM community. So.....

My colleague Alessandro Colantonio has just released a white paper entitled “Cost-driven approach to role engineering”. You can download a copy here.
"Cost-driven" is the philosophy that inspires Engiweb Security's “Role Constructor” module.

In general most proposed methodologies lack a formal metric to capture the “interest” or “quality” of proposed roles. To address this problem, Engiweb Security's role discovery tool can identify a role-set that minimizes the administration cost, by measuring and evaluating cost advantages during the entire role-set definition process.

Various elements can influence the administration “cost”:

• Number of roles, role-to-user assignment, role-to-permission assignment and hierarchical relationships;
  
• Business process and activity modeling;
  
• SoD constraints, Temporal constraints, Cardinality constraints, etc.;
  
• User attributes (organizational unit, business function, physical location, etc.);
  
• Actual usage frequency of IT resources, …….

Furthermore, the developed algorithm can easily be scaled to manage huge RBAC role engineering tasks, such as those usually encountered during a large Identity and Access Management projects.

Alessandro will better describe our approach, speaking at the “The 23rd ACM Symposium on Applied Computing” to be held in Fortaleza, Ceará, Brazil, March 16 – 20, 2008.

Greetings IAM community!!

I’ve been involved in studying security and identity based solutions for the last 5 years. Follow along as I share practical experiences about how Role and Identity management solutions have a major impact on the way organizations do business. I’ll also talk about practical implementation, work philosophy, common traps to avoid, as well as people I’ve met along the way.
These are my first steps in blogging, so sorry if I'm starting slow. I'll learn quickly with your feedback and support.