Live and let Live

It is time to put my two cents to the ongoing dialogue revolving around RBAC versus ABAC.

My impression is that talking RBAC down is presently in fashion and used as a pretext to promote ABAC.

The pro-ABAC Advertisement Campaign foresees an impressive list of reasons. The most popular among them are:

• RBAC projects start with high expectations
• The real world just happens to be too complex to model efficiently with RBAC.
• RBAC misses the context
• RBAC is very costly
• RBAC is almost impossible to finalise
• RBAC is Static
• RBAC leads to Role explosion
• RBAC (Roles) are not interoperable

But the “gem” is

• The RBAC model as opposed to the ABAC model is not context-aware and is thus not well suited to handle SoD requirements.

As a kindness they allow roles to be used in ABAC, as one of the multiple attributes that ABAC can engulf or use to make access decisions.

Now: I can logically agree on all the syllogisms that are used to justify the prevalence of ABAC, but the problem is in the starting axioms: what enterprise authorization solution is actually using “pure” RBAC as a determining factor on whether to grant access to an asset or not?

For instance, our solution IDEAS Enterprise Entitlement Server (the new name of our Enterprise Authorization Server) provides an entitlement model that unifies role-based, rule-based and attribute-based access control.
With this model, entitlements may include dynamic authorization information, such as: contextual attributes (e.g. time of day, value of a transaction, a physical location, ..), user resource attributes (e.g. an account, an organization, ...), and rule-based business logic (e.g. exceptions, call-outs, …).
Of course, historically, we our roots are in Role Management, thus roles have a central position in our solution, but in order to map any application authorization framework, we have included Application mapping capability from the beginning, in our unique data model, that allows for flexible definition and evaluation of complex access control policy sets.

So, instead of only using roles as the determining factor on whether to grant access or not, many attributes can be used. The hybrid adoption of RBAC together with additional context simplifies the making of access control decisions (at finer levels), allows easy compliance with regulations, and very importantly, minimizes governance problems.

Here is an example of authorization policy mapping using IDEAS.

The application is a fiction stock trading application, used by traders in a bank to buy and sell stocks on various stock exchanges.

First of all the model has an:

Actor: the subject (e.g. user that can be mediated by roles, ...) for whom the authorization is evaluated. Example Mr. X with the “Senior Bank Operator” role

and it is based on four entities:

Permission: is an action on the Resource (also called Operation). Example: Trading.

Resource: is the Application element to protect. Example: Stocks.

Constraints: are the Conditions that must be validated to grant the authorization. Two or more Constraints can be merged with a boolean combination of their values. Examples: Trading depends upon the user geographical area; Transfer limit is based on user characteristics; SoD conflict verification in real time.

Exceptions: are other conditions that can further limit the authorization decision and that allow for the creation/evaluation of more complex business logic. Example: Trading not allowed for companies where the user is involved.

that rely on a Role Management infrastructure.

Very lean and straightforward!

I just want to put in a good word now and refute the statements that have been made on Role explosion and SoD management. Once again it is just a matter of selecting the right tools and adopting the appropriate methodology.

In the next post I will try to describe a framework that is able to, not only stop this overstated issue, but above all allow stepped construction of sound and governable role infrastructure. As a matter of fact, it is mainly a matter of using the right tools!

For me, however, the most surprising argument that was raised against RBAC, was SoD management. SoD, and in general, easy compliance is one of the strongest points of adopting Roles in an Access governance framework.
For example, IDEAS offers the possibility to easily define and maintain the scope of roles based on the organization unit structure (for implementing need-to-know, need-to-share). Further, the proposed SoD model allows business users (that might have no knowledge of IT systems) to define potential conflicts among business activities (e.g. “purchase order - creation” or “purchase order approval”) rather than among entitlements, thus decoupling business and IT aspects as well as leveraging a business perspective.

In my opinion (sorry if I now use comparative reasoning) the policy administration issue should not be underestimated. I’m sure that by using IDEAS even a very complex authorization policy is far more viable, thanks to adopted data structuring.
On the other hand, how can XACML policy be set and analyzed? What kind of tools are actually available for managing a very complex application authorization policy with multi-valued requests and rules? What about conflict verification checks?


