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 23rd 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:
- 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.
- 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.
- 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.
- 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.
- 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.
