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.

RBIA: The Great Unknown

An Identity and Access Management project is not always an easy job. It is very difficult to describe in few words why, but one reason for sure is that in the IAM environment procedures are always more important than technology. In other environments, (e.g. Document Management), technology can drive procedures, thus the right technology choice is the most important aspect.

Conversely, in the IAM environment it is quite impossible to find customers willing to change procedures because technology is unable to map these procedures into the product (or achievable only with huge software customisation). Procedures are important and relevant processes have to be mapped into technology without compromises.

On the flip side of the coin, there is another aspect to consider.
AM technology is still evolving. Most “official” IAM technology vendors are coming from the User Provisioning environment; in essence, coming from the bottom. Pure technology. Of course vendors are adding features trying in attempts to raise the bar but they are still conditioned by original sin – They want to add intelligence to technology instead of adding technology to intelligence.

Intelligence, as in many other IT contexts, is represented mostly by the conceptual model standing behind the product and a data model representing the conceptual model.
The secret of product “intelligence” lies in the conceptual model and its relevant data model.
Technology features like a beautiful, rich graphical interface for workflow design or the huge standard support are all important aspects, …. but I suggest that customers intending to acquire an IAM solution verify how complex it could be to implement simple procedures (e.g. user lock/unlock levels or procedure). It turns out to be a mess with customized software development and the writing of many, many technical policies: even if within a nice graphical environment.

This situation has encouraged the founding of companies who start from RBAC and progressively enrich the model to reach complete RBIA (Role based Identity Administration).
The RBIA model intends to integrate all concepts of User Management (including Credential Management), Role Management, Role Engineering, SOD compliance, Audit and Reporting all the way up to Unified Identity Approach, in order to unify Logical and Physical Access Management views.

According to my understanding, customers’ important expectation of an IAM project that easily supports present and future Identity Management procedures and processes, indicates that a field proven RBIA product is a “must”.

Addition of RBIA functionalities could result in an increase in license costs with respect to the budget sum. However, in our experience, this is greatly offset by tremendous savings of time and cost of project implementation along with a heavy reduction of project risks.

BTW, in a following post I’ll try to justify why implementing a lock/unlock account procedure might not be so easy.