To wrap-up, I don’t think we need RBAC and ABAC slinging mud at each other (like a typical Coke and Pepsi duel). We don't want to create bad karma: we need to support BOTH! (many agree with this).

Sit down and decipher the most advantageous benefits of your company and its products, without bashing others; because other approaches are also on the horizon… like Risk Adaptive Access Control (RADAC).

It could be a never ending quarrel…

And once again…

Live and let Live

Alessandro strikes again!

Two new Technical Papers, “Mining Stable Roles in RBAC”, and “A Probabilistic Bound on the Basic Role Mining Problem and its Applications” have been recently accepted and will be presented, by my colleague Alessandro Colantonio, at the coming IFIP/SEC-2009- 24th IFIP International Information Security Conference, Pafos, Cyprus, May 18-20, 2008.

I am not an expert in the used theoretical and mathematical concepts, but I find the global effort to minimize complexity very insightful. Clearly, keeping the number of different roles sufficiently small is an important aspects. But there are many other aspects being equally important, in particular roles should reflect the organizational structure, should be acceptable by human users, easy to update, and should consider business constraints. The papers highlight some basic features on which Engiweb Security “IDEAS Role Constructor” module is based.

The abstracts:

A Probabilistic Bound on the Basic Role Mining Problem and its Applications
In this paper we describe a new probabilistic approach to the role engineering process for RBAC. In particular, we address the issue of minimizing the number of roles, problem known in literature as the Basic Role Mining Problem (basicRMP). We leverage the equivalence of the above issue with the vertex coloring problem. Our main result is the proof that the minimum number of roles is sharply concentrated around its expected value. A further contribution is to show how this result can be applied as a stop condition when striving to find out an approximation for the basicRMP.
We also show that the proposal can be used to decide whether it is advisable to undertake the efforts to renew an RBAC state. Note that both these applications can result in a substantial saving of resources. A thorough analysis using advanced probabilistic tools supports our results.
Finally, further relevant research directions are also highlighted.

Mining Stable Roles in RBAC
In this paper we address the problem of generating a candidate role set for an RBAC configuration that enjoys the following two key features: it minimizes the administration cost; and, it is a stable candidate role-set.
To achieve these goals, we implement a three steps methodology: first, we associate a weight to roles; second, we identify and remove the user-permission assignments that can not belong to a role having a weight exceeding a given threshold; third, we restrict the problem of finding a candidate role-set for the given system configuration using only the user-permission assignments that have not been removed in step two (that is, user-permission assignments that belong to roles having a weight exceeding the given threshold). We formally show-proof of our results are rooted in graph theory-that this methodology achieves the intended goals.
Finally, we discuss practical applications of our approach to the role mining problem.

Authors: Alessandro Colantonio, Roberto Di Pietro, Alberto Ocello, Nino Verde.

If you are interested in receiving the full texts, please send me an e-mail: my surname at eng dot it.

Musings on Bruno Munari thoughts

Last Sunday I was walking downtown in the historical center of Rome, and as I was strolling along the Tiber river I came across the Ara Pacis Museum. These days the exhibit area inside Ara Pacis is hosting an exhibition on Bruno Munari.
The new museum, designed by the Richard Meier architect is quite charming: I like its pristine structure that is full of light, but what really touched me was the Bruno Munari exhibition.
In fact Munari’s works and his attitude of whimsy and sheer inventive imagination were actually venerated by me when I was a kid.

From the catalog:

“Munari’s life (1907-1998) and career spanned the 20th century, and he was among the most seminal exponents of Italian design and graphic design. Yet he never received the accolades and recognition on an international scale that he so richly deserved. What sets Munari apart from other designers is that he engaged in a quiet, playful revolution, inventing and designing with humorous and modest creativity, challenging all conventions and stereotypes intelligently but without flamboyance.”

But let me tell you why I’m speaking of Bruno Munari in this blog.

Walking along the exhibit set course, I noticed some of Munari’s sentences on the walls, and among them one in particular attracted some attention:

