Authorisation – what does it mean after all?

In the field of Identity- & Access Management terms like authentication an authorisation are well understood, frequently used and everyone knows what they mean. Really?

Well, Identity Management is about managing identities, e.g. of employees. Access Management consequently deals with access, e.g. to information objects. And it is quite obvious that, before you may access any protected information object, you 1^st have to be authenticated (Are you the one you claim to be?) and 2^nd you need to be authorised (are you allowed to perform that particular activity on a specific information object?).

In a contemporary architecture, which may be considered as such when being ‘service oriented’, there hence would be an authentication service, taking care of the authentication task, and an authorisation service involved. Both are run time activities on an operational level, rather than administrative tasks on a management level.

So it’s clear now, isn’t it?

But what does authorisation mean? When is a digital identity authorised to access a protected information object in a defined way? Is it done 1) when the privilege is assigned to her / him (logically at administration time) or 2) when this authorisation is enforced (physically at runtime)?

Hmmmm.

There might be even 2 warring factions – and I have been member of each of them – each at a time. In the essential world (

http://genericiam.blogspot.de/2010/08/modelling-fundamentals.html) of course 1) applies, because once the role / attributes are assigned, nothing more is left to be done (http://genericiam.blogspot.de/2012/02/apply-approve.html). For the SOA people, who live in the real – physical – world, it might rather 2). As here you may easily design a single-tasked service, an equivalent to an authentication service.

Hmmmm.

It might not appear worth to discuss these topics here. But I encountered this discussion once at one of my customers. The good news however is, we are not the first and only ones to be confronted with this schism.

And I think the XACML people (http://xml.coverpages.org/XACML-v30-HierarchicalResourceProfile-WD7.pdf) have done quite a good job. You may remember that with PRP, PIP, PAP, PDP & PEP they defined four fundamental processors.

They perform the following tasks …

1. The PRP does the policy retrieval,
2. The PIP does the policy information,
3. The PAP does the policy administration,
4. The PDP does the policy decision and finally
5. The PEP does the policy enforcement.

The 2^nd P at the acronyms end obviously means ‘point’. In process notation the five processors do …

1. Retrieve policy
2. Inform about policy
3. Administer policy
4. Decide policy and
5. Enforce policy.

All of them may be seen as processes from the authorisation ecosystem.

As ‘policy retrieval’ and ‘policy information’ can be matched with the well-known directory service and / or database, where the ingredients for the following activities are stored, this activity can well be seen outside of the core authorisation.

‘Administer policy’ however is the type 1) essential activity from above.

Perhaps the illustrations created by Axiomatics may help here:

see: www.axiomatics.com

The remaining two activities ‘decide policy’ and ‘enforce policy’ are performed at run-time and they would be part of the type 2) authorisation activity of the SOA people.

The confusion is also related to the role based (RBAC) vs. attribute based (ABAC) access control discussion.

• Whereas in (static) RBAC thinking an Identity is assigned at least one role (The R in RBAC) and this role comes along with the elementary entitlements dangling from them, on essential level all is done to authorise this identity. The entity containing this assignment can well be called ‘authorisation’.
  
• In the (dynamic) ABAC approach rules operate on attributes (the A in ABAC) which in turn are associated with the identity. In case the attributes used here can be considered as being static, i.e. stay unchanged until next policy administration, on the essential level authorisation would happen – as in the RABC world – when the rules are set into place. However as rules might be complicated and are not directly assigned to an identity this case is less obvious and reveals its truth after closer examination only.  

If however attributes (not to talk about rules) may change from one policy decision to the other, policy decision would be the authorisation step.

For real world static RBAC authorisations you would anyway need roles and rules in combination. So changing the R for an A makes less a difference than the increase of dynamicity.

I think I will adapt my essential processes to reflect this thinking. And time has come anyway to amend them with a ‘physical ring’in order to cover the physical runtime processes as well.

The constraint universe

You might remember my simple model of static objects of the corporation. Now here comes the complexity. In my nice a lean model of the static IAM objects there was one innocent and less impressive object called constraint.

I borrowed the term constraint from RBAC ^[1], where various kinds of constraints can be specified. RBAC knows separation of duty constrains, prerequisite constraints, and cardinality constraints. The constraints of the RBAC model are expressed using the Object constraint Language (OCL). OCL constraints, based on first-order logic, are generally perceived as being difficult to understand.

There are several privilege determining dimensions

In this BLOG post I don't follow the narrow RBAC view of constraints. Let's step back first, to get a complete view of the privilege determining dimensions. If the question goes like this: "What are the dimensions of information, which determine the privileges (permissions) to be bundled to one role?" Then the answer might come as a list like this …

• Business function (as defined in a functional enterprise model),
• Region,
• Organizational unit,
• Market,
• Authorization amount limit
• Project,
• Information object
• Contract type
• …

The first Dimension, which leads to the determination of privileges, is indisputable. That is the function or functional role. The remaining privilege determining dimensions however are debatable and probably incomplete. This means they depend of the corporation we intend to model - expressing what appears to be important to them for privilege assignment. And as I doubt that we will ever be able to come up with an all-encompassing list of all possible dimensions from where we just have to select the right ones, I simply like to leave the end open to be completed individually by each modeller.

Therefore I bundled all other dimensions - except the business function - to the object constraint. But now it is time to unfold them and to name the different dimensions or types of constraints.

The seven commonly used constraint types are:

1. Region - usually the functions to be performed are limited to a region (US, Germany, Brazil, China ...). It may be useful to explicitly state the absence of this restriction by the introduction of a region "world".
   
2. OU - quite often the areas of responsibility have been separated by the definition of organizational units (OU) already. This applies to markets on the top level such as banking, insurance and leasing as well as to executive secretaries (by business line) or to departmental activities. Again, it may be useful to make the absence of this restriction explicit by the introduction of the OE "group". Projects in this context can also be regarded as (temporary) OUs.
   
3. Customer group - the segmentation of the market by customer group (wholesale, retail, corporate customers, dealers …) also leads to constraints to the pure function.
   
4. Authority level - in order to control inherent process risks organizations often set "levels of authority". There may be directly applicable limits, which are expressed in currency units or indirectly applicable ones. In the latter case they are expressed in parameters such as mileage allowances, discounts, discretion in the conditions defining ... which in turn can be converted into monetary upper limits.
   
5. Project - If projects are not considered as (temporary) OUs, they represent a
   separate dimension determining information access: project managers and other project functions usually have received their privileges for a particular project and cannot access resources of other projects.
   
6. Object - Sometimes you may be able to restrict permissions to a defined information object. A tester has to run tests on particular software object (application or system) only; a janitor is responsible just for a particular house.
   
7. Contract type - Different privileges also arise from the contractual agreement a person has with the corporation. Hence the permissions of permanent employees, interim managers, contractors, consultants and suppliers usually differ considerably.

Other conceivable constraint types are...

1. Cost centre - sometimes cost centres don't match with OUs or projects and for reasons of cost allocation employees are allowed to "move" within their cost centre only.
   
2. Company Code - To further fine structure market segmentation within customers groups or for the distribution of workload sometimes auxiliary structures such as client or company codes are used. Different codes may lead to in differing permissions.
   
3. More to come - ... most probably there are more privilege-determining dimensions in use out there, which haven't been listed here.

Segregation of duties

Following the structure used above segregation of duties (SoD) do not count as constraints. They do not further restrict the privileges which are granted via assigned functions, but exclude certain functions form being combined.

IM + AM + CM

As a helpful notion, the three disciplines of AIM, IM (identity management), AM (access management) and CM (compliance management) can be clearly separated from each other's. Here, the AM resides on top of the IM and the CM on top of the AM. constraints hence are part of the AM; SoD's however belong to the CM (which deserve its own, or more, BLOG post).

Checks for the separation of duties are required in two cases:

1. When roles are created / modified to ensure that they are inherently free of SoD conflicts.
2. When roles are combined, e.g. when assigning them to digital identities (persons) or when they are aggregated into combined types of roles.

Application

To determine the necessary permissions for a given job description, you need to determine …

1. Which of the above-mentioned constraint types are actually used to determine privileges,
   
2. What possible additional constraint types can be detected by examining existing privilege assignments and
   
3. Which values of these constraints lead to which privilege restriction?

Using this information should - if done right - enable us to determine the full set of privileges necessary for a certain job description just on the business level; which is fine as IAM is a purely organisational task.

After having done that the technicians may add references the technical permissions which may be provisioned to target systems or interpreted directly at run time.

---

[1] D.F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli. Proposed NIST Standard for Role-Based Access Control. ACM Transactions on Information and Systems Security, 4(3), August 2001.