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.