by Martin Klein,
Business Analysts Pty Ltd Consultant
My mum told me once that she went for a holiday to Italy and Vatican city and there she visited the Vatican museum. But after lining up for hours to get in, and even being allowed to enter the hallowed halls of the iconic museum, viewing the religious artefacts, she still wasn’t permitted to access many of the areas that more devout members of the community would be allowed to enter. Despite this she enjoyed the visit and would gladly repeat the process, although with Italy currently in lock down, I dare say that will not eventuate any time soon.
In identity management terms, the IAM system is often required to provision an account at specific levels that are commensurate with the persons authority within the organisation. In my mums case, she simply didn’t have the right authorisation level to touch the hand of god, in the Sistine Chapel, even if she was tall enough to do so.
Don’t you hate going somewhere, and finding that you aren’t allowed access to the areas that you were desperate to see or experience. It’s like having a ticket to a festival but not being allowed to the most fun areas, like the German tent with the umpa band and dancing the chicken dance on the bar tables. (I’m not saying I did that, just that it was fun if I did!)
The A in IAM stands for Access, the access to applications. Often times people will confuse Access with Authorisation. It is a frustrating paradigm where often times people will use either term interchangeably and end up confusing us all.
To clear this up, I tend to refer back to the metaphorical story that is on the Microsoft website for identity management. In this situation, Microsoft identify that a person has an identity through having a passport. But, access to a country is provided through a visa. However, even with a visa, the person may not be authorised to visit every location. As an example, they may not be authorised to visit the army barracks. This requires a special permit and typically this would be based on the role that the person holds.
In IT terms an account is provisioned to a resource to permit access for the person to that resource such as a file system. Authorisation controls what files the person can have access to. In an application this may be applied through a role which is applied when the person is added to a group or table in the application database, or in a file system, access is applied via ACL’s (Access Control Lists).
This blog aims to identify how we can determine what authorised access the identity is provisioned with when the account is first provisioned or changes to the account are made.
To cut a long story short the answer is attributes. Each identity is comprised of a number of attributes including given name, familyname and a whole host of others, often described from the position the person holds in the organisation.
Let’s step back for a second to how we developed the identity in the first place. It wasn’t the stork that delivered the baby, it was the HR system and as we have already discussed, that delivery provided gender information, position, title and many other trinkets of information. As surprising as that is, HR typically capture a whole raft of information about the person and of course they are placing the person into a position.
Many HR systems work in a rather complex way when assigning a person to a position. Each person is firstly given a unique identifier in the employeeID so we can differentiate the two Bob Brown’s in the company as two separate individuals.
When placing a person in a position, the HR system often considers the position as a separate entity. So the association of the person entity with the position entity may not be a direct one as there will be many cases of multiple people in one position and multiple positions to a person. Often times the HR system uses an Occupancy entity to associate the person and position entities. That occupancy will define whether the person is full time or part time and other work specific details.
So, when we get information about an identity from HR, we are also receiving information about the position and the occupancy. Or at least we can if we chose to. The resulting data from HR is then stored in the Identity vault and components of this are used to provision an account into specific applications that not only create the account access, but also provide the right level of authorisation.
The data mapping table below is a brief example of what attributes may be used to provision access and authorisation.
| Source Data (HR) Attribute | Identity Vault Attribute name | Target system attribute names | Attribute use | ||
| Given Name | | Firstname | | Firstname | |
| Family Name | | Lastname | | Lastname | |
| Username (derived from first and lastname attributes) | | Loginid | To login | ||
| Position | | Position | | Role / authorisation level (combination of position, department and location) | Used to set authorisation level |
| Location | | Location | | ||
| Department | | Department | |||
| Date of Birth | | DoB | unused | ||
| Manager | | Line Manager | unused | ||
| Preferred Name | Derived from alternative source for use in email and collaboration systems like skype |
The above table is an extremely brief set of data that might be sent from HR or a source system to the Identity Vault and from there to a subsequent target system that the user requires access to.
Of course, the business rules are defined to determine what level of authorisation that a user is provided. These rules are simple ones that effectively might state:
If Position = x and location = y and department = z then create role as manager. This completely depends on the target system. For example, creating an ACL in the file system can be done by identifying a user in a specific location to have access to files from that location, a manager with additional access etc.
The other way for file systems is to add the user to a group membership, but once again this would be determined based on the attributes of the user. E.g. managers group for anyone with a position of manager.
These can be quite complex and with the complex structures of organisations it is not unusual to have at least a few business rules conflict. The only way around this, given the large number that will be created is to work through them carefully and keep it as simple as possible.
Of course with the right level of authorisation I am sure we could all dance the chicken dance on the tables of the HoffBrauHaus, but in the meantime, until we get that from the right attributes, we might just save it to having a quiet Shiraz at home where we can dance to our hearts content whether as chickens or ballerina’s and my mum can try to reach the hand of god in the Sistine Chapel although she probably needs to grow another 20 metres tall.