“Progresso è quando si semplifica, non quando si complica”
“Progress is when things get simpler, not more complicated”

I like to use quotes to mix things up: in this case Bruno Munari reminds me of the aggregation (and/or acquisition) processes currently taking place in the Identity Management space.
We, as all vendors, are supporting our customers move from automating infrastructure procedures (that is meta-directory services, basic identity administration and access management) to enabling business processes, towards the satisfaction of the new requirements for Governance, Risk and Compliance (GRC).
Thus most vendors started down that path of adding new features, and new modules; often with the shortcut of specialized company acquisitions.

And the result is. ......Yes, for sure we are allowed to check the coarse grain Role checkbox in RFP's, and if the prospect asks for a POC we can always mask the mess, ..... and in parallel: let’s pump cosmetic marketing campaigns.

So if the product isn’t built, since the beginning, around a data model that is able to natively manage all processes linked to identity, role life cycles and access governance, just two alternatives are available:

• Rewriting from scratch the product around a coherent and complete data model;
• Try immediately to trim the fat, hide the complexity and hope that the discrepancy that exists will definitely be decreased in the next releases and beyond…

What is happening in the present Enterprise Role management vendor acquisition fever is quite typical.

Is it possible to really integrate an Identity Management solution with an Advanced Role Management solution? And what are the risks associated with this two-headed architecture?

I will write more about this in the next post and try to explain our idea of integrated solution that is able to natively support all the needed features in a scenario, where Advanced Role Management capabilities together with strong Authorization Management is gaining momentum

A pragmatic approach to “Virtualization”

My company, Engiweb Security, is quite small, but I think, has many strengths and is well positioned to play a vital role in the role based identity management and the GRC markets.
One of the innovative aspects that, is worth sharing is our approach to “Virtualization”. Here we don’t want to take sides in the dispute between Meta-Directories versus Virtual Directories: they are both well respected technologies and, looking at our solution IDEAS, I view these technologies as complementary. As a matter of fact we have a hybrid approach.
Most Identity related information is consolidated in the IDEAS master repository (based on a RDBMS) using specific connectors to Target Resources. But there is also an interface to other repositories to provide the required attributes without any need to move information from the existing user repository, thus providing a combined view of all user data.

In other words a sort of “Virtual Directory” or "Identity Virtualization".

The combination of the Master Repository with its strong data model behind (able to manage identity information, policies, business roles, …) and the Virtual data aggregation, allows an external application to have all the needed information to act in a secure way.
For this purpose IDEAS is equipped with API JAVA, API .NET and Web Services which permit an external application to see the required data as one data source, and recover the user security context.
So, applications might require user data that is stored non only in the central IDEAS repositories, but also in scattered different repositories (DB, directories, ..).
This approach makes it possible to keep the central repository lean, no need to fatten it if an application needs some specific data (i.e. external attributes) that are not relevant for other applications.
Furthermore some of these external attributes could also support the internal rule engine processes, where some decisions have to be taken considering specific parameters.

In the next post I’ll introduce another element that, from my point of view, adds a lot of value to our IDEAS solution: the support of SOA-based integration platform for providing a new generation of “Target Resource” connectors.

Do I have an alter ego?

A few days ago I received an e-mail from Courion Corporation: “Register Today: Sept Webinars Now Posted”. … and reading the content, I jumped.


Yes, one of the webinar title was just like the name of this blog: “Roles in Action”.

Of course I will not claim ‘firstborn’ rights. Very often in marketing you can create a catchword using a simple buzzword generator. For example, within my company we recently named a webcast: “Role Management: unlock the complete value of Identity Management, take full control over Compliance”. Not very original, is it?

Anyway, I am looking forward to this webinar. I hope that Courion speaker, Chris Sullivan, will agree with my blog subtitle: “Roles can’t be built in a day”.

How to add "intelligence" to IAM

One of my colleagues just finished up a White Paper that is worth reading: “Let the Good Times Roll: Role Management for Enterprises Is Possible“.
The paper tries to explain how to add “intelligence” to a “classic” IAM solution. It also collects some concepts and examples I have already touched on in this blog.

Here is an excerpt addressing on the concept of Application.

In a large Organization environment there are many "Applications” managing both authentication and authorisation using (for instance) Active Directory groups.
In this context, with a single technological target (AD) connected to the IAM, there are multiple, associated “Applications”. On that level, into IAM environment, “target system” is a technology concept, whereas "Application” is a IAM business concept.

Note that in this context "Application" can be seen as a resources container (in this case AD groups).
Even AD groups set, used for users “Infrastructural” access, could be seen as an "Application". Following this point of view, we can group the “Infrastructural Resources” groups set (Internet, Mail OWA, VPN, FTP etc..) in a container (Application) and give it a name. (e.g. Infrastructure Resources).

This “Application” concept is very important in an IAM environment. Through “Applications” many administrative processes can be easily managed. Especially so are such processes where the “Target” concept does not fit because it is not expressive enough, and the “Resource” concept does not fit because it has too little granularity.
Some examples are:

• Application is a Business language while “Target” or “Resource” are technical languages.
• Dynamic management of IAM administrators “scope” on specific applications (an administrator can only approve requests referring to specific “Applications”).
• Policy writing is much more expressive and simple if referring to Applications instead of always identifying a set of resources.
• Event grouping under an Application is extremely expressive both from operational and auditing aspects.

Most IAM tools refer to technological concepts such as Targets or simple Resources thus resulting in a very low expressivity and administrative complications.
If you want to introduce the Application concept where it is not “out-of-the-box”, you must analyze the impact, define data model and implement all business intelligence associated with the concept.
Instead, with a tool natively supporting this data model, processes implementation related to this concept are direct and prompt.
Referring to the above Active Directory example: with IDEAS by Engiweb Security, once the Active Directory technological connector is created, the creation of an "Application”, its relative “Resources” association and connection to the reference “Target”, is really simple.

Only a few parameters need to be defined, such as:

• Target.
• Synchronisation Options (Automatic, Manual NoSync). It is interesting to note that native Applications management, based on “Sync. Options”, make the synchronisation chain work in a different way. In fact, in the case of Automatic Sync, if a user is assigned an Entitlement or a Role which includes a resource from this application (e.g. an AD group), the system generates an outbound event towards the connector which automatically associates the group with the user. On the contrary, Manual Sync generates an event which is retrieved from a file to run a Batch Synchronisation (everything out-of-box).
• Resources connected.

A new webcast on Role Management

If you are interested in Role Management and in particular in Engiweb Security’s approach to this business issue, you can tune in to a new webcast featuring Roberta Witty - Gartner Research VP, Richard Parisi - Engiweb Security International Customer Support and Alberto Ocello - Engiweb Security General Manager.

For registration to this webcast, click here.

An Italian clichè

A friend of mine sent me an e-mail with a ppt file attachment. It was in Italian, but the translation in English was easy. It was a joke on an Italian cliché, but it was a great illustration of a common Identity management nightmare: role explosion!

Yes, at least in Italy, most customers we work with are very clever at imagining every level of nuance when “theoretically” defining roles in their organization.

But fortunately, we are used to facing their anarchy and we know how to prevent the awkward problem of “role explosion”.
As the picture says, to survive we have been forced to take adequate countermeasures. For example the waitress can simplify the orders by requiring the customers to add their own sugar, milk, liquor, etc. Therefore, by restricting the number of kinds of coffee, requests are delivered in a timely manner while maintaining flexibility.

So, business managers, don’t be afraid: just select the right tools and adopt the appropriate methodology!

New Technical Paper on Role Mining

A new Technical Paper, “Leveraging Lattices to Improve Role Mining”, has been recently accepted and will be presented at the coming SEC 2008 23rd International Information Security Conference, co-located with IFIP World Computer Congress 2008, Milan, Italy, September 8-10, 2008.
Topics of interest of this conference include, but are not limited to:

• Access control
• Security and Content Policies
• Role Mining
• Security Compliance
• Identity and Trust Management

The paper highlights some crucial aspects on which Engiweb Security “IDEAS Role Constructor” module is based.

Abstract:
“In this paper we provide a new formal framework applicable to Role Mining algorithms.
This framework is based on a rigorous analysis of identifiable patterns in access permission data. In particular, it is possible to derive a lattice of candidate roles from the permission powerset.
We formally prove some interesting properties about such lattices. These properties, a contribution on their own, can be applied practically to optimize role mining algorithms. Data redundancies associated with co-occurrences of permissions among users can be easily identified and eliminated, allowing for increased output quality and reduced processing time.
To prove the effectiveness of our proposal, we have applied our results to two existing role mining algorithms: Apriori and RBAM. Application of these modified algorithms to a realistic data set consistently reduced running time and, in some cases, also greatly improved output quality; all of which confirmed our analytical findings.”
Authors: Alessandro Colantonio, Roberto Di Pietro, Alberto Ocello

Nice, Friends!, But, pardon me if I find much more pleasant another kind of Lattice: A nice piece of the Rhubarb-Strawberry Lattice Tart really hits the spot!

BTW if you are interested in receiving the full text, please send me an e-mail: my surname at eng dot it.

Inconsistency: the revenge

Before going on to introduce the second inconsistency case study, I just want to stress again that we are not speaking of a sort of “event manager” that monitors the activities performed directly on targets and blocks any possible operation. Here we are introducing a solution (part of a Governance and Compliance framework) that intelligently tries to understand if this operation could be accepted, taking into account presently enforced security policies. As a matter of fact, the realistic situation we are facing is the typical end-user’s requirement for additional access to another application (target). The official way (e.g. following a workflow) is not fast, so he calls his friend that works in the IT administration and bypasses the official procedure, quickly achieving access to his coveted application.

Previous episode: IAM System - Targets inconsistency policies: remove
There is not way to prevent someone (a naive “authorized” administrator ) from removing Profile1 from user John on target1.
Meanwhile, the IAM system must assure a single centralized record of reference, even if the IAM administrator is gambling poolside at Vegas with his new intelligent mobile phone…
To be more clear, take a look at the following diagram:


This Latest Episode: IAM System - Targets inconsistency policies: add!
As already anticipated, if the Administrator, again directly on a target, adds a profile to John, this would be even more difficult to manage as there could be a huge impact on Separation of Duty verification.

Actually managing the already described “remove” scenario, means assuring Security Policies, even if the operation ability of the “involved” user could be somehow diminished, but when the unaware user (John) gets a new profile with a direct action on the target, no preventive compliance control is performed and the real danger could be: Security breaches, failed audits, non-compliance, all the way up to fraud.

One again a sound IAM solution should effectively manage the risks associated with such a scenario, with the objective of assuring compliance with the least operational impact.

The following diagram explains how the Engiweb Security solution (the IDEAS suite) deals with this inconsistency (the offset between the IDEAS core repository and a generic target system) and how the Inconsistency Role Engine goes to work to repair the offset.

In this case, an authorized administrator accesses target1 and adds Profile1 to user John.

If the policies are set to try and accept the profile addition if possible, the first check is performed using a Segregation mechanism on the base OU. A profile is available for assignment to a user belonging to a certain OU only if “visible on that OU”. In this situation, particular profiles having some criticality can be “hidden” to OU’s that do not have the so-called “need to know”.

A second mechanism, used in the next checks, performs profile and role incompatibility management. This mechanism is supported by a powerful incompatibility SoD engine able to make run-time checks on a pre-assigned conflict matrix and contextual information. The system also contains a Role_Policy_Definition module which, starting from high-level incompatible activities, helps the administrator define a matrix of conflicting profiles.

Illegal roles and incompatible role-pair lists are also used by the IDEAS Profile Provisioning for other run-time SoD checks during user provisioning compatibility control. The SoD engine is queried for each new role assignment request. If assigning the role makes the user illegal, different authorization workflow steps can be executed.

Yes, in this case our IAM administrator can spend some more time poolside at Vegas undaunted by any notifications he may receive on his new intelligent mobile phone regarding of what’s happening at work!

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.

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.