Pragmatic Approach, Practical Designs, Secure Implementations

Based on the observations during few recent large scale IAM projects I was involved in, key success factors are in sound understanding of existing business process which drives identity management, building application level profiles using existing access information and bringing them together to form cross platform roles mapped to common HR parameters like user location, department, job function or job title.

Using enterprise roles and profiles has proven to be valuable approach in solving identity and access management issues today while gaining better understanding of IAM landscape for future automation.

Companies can use very simple, inexpensive approach to explore existing IAM processes including building of initial roles, testing them and even incorporating them into manual access management process without making large upfront investment in IAM tools.

Once existing processes are understood and roles are mapped to employee/contractor parameters, future IAM requirements and support tools can be selected based on very specific needs of the company.

Information collected during this exercise can be used to demonstrate IAM benefits using actual production data and can better support ROI discussions for IAM, governance and compliance solutions.

To demonstrate this approach I will try to show how general purpose tools can be used to engineer application based profiles and enterprise roles.

Before any enterprise roles can be implemented and used in production, few important steps need to be accomplished:

  • Current entitlement information must be collected from all application in scope (may be limited to data sample at the beginning)

  • Entitlements should be linked together under some type of global identity, typically employee ID (needs to be done anyways for reporting and any IAM implementation)

  • Appropriate HR parameters used for role engineering must be available for every employee (typically department, job title, location)

This information can be collected within Excel table, but it is better to feed it into some type of relational database because you can potentially have many thousands of records.

Following is typical data needed to start initial analysis:

Column #

Column Name




Any unique identifier which you can assign to a user (typically Emp.ID)



User's First Name



User's Last Name



Employee's Department



Geographic Location



Employee Job Code managed by HR



Supervisor's EmpID



System Code



Entitlement Code for the System

SYSTEM field should contain system names, like UNIX or Active Directory or SAP to identify which access is being recorded. ENTITLEMENT field provides access granted specific to individual system. For example, in Active Directory world entitlement can exist in the form of security group which provides access to file folders, Sharepoint resources etc.

Of course preferred way of collecting this information is to have automated feeds which will bring current set of entitlements/users to the database on regular basis, but initially this information can be collected manually. Once this information is collected, it needs to be loaded into single work sheet in MS Excel where it can be analyzed.

In real life environment it will not be uncommon to have few hundred thousand records in this table because you will need a record for every user for every system and every entitlement they have, but again you may load just a limited set of data with good representation of overall picture.

Once your data is loaded into Excel, it will look like this:

Pivot Data

Data may be loaded directly or by connecting to appropriate database table.

After you have your raw data loaded, you can create pivot table which will be used to define application profiles and cross platform roles and also report on cross platform access by user or by system.

Your pivot table should look like this:

Pivot Table

As you can see this pivot table now allows us to model system access against available employee parameters. It also allows us to filter based on systems/entitlements and employees.

In this example access to systems is modeled against LOCATION and JOBCODE, but any available parameter can be used.

It is also possible to group users with specific access and look at what other access they have across the systems. By implementing simple scripts, it is possible to automatically select a group of users to see what common access they have.

Once roles are engineered, it is not difficult to run a report against actual entitlements and evaluate access coverage by profiles.

This simple process will provide valuable information on applicability of RBAC to different individual systems and cross platform access roles and will have you well prepared for implementation of more advanced automated RBAC and IAM tools should you choose to go in that direction.

You will also have an ability to produce "who has access to what" reports from a single source without going to each an every system.