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.

“User lock/unlock” management scenario

In my previous post I was raising doubts about the fact that implementing lock/unlock account procedure might not be so easy. Here I’m trying to explain why.

Preliminary remarks: although this requirement is rarely present in IAM project RfP’s, it is obvious that any large organization already has a procedure disciplining the user lock/unlock processes. Let’s try to imagine it in detail.

A user can be locked for various reasons. For example:

1. Technical lock (a user is locked because he or she has exceeded max wrong passwords or due to extended inactivity).
2. Administrative lock (specific events coming from HR determine a temporary or definitive user lock i.e. maternity leave or grace period before expiration).
3. Security lock (a user is locked by a security manager).

It is also obvious that unlock procedures must follow hierarchy rules, such as:

1. A Technical lock on a user can be removed by any administrator (Head of Unit, Help desk etc..).
2. A Security lock on a user can only be removed by a Security Officer.
3. An Administrative lock on a user CANNOT be removed by any administrator. His or her unlock is determined only by an HR event (return after long leave or expiration interruption etc..).
4. To complete complexity, if a user’s Security or Administrative lock is directly removed by the target (e.g. using AD console), then the IAM system must react in real time by resetting the unlock.

These processes must be managed by the IAM system since access systems (e.g. MS Active Directory) do not have the “intelligence” for this purpose and therefore cannot “assist” such management.
If this type of requirement, even though not particularly complex, is not directly supported by the tool’s data model, a custom development consisting of "data model” definition managing would be required.
The data model shall support data, relations between them and other already available data as well as necessary developments to implement policies.

In conclusion:

• When the product data model itself already supports these processes, mapping of the said process is reduced to pure and simple configuration in no time. Maintenance and changes are made by high level administrators
• In case native support is not available, the following should be expected: detailed technical specification definition, Data Model updating, policy writing (usually at low level) and tests, changes, complex management, etc….