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.

Changing Roles

We saw that maintenance of roles is rather simple (How to find roles). Maintenance just consists of the CRUD (create, read, update & delete) operation on the role object. But what if a role is in use somewhere already? In this case obviously the referential integrity has to be maintained. Database people may be familiar with this requirement. But, can it be changed at all? Do we need to renew all approvals we received while assigning this role to an identity? Can it be done within the regular attestation?

Well some tough questions. Let's break the case down to the different occasions:

Create:

To my understanding this case is well covered. Roles are an artifact of organizing the business. So it will be a business responsibility, which has to deal with its creation. Let's call this role the Business Architect.

In order to be able to use these roles for access management purposes they need to be underpinned by permissions to access systems. This can only be done in a joint effort with a technical role. Let's call it the System Architect.

In some environments - like the SAP universe - we often distinguish between Applications and System(line)s. So there might be even 2 technical roles: an Application Architect and a System Architect.

As all 3 types of architects are bound to a certain business domain as after all you cannot be a specialist for the whole world. So an overall coordinating Role Model Owner should be appointed to keep the role model clean and lean, comprehensible and free of uncontrolled redundancies.

Update:

roles are versioned

Let's assume for this case that delete is just a special case of update. For purposes of backward traceability and reporting I anyway doubt, that we should delete IAM entities which we may be requested to report on later. But rather I think we should flag them as being out of use and keep them to be able to sum up all changes to an audit trail.
 

If a role for any reason is not yet in use you may pretty much follow the same procedure.

But if the role is or has been in use it simply cannot be changed anymore. Instead versioning comes into play. You may however create a new version of this role. The old version of this role will then be disabled for any further assignment. Only the new version can be assigned henceforth.

 

However in case the update is not just a convenience change, but there is an important reason for it; you may need a special process:

1. Create a new role version,
2. disable the old role version,
3. send an application to all affected persons' superiors and
4. let them confirm the withdrawal of the old role version and the assignment of the new role version.
5. Of course you have to inform the affected individual as well.

 

Sometimes things are a bit more complicated in reality that they looked at first sight.

 

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.

Objects of the corporation - slightly revised

Looking back to the Objects of the corporation, which I defined back in 2010-07-05, I felt the need for some minor adaptations in order to comfortably derive the elementary actions for its manipulation from this model.

IAM-objects & non-IAM-objects

Everything starts with an agreement …

We only care about the digital identity in the corporate context if it maintains any kind of relationship with the organization or an organizational unit (OU).

Let’s state therefore: the identity has closed a contract with the organization, not necessarily a legally binding agreement; whereas usually it is. Although not in focus of the Identity Management the digital identity’s lifespan within the corporation starts with an agreement. There may be more than one of them like a freelancer contract and a bank account creating a customer-supplier relationship or an employment contract and the membership in the workers council.

To take full advantage of the possibilities to automate role assignment we could later resolve the fine structure of the object organization. For now however it may be sufficient to deal with a monolithic object.

Contracting is usually done according to a standard contract type covering at least one standard position, e.g. sales representative of securities trader. Each of these standard job descriptions covers at least one functional role.

The functional role just specifies functions to be performed. What still is missing is the information object to be accessed. Therefore the business role needs to be localized by further constraints in order to bind it to specific permissions. The result is stored in the business role. There are of course many more business roles than functional roles, accessing different incarnations of the same information object type.

According to the RBAC definition permission is an operation on an (information) object.

… and ends up in an "authorization".

The identity’s access to an information object - expressing the use of the object - is stored in the authorization object. There may be one or more authorization object per identity.

Constraints may be specified in the same agreement as the function or in additional agreements and applied to the business role. For example the amount of money, a bank clerk is allowed to sign a credit contract for, may be limited. Or the authority to purchase material may be limited to a specific organizational unit.