Identity & Access Governance in the age of digital transformation

Identity & Access Governance obviously is a difficult task. Many major corporations struggle to meet their various compliance criteria, which could be expected as a natural by-product of good governance. But having hardly completed this job, the next one, innocently called “digital transformation” knocks at the door.

Will governance thus become even much harder by then: At least I was asked that question recently. Ok, let me quickly give an introduction to the total topic, go into a little more detail where it appears appropriate to me and eventually come up with a couple of brave conclusions.

You might have heard of the new esoteric trend “Declutter your life”. Some very similar recipe I would prescribe the majority of today's companies: “Declutter your infrastructure (before going to digitize it)!” So, with all right, you can expect a decluttered contribution too, dear reader. However, the text nevertheless has become slightly lengthy. I will therefore publish it in three parts - one per week:
  1. Governance and Identity & Access
  2. From ‘oversight’ to the algorithm driven company
  3. Challenges ahead for a digital transformation agenda

What is Governance after all?

The term Governance was coined and defined during the last years of the previous century. However before that time too some form of ’governance', i.e. oversight, strategic change & direction was always expected from high ranking positions like non-executive directors.

In the beginning it was all about corporate governance, as senior management first had to be convinced of the usefulness of handling this new discipline explicitly – before it was applied to sub categories, like e.g. Identity & Access. By now it is accepted that a governance layer should reside on top of each management layer.

In case you want to get an in-depth introduction into Corporate Governance, its Principles, Policies and Practices I recommend the voluminous authoritative guide by the 'father of corporate governance', Bob Tricker, surprisingly named, 'Corporate Governance'.

Identity & Access Governance

So, how did we discover Governance in the I&A world?

Historically we started with the attempt to manage Identity & Access – as it became time to do so. This task alone turned out not to be easy going. While by then I expected the corporate world to do their homework within a timeframe of 3 to 5 years, it isn't even achieved today to a sufficient degree. And more challenges are looming around the corner, not least the digital transformation.

But even when companies succeeded with the introduction of I&A Management, the questions arose: Are we doing the things right? Are we doing the right things? Therefore, and as any management layer needs a governance layer on top of it to stay healthy, I&A Governance appeared out of the dark.

But IAG itself turned out not to be an easy task. The sufficiently powerful equipment for data analytics was missing and, more often than not, is still missing today. I&A Intelligence was born - the application of data analytics to the domain of Identity & Access.


Separating into Identity and into Access

While working hard on making Identity & Access Management (IAM) become reality some fine structure was discovered in what had been reluctantly lumped together into one discipline. The equation hence became: IAM = Identity Management (IM) + Access Management (AM).

Identity Management being a genuine Management discipline on its own, is the necessary organisational foundation for many corporate necessities like business automation, fine grained cost controlling, classical disciplines like human resources management and – of course – access management. So access needs identity a solid foundation – but not the other way round.

Hence one can imagine 6 distinct disciplines, as for identity all 3 layers (operations, management and governance) have to be performed, as has it for the access part.

Direction – we need a strategy

Remembering the definition of Governance as ’direction & oversight' let me quickly have a look at the 1st half of the world: direction. Certainly you should have to follow a strategy while directing a whole business towards its future.

This insight is not entirely new and so the procedure of defining a strategy is pretty well understood by now. Strategy development is merely a high level planning process, leading from the current state to some assumed future state. To do this with sufficient rigour, some prerequisites need to be fulfilled.

First you need to have meaningful mission. As for a corporate mission “Earning tons of money” might not be a good enough driving mission, so “Securing the business” would not suffice for Identity & Access. Good news is that nearly every company has started with a clear mission. By the time it may however need some adjustment or even re-invention, enough in each case to keep top management busy for a while.

Second you should now your current “As is” status, as ”if you don't know where you are, every direction might be the right one”. As trivial as this “know thyself” sounds, given the complexity of today's major institutions, you can easily run into the “analysis paralysis”-trap.

And thirdly you should have an idea of what lurks around the corner, the future drivers, influences, trends, new technologies, which may have an impact on your business.

Hence “Strategy Development” can be understood in a narrow and abroad sense, depending on whether the necessary foundation is laid already, or the entire work lies ahead still.

Strategy development - a cyclic process

Strategies often bear the stigma of being fuzzy, general, overambitious or even outright unrealistic. At least they are blamed to talk about a distant future in abstract terms. This perception is not completely wrong and not entirely right. Strategy development follows a cyclic process. And as its goal is to transform an organization from a defined here-and-now state to a specific future state, during this process it deals with abstract and far-off future issues, just to come back to the here-and-now, the cruel dirty world, with change items to be implemented tomorrow.

Expressing it as guidance

Having been perhaps too generously spending 356 words on a well-known corporate discipline like strategy development, I cannot afford the luxury to do the same for the subsequently necessary change activities. Let's assume however, that one fine day the projects will have come to an end, yielding new corporate processes – and altered corporate guidance.
The pyramid of corporate regulatory documents traditionally looks like this:
  1. Strategic level: Policies & Guidelines


    Policies are binding corporate documents, usually issued by top management. They express goals, principles, focal areas and responsibilities. They represent the top level of the documentation pyramid.


    Guidelines like policies are of a high level of abstraction. However they don't come with a binding character.

  2. Managerial level: Procedures & Standards


    Procedures lay out all management controls for a defined problem domain on an essential level. They contain (static) functions & responsibilities and (dynamic) processes.


    They state requirements for generic minimum standards, a choice of good practice examples or a bandwidth of tolerable quality parameters.

  3. Operational level: Specification & work instructions


    The Implementation of controls on a physical level is specified in operational specifications, work flows, specifications, … Techniques, configurations of solutions and organisational processes are documented on this level.

    Work instructions:

    Based on the defining procedures work instructions specify the volatile details like configuration parameters or physical techniques.

Traditionally these documents on each level are written as some kind of narrative to be read and followed by its target group. This group evidently is meant to be made of humans. Automated processors usually are not in scope – however they increasingly need to be.

To let process definitions seamlessly translate into executable workflows, to automatically check human and automated activities against corporate policies, to authorise digital identities (human 'users' or automated processors) dynamically and aware of its context, expressed as rules and attributes (ABAC), much more rigour has to be applied to definition of regulatory documents.

As those documents become the central code, whose rules are executed in an unattended manner they need to be considered as the sensitive core of the entire organisation – and hence protected accordingly against failure, inadvertent or malicious alteration and creeping degradation.

Ok, that enough for now. Next week I will outline how to make policies & guidelines actionable. So please stay tuned.


RBAC first – ABAC next, or what?


Recently, at a customer’s site, I heard an enlightening response to a simple and straightforward question.

The question was: “Why do we implement our access management system according to the old fashioned RBAC model and don’t follow the modern ABAC approach instead?”

The answer came quickly and was as simple: “As we are a large organisation, to go for ABAC would be a step too big for the start. So first let’s implement according to RBAC and later we go on to the ABAC model.”

Figure 1: The (perceived) Evolution of Access control
The answer left me wondering whether there is a logical sequence in which to implement an access model according to the ABAC approach: first RBAC then followed by ABAC? Indeed, while researching literature I found some proposed or perceived evolution paths, like the one illustrated in the graphic above (e.g. here:, also conveying the promising news that XCML support all of these models) here .

However, why couldn’t it be the other way round? Or can’t we have both at the same time, as roles are a good idea. But the dynamic access control, which often comes in the wake of attributes, might be very beneficial as well. What’s about a blended model, having the best of both worlds?

What is RBAC?

Role based access control (RBAC), as defined in the US standard ANSI/INCITS 359-2004, Information Technology, controls all access through roles assigned to users. Each role assigns a collection of permissions to users.

Herby RBAC assumes that, in most applications, permissions needed for an organization’s roles change slowly over time, but users may enter, leave, and change their roles rapidly. RBAC meanwhile is a mature and widely used model for controlling access to corporate information.
To cope with its early limitations, inheritance mechanisms have been introduced, allowing roles to be structured hierarchically. So some roles may inherit permissions from others.

Intuitively roles are understood as functions - or bundles thereof - to be performed within a corporation. Not surprisingly they offer a natural approach to express segregation-of-duty requirements, where no single individual may be assigned all functions for critical operations such as expenditure of funds.

It is evident, that roles are global to a given context by their very nature. Proper operation of RBAC hence requires that roles fall under a single administrative domain or have a consistent definition across multiple domains. In contrast employing distributed role definitions may become challenging.

But not all permission determining dimensions are functional. What is about location, legal entity, customer group, cost centre and the like? Those ‘attributes’ in conjunction with the job function span a multidimensional vector space. A Point in this space defines the package of permissions.

Figure 2: A simple (static) role meta model
The separation of functions & constraints pays off even without complex rules
  • In the (simplest) role meta model …
  • Roles express the function
  • Parameters are used as constraints
  • They combine to several business roles
  • Business roles are defined in pure business terms
  • Business roles must be mapped to entitlements.
  • Entitlements are operations on objects
  • Business roles may be statically generated.
  • They may be determined dynamically at run time.

Of course, if the only tool, you have at hand is a hammer, all the world may look to you as a nail – or a variety of them. And so the inevitable happened and roles, with their functional nature, were abused for the assignment of any bundle of permissions, quickly leading to the well-known role explosion.

Also the static nature of roles is increasingly felt as a severe limitation - in some cases. Where does agility enter the game? Well the context is to blame – and requires dynamic constraints. To make this cryptic statement a bit clearer, let’s take some examples …
  • Device
    The device in use might limit, what someone is allowed to do.
    Some devices like tablets or smartphones might be considered to be less secure than others.
  • Location
    The location the identity is at, when performing an action. Mobile, remote use might be considered less secure than access from within the headquarters.
  • System health status
    The current status of a system based on security scans, update status, and other “health” information, reflecting the attack surface and risk.
  • Authentication strength
    The strength, reliability, trustworthiness of authentications. You might require a certain level of authentication strength to apply. Otherwise you might want to restrict access in a certain way.
  • Mandatory absence
    Traders may not be allowed to trade in their vacation. Mandatory time Away (MTA) is commonly used as a detective / preventive control for sensitive business tasks.
  • Many more
It is evident, that static role models cope badly with such dynamic requirements.

What is ABAC?

To avoid “role explosions” and to provide for a higher agility, several attempts have been made. Likewise recent interest in attribute-based access control (ABAC) suggests that attributes and rules could either replace RBAC or make it more simple and flexible.

The attribute-based access control (ABAC) model to date is not rigorously a defined approach. Its central idea expresses that access can be determined based on various attributes presented by a subject. These contemplations can be traced back to A.H. Karp, H. Haury, and M.H. Davis, “From ABAC to ZBAC: the Evolution of Access Control Models,” tech. reportHPL-2009-30, HP Labs, 21 Feb. 2009).

Hereby rules specify conditions under which access is granted or denied.

For example ...
  • A bank might allow access if the subject is a teller, working during the hours from 7:30 am to 5:00 pm, or the subject is a supervisor or auditor working those same hours who also has management authorization.
  • This approach at first sight appears more flexible than RBAC because it does not require separate roles for relevant sets of subject attributes, and rules can be implemented quickly to accommodate changing needs. The trade-off for this flexibility is the complexity introduced by the high number of cases that must be considered.
Providing attributes from various disparate sources adds an additional task. Attributes may stem from different sources with different reliability resulting in different trust we place in them.

ABAC (sometimes referred to as Policy Based Access Control or PBAC or Claims Based Access Control or CBAC) was proposed as a solution to these new issues.

As it evolved it was also called Risk Adaptive Access Control (RAdAC). As the model and its application are still emerging, there is currently no widely accepted ABAC model as there are for DAC, MAC and RBAC. Although considerable literature has been published, there is no agreement on what ABAC exactly means.

It is however safe to state, that attributes and policies (made of rules) are used in ABAC to derive access decision. As those attributes my change during run time, the ability is assumed to perform these policy decisions at runtime too.
Figure 3: Agility creeps into the model from the increasingly dynamic corporate context


As discussed above, both approaches RBAC and ABAC have their specific advantages and disadvantages. RBAC trades up-front role structuring effort for ease of administration and user permission review, while ABAC makes the reverse trade-off: it is easy to set up, but analysing user permissions can be problematic.

This insight comes less as a surprise, if we start viewing both models as incomplete fragments, just projections of some richer model. And in fact, rarely does any organization use a pure RBAC or ABAC approach. Typically attributes augment or parameterise roles. They can be used independently to assign basic resources to digital identities, which are not linked to functions performed within the organization.

This view supports the strong impression that the discussions of RBAC vs ABAC tend to search for the right answers to the wrong question. It would rather make sense to ask how much R vs. A should be taken to our xBAC model to best serve our needs.


Coming to the above conclusion it is not surprising to find that the ‘inventors’ of RBAC themselves come up with even three different suggestions how to combine RBAC and ABAC.

As D. Richard Kuhn, Edward J. Coyne and Timothy R. Weil, in their article “Adding Attributes to Role-Based Access Control” (IEEE Computer, vol. 43, no. 6 (June, 2010) IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81, pp. 79-81) present, there should be three approaches to handle the relationship between roles and attributes, all retaining some of the administrative and user permission review advantages of RBAC while allowing the access control system to work in a rapidly changing environment:
Figure 4: There are 3 basic models  discussed here to combine RBAC and ABAC
  1. Dynamic roles. Attributes such as time of day are used by a front-end module to determine the subject’s role, retaining a conventional role structure but changing role sets dynamically (R. Fernandez, Enterprise Dynamic Access Control Version 2 Overview, US Space and Naval Warfare Systems Centre, 1 Jan. 2006; http://csrc.nist.gov/rbac/EDACv2overview.pdf). Some implementations of dynamic roles might let the user’s role be fully determined by the front-end attribute engine, while others might use the front end only to select from among a predetermined set of authorized roles.
  2. Attribute-centric. A role name is just one of many attributes. In contrast with conventional RBAC, the role is not a collection of permissions but the name of an attribute called role. This approach’s (IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81) main drawback is the rapid loss of RBAC’s administrative simplicity as more attributes are added. It also suffers from potential problems with ABAC when determining the risk exposure of a particular employee position. However this 2nd scenario could serve as a good approach for a rapid start, generating early results in automatic the assignment of all those permissions, which can be granted without having deeper knowledge of the digital identities job function.
  3. Role-centric. Attributes are added to constrain RBAC. Constraint rules that incorporate attributes can only reduce permissions available to the user not expand them. Some of ABAC’s flexibility is lost because permission sets are still constrained by role, but the system retains the RBAC capability to determine the maximum set of user-obtainable permissions. As an aside, developers explicitly designed the formal model for RBAC, introduced in 1992, to accommodate additional constraints being placed on a role. This approach by the way is the one envisioned as the natural approach by KuppingerCole ).


In a dynamic role meta model …
  • Roles can be created at runtime
  • So can constraints
  • They are rule / attribute pairs
  • Roles & constraints can be deployed dynamically too.
  • Dynamicity is propagated from constraints and/or from functional roles to business roles and authorisations
  • Entitlements and identities remain static at the same time.
Figure 5: Roles and constraints may be created and / or used dynamically

Having said all this, we can safely conclude that sticking with one model in its pure breed will limit our expressive power and lead to suboptimal results. There should be less the question whether we have a preference for the A or the R in the respective xBAC-model. But rather we should decide on how much of each to be introduced at what point in time. Even a combination of the three approaches as mentioned in the above chapter may not lead to model degeneration but would rather have the potential to lead to an optimal model.


  1. D.F. Ferraiolo and D.R. Kuhn (1992) "Role Based Access Control", 15th National Computer Security Conference, October, 1992
  2. M. Blaze, J. Feigenbaum, J. Ioannidis, “The KeyNote Trust-Management System Version 2”, IETF RFC 2704, September 1999
  3. K. Brown, “Exploring Claims-Based Identity
  4. A. Pimlott and O. Kiselyov, “Soutei, a Logic-Based Trust-Management System”, FLOPS 2006, 8th International Symposium on Functional and Logic Programming.,Fuji-Susono, 12 Japan, April 24-26, 2006. Also in Springer's Lecture Notes in Computer Science 3945/2006, pp. 130-145.
  5. D. Richard Kuhn, Edward J. Coyne, Timothy R. Weil, “Adding Attributes to Role-Based Access Control”, IEEE Computer, vol. 43, no. 6 (June, 2010), pp. 79-81

More readings

  1. Anderson, A. 2004. XACML Profile for Role Based Access Control (RBAC).
  2. Anderson, R.J. 2001. Security Engineering: A Guide to Building Dependable Distributed Systems. New York: Wiley Computer Publishing.
  3. Barkley, J.F. (no date). “Workflow Management Employing Role-Based Access Control.” U.S. Patent #6,088,679.
  4. Barkley, J.F. 1995a. “Application Engineering in Health Care.” Second Annual CHIN Summit. Chicago, IL..
  5. Barkley, J.F. 1995b. “Implementing Role-based Access Control Using Object Technology.” First ACM Workshop on Role-Based Access Control.
  6. Barkley, J.F., and A.V. Cincotta. 1998. “Managing Role/Permission Relationships Using Object Access Types.” Third ACM Workshop on Role-Based Access Control, Fairfax, VA.
  7. Barkley, J.F., and A.V. Cincotta. 2001. “Implementation of Role/Group Permission Association Using Object Access Type.” U.S. Patent No. 6,202,066.
  8. Barkley, J.F., A.V. Cincotta, D.F. Ferraiolo, S. Gavrila, and D.R. Kuhn. 1997. “Role-based Access Control for the World Wide Web.” 20th National Computer Security Conference.
  9. Barkley, J.F., D.R. Kuhn, Rosenthal, Skall, and A.V. Cincotta. 1998. “Role-Based Access Control for the Web.” CALS Expo International & 21st Century Commerce 1998: Global Business Solutions for the New Millennium.
  10. Bednarz, J. 2005. “Compliance: Thinking Outside the Sarbox.” Network World. As obtained on 10/31/2008.
  11. Bertino, E. and R. Sandhu. 2005. “Database Security—Concepts, Approaches, and Challenges.” IEEE Transactions on Dependable and Secure Computing 2(1): 2-19.
  12. Bokhari, Z. 2009. Standard & Poor’s Industry Surveys, Computers: Software. (April 23) and company Web sites. U.S. Code 44 (2006). Information Security, § 3532 (b) (1).. Accessed February 5, 2009.
  13. Bureau of Economic Analysis. 2009. “National Income and Product Accounts: Table 5.3.5. Private Fixed Investment by Type.”. Accessed April 14, 2009.
  14. Byrnes, C., Vice-President: Services and Systems Management, The META Group. June 13, 1997. “Security Administration Grows Up.” An analyst report produced for Tivoli, an IBM company.


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 1st have to be authenticated (Are you the one you claim to be?) and 2nd 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)?


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.


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 2nd 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:


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.


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.


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.


Why IAM-Projects fail

7+1 reasons and more to expect

There are several caveats to be aware of up front when starting a major IAM project. These useful hints are driven by experience from projects that went wrong due to some common misconceptions:

1. Sub-optimal assignment of responsibilities

corporate organisation needs a Business Owner

Complexity factors

  • Identity Management is a management task.
  • Identity Management means organising the enterprise.
  • HR could be the natural owner - but often refuses.
  • IT has the implementation capabilities but is not mandated to change the organisation.
  • On the business side methodological and technical knowledge is lacking.

Possible countermeasures

  • Shift the responsibility to the business side.
  • Create a new cross functional function (group) for the doing.

2. Cross-company character

IAM-Projects touch multiple corporate functions

Complexity factors

  • Identity-Management Processes are typically cross-company.
  • There are multiple stakeholders from different corporate levels involved in a project.
  • You need to expect a 3 to 5 times higher communication complexity compared to "normal" IT-projects.
  • IAM-Projects show characteristics of typical Change Management Processes.

Possible countermeasures

  • Strengthen the project management.
  • Add an extra reserve for communication.
  • Insist on a power sponsor for your project.

3. Differing Process maturity

There are no islands of order in an ocean of chaos.

Complexity factors

  • At higher levels of maturity of the management processes (e.g. according to CMMi) the introduction of IAM- processes, -rules, -roles, -policies becomes easier.
  • You can't implement mature IAM-processes in a low maturity process environment.
  • E.g. the top-down definition of roles needs defined processes.

Possible countermeasures

  • Only launch IAM-projects corresponding to the maturity level of the environment.
  • Occasionally just say "no"!

4. Wrong Project scope

An implementation project cannot reorganise the corporation.

Complexity factors

  • Implementation project will have a hard job when having to reorganise the corporation first.
  • Process- and Role-Definitions require their own definition projects before or in parallel to the Implementation.

Possible countermeasures

  • Define separate projects for the Definition of Processes and Roles before or in parallel to the Implementation.

5. Adverse effects of the market consolidation

acquired components don't necessarily combine to Suites

Complexity factors

  • Mergers & Acquisitions often lead to less compatible product collections.
  • The software of acquired companies is often not supported sufficiently.
  • It may take a long while, until components fit together as promised.

Possible countermeasures

  • Only a Pilot installation under real world conditions leads to the necessary evidence for a product selection.

6. Non-availability of domain knowledge specialists

persons with business domain knowledge are rare creatures

Complexity factors

  • The availability of specialists with domain knowledge often turns out to be the bottle neck in role- und process definitions.
  • Their involvement is essential for the requirements definition and the QA.
  • Waiting times (for specialists) are driving the overall effort.
  • While in projects they tend to disappear.

Possible countermeasures

  • Assign the project responsibility to the business departments.
  • Think of splitting projects into business definition and an implementation part.

7. Too deep vertical integration

don't try to reinvent the wheel

Complexity factors

  • Only a fraction of the overall IAM-Processes is really enterprise specific.
  • The adoption of processes and / or Roles from generic Models may speed up projects.
  • Not always it is a good idea to start with a blank sheet of paper.

Possible countermeasures

  • Ask your integration partner or consultant for consolidated models containing his experience.
  • Participate in Standardisation initiatives (like GenericIAM.org).

8. Technical risks - they still exist

Technology often is more of marketing than reality

Complexity factors

  • IAM-SW-Suites are complex and often not easy to handle.
  • Without implementation experience in exactly the required environment risk of failure is high.
  • "Minor" changes of the version number sometimes cover oft complete new developments.
  • The support Matrix of environment components vs. versions often is only sparsely populated.
  • Forced replacement of infrastructure components leads to higher effort.

Possible countermeasures

  • Always test selected software in a pilot run before deployment.
  • Only choose integration partners with true product experience.


apply & approve

Lately - well it is some four months ago already - I posted a simple model of the AM maintenance processes. Not covered at that time were the processes which lead to an assignment of roles to persons, respectively their digital identities - the mere act of authorization.

We still view this world on the essential level (see
Modeling fundamentals). So as long as we just model the essence of systems we (still) need not to bother with such non-trivial artifacts like provisioning the business decision to the target systems. Those things will inevitably come later when we will be forced to step down from essential heaven to the cruel & dirty physical world.

Maintenance of "authorization"

Apply - approve - grant or revoke can in principle be understood as the maintenance processes (as in how to find roles) for the object "authorization". There may be other designations for this object like "assignment" or "essential account". In order to optimize the communication with your in-house or outside clients you may choose a more suitable name, if you like.

"authorization" as a derived object

Ok, as a maintenance process we would expect the CRUD crowd again: create - read - update & delete. However, "authorization" is not one of the fundamental objects. In fact it is a derived or relationship object and mostly consists of references to its constructing elements: "identity" and "business role". And this is where the necessity for an approval comes in.

Finding approvers

Why do we need approvals here and not before; when we considered the fundamental objects? The answer is: because the object "authorization" does not own all of its attributes. But instead references to other objects (identity and business role) attributes and their attributes. As a polite object it should ask for permission before doing so.

So, the rule we like to follow here is: "if one of the attributes of an object represents a reference to another object, this objects’ owner has to consent his object’s use." So on one side the object is the identity: Its "owner" is its superior.

On the other side of the equation there is the business role. Having a closer look to it however reveals that the business role itself represents a relationship. So we have to go even further. The "business role" is the intersection of the privilege determining dimensions. These dimensions are first of all the "functional role" and second all those which are subsumed under "constraints". These depend on the organization in focus, e.g. region, organizational unit, customer group, contract type. As an example we determine the permissions of a contract administrator in the US, in the headquarters, for whole sale customers if he is a fixed term employee. So the "business role" primarily consists of references to the "functional role", the various "constraints" and the assigned "permissions".

"Every object has an owner" I once (2010-08-17:
objects, subjects & actions) stated in my BLOG. And I went on, that owners are prime candidates for actors to act on their objects. At least when it comes to the approval of requests to access objects, it is up to the owners to decide (unless the delegate it to clerks).

Who now are the owners to ask for their approval? For the "functional role" as well as for the various "constraints" it should be a "business architect" or - even better - a "process owner". For the set of "permissions" there should be an owner of the "information object" be defined. Often this position is known as the "data owner".

So these are the authorities to approve the formation of a business role. As the "business role" per se is neither sensitive nor does it contain much substantial information but rather references to other objects, its use may be pre-approved by policy. The same is true for two of its referenced objects: "functional role" and "constraint".

But for the "Information objects" things are different. Information objects always need some level of protection. They may be classified due to their level of sensitivity (separately determined in the categories authenticity, availability, confidentiality and integrity) into levels like low, medium, high and very high.

Whereas in cases of low protection needs access to the resources may be pre-approved via policy information objects attributed with high protection needs require the case-by-case approval of the owner (or his delegate).

So at the end of this long story it turns out, that there will be two approvers during privilege assignment to a digital identity: the superior and the information owner.

Process variations

There are several processes for granting authorization found to be in use.

  1. Grant authorization
  2. Withdraw authorization
  3. Deactivate authorization
  4. Reactivate authorization
  5. Instantaneous withdraw authorization
  6. Change of position
  7. Deploy temporarily
The most common are grant and revoke (withdraw). But as authorization should be granted with and end-date of its validity set while approval, the reverse action can be done as well: deactivate an authorization for a given period of time (e.g. planned absence). A reactivation process then cares for the case when deactivation period is meant to end ahead of schedule. Temporary deployments offer more complex cases (to fill an own BLOG post) as usually no clear cut can be done.

A process which appears quite often is something like "Instantaneously withdraw authorization". However in an essential model (remember, we have perfect technology!) it simply collapses with "Withdraw authorization". Only if by technical restrictions it becomes necessary to be a bit faster than in the standard process, a separate (physical) process is justified.

But what to do, if an individual changes its position within a corporation?  This process is often explained as a combination of a preceding revocation followed by a subsequent assignment of new privileges (grant). But this picture seems not to reflect reality properly. Quite often there is the necessity of an overlap of privileges of the old position and those for the new position - unless they are in conflict with each other’s. So the change process still may be a combination of revoke and grant - but rather running in parallel instead of being executed sequentially. However as an invariant to the parallel execution of both (sub-) processes the integrity (e.g. being free of SoD conflicts) needs to be checked after each step in the out-phasing of the old and in-phasing of the new position’s roles.

Triggering events

And what are the triggering events? Well, in general processes are triggered by one of the following events.
  1. created by an subject,
  2. triggered by time,
  3. fired by embedding business processes,
  4. fired by state transitions.
The 4th one can be debated, as it can be argued, that a state transition only occurs in embedding processes.

Process composition: grant authorization

"Grant authorization" can be imagined as being composed of the following activities:

  1. apply
    1. Select identity
      Usually either the applicant himself or one of this subordinates.
    2. Select business roles(s)
      1st the functional roles should be selected, 2nd constraints should be assigned (based on rules) and / or selected. Rules may restrict the focus of the selectable roles.
    3. Check Validity
      Validity is an invariant - it should be checked during each change - even when withdrawing roles. If rules are violated the choice could be disabled (strict rules) or an alert could be raised to allow for branching into a resolving (sub-) process. SoD rules for example can be imposed as a strong recommendation ("to be separated in general"), as a mandatory requirement or even with special emphasis ("to be separated up to the C-level"). At least in case of a mandatory SoD conflict a compensating control can be implemented to restore validity. But getting compensating controls approved may be a lengthy process, return in the "go" / "no go" after some days only - during which the application will be pending. When withdrawing roles an implemented compensating control may no longer become necessary. That’s why the validity check should be invoked in this case too. So "check validity" may look innocent. Nevertheless it introduces the bulk of organizational complexity to this activity.
  2. approve
    1. Usually the choice which has been made has to be approved.
    2. It is possible however to pre-approve it via a policy, if appropriate.
    3. Typical approvers are the superior of the identity (for contractors this may be the contracting counterparty) and the information object owner.
    4. In case of unresolvable SoD conflict leads to compensating controls, more approvers can be involved.
    5. Usually a time limit is set after which an escalation is triggered.
    6. The approver has to name a deputy in case he is unable to perform the task himself.
Well, that's certainly not all. It is just one important process. But it is enough for today. More to be seen here soon.


How to find roles

Not, many of you may have read this Blog post before here, posted at Sat. June 30th to the GenericIAM Blog. Here I made the statement that "Roles are the organization". You may read through this short contribution before you go on listening to me.

And please always feel free to come up with a different opinion or with some critique as did
one BLOG author - who unfortunately did not completely get the point.

Well, maybe I overstated my point there. More will be necessary to describe how an organization is expressed in roles.

What are roles?

When we talk about roles they are most commonly understood as functional roles. That means bundled corporate functions. So if you have a functional enterprise model (as opposed to an object oriented one) at hand, you may just select the appropriate functions, add them the functional role and give it a meaningful name. Yes, that's all.

Will it be enough to use these roles for granting access? Remember this is the idea behind Role Based Access Control (RBAC) after all. No, it will not.

But how do we get there? Ok, let's take a step back and consider the organization and all the objects around there and see what we can collect to finally have all determining information at had to define privileges.

What is the organization?

Figure 1: Roles link process to resources
Processes - Roles - Rules - they express the abstract Organization. They form a generic template not yet populated with real people and still without individual customers, contracts and obligations. So we are on the class level still - not yet their physical incarnation. As mentioned - it's the abstract organization.

So let's follow a top-down modelling approach:
  • Business processes express the organization's dynamic behavior. Often they are the starting point. They are best understood and perceived as been the essence of the corporation - something to excel or to fail in.
  • Processes themselves are made up of elementary actions which can be understood as some atomic activity - what one person does at a time in one location.
  • These actions are performed by someone - not yet individual persons but on class level roles instead. So here they come into play - the roles, functional roles still.
  • To be able to perform the singular actions these functional roles need appropriate access to resources. The functions are bound to resources. They are being "localized".
  • Constraints drive this localization. They further restrict the roles access to certain subclasses in order to reflect the real world's needs. Those constraints express the privilege determining information dimensions like organizational unit, region, contract type, customer group and more. The resulting "business role" finally is the one which can be used for access control as it defines the intended privileges - still defined in business terms.
So processes and roles can't be modeled independently - without being incomplete. But only by taking constraints into account makes the model sufficiently determined to derive privileges for information object access from functional roles.
This picture to my opinion is more straight forward and easier to comprehend than the so called Stanford model:
Figure 2: Stanford model enterprise and system abstractions. McRae, R., The Stanford Model for Access Control Administration, Stanford, University, 2000 (unpublished but cited by Ferraiolo, D., and R. Kuhn).
Obviously role finding requires good and - even more important - explicitly documented knowledge of the business domain (best to be expressed in a formal enterprise model), some experience in related business modelling areas and a sound portion of intuition.

While existing, defined and documented business processes are an excellent starting point for successful role engineering, they still don't represent the most fundamental core objects of a corporation. Even more fundamental to an organization are the essential persistent (non-transient) objects:
The static IAM objects

The static IAM-Objects

Anchor point is the business role - ok, but let's start at the beginning - always a good idea. In this chapter I might reiterate ideas of earlier postings. However - as insight has progressed - my explanations may get a slightly different flavor than before. In case you feel bored just skip this chapter. But be warned - as virginal ideas are rare in general - you might encounter the usual suspects.
The identity

Identity: the digital identity is the digital representation of the individual, which has a defined relationship to the corporation. It is stored and maintained as long as the as long as the interest in this relationship lasts and no legal or regulatory requirements restrict its use.
The functional role

Functional role: a bundle made up of business functions as defined in a functional enterprise model which represents the tasks which have to be performed. So the functional role just specifies functions to be performed. The functional role can be understood as a projection to the enterprise model. In case the enterprise model is purely functional (in contrast to object oriented), the functional role just lists corporate functions. It doesn't contain any hints on how to grant access to information objects or applications. Even more; only in special cases you may be able to derive the affected information objects they are acting on from the role's names. Note: This applies if you have a functional enterprise model at hand. This is most commonly the case. Situation might look slightly different if there is an object oriented (means class based) enterprise model available.
The constraint

Constraint: constraints narrow the focus of a functional role. Well known examples are defined authorisation levels, to limit transactions by a maximum value (value authorisation) or to limit the scope of activity to certain organisational units or regions (structural authorisation). Value authorisations in turn can be further split into direct and indirect value authorisations. For example the permission to close contracts or to grant discounts up to a certain (direct) limit can be expressed as an amount of money. On the other hand there can be also maximum values defined for parameters (maximal validity period, or maximum mileage - both of a leasing contract) which can be converted to an amount of money after some form of transformation only (indirect). Furthermore it is rather common, that the contract type (employee, contractor, interim manager …) might lead to further restrictions of a role's full privileges. More types Constraints are possible of course and more discussion on this object is necessary I fear.
The permission

Permission: The elementary object of access management is the elementary privilege (permission). According to the RBAC standard it is defined as operation on objects. In case the privileges cannot be defined via access to information objects, privileges alternatively can be defined the access to systems.
The business role

Business role: In this model the business role is the central structuring element. It expresses all information necessary for the (technical) privilege assignment on business level. But you could also call it the localized Role.  By the introduction of the business role the purely functionally defined functional roles are finally bound to the specific Information objects (or alternatively systems). This can be done by linking directly to elementary permissions. (In some cases, when applications or systems offer some kind of roles already, the business role may link to these 'system roles'. But their introduction needs its own discussion) Here the constraints unfold their by definition restricting effect. If you manage to bind the information objects strictly rule driven to the functional roles you may not need to store the business roles. In this (lucky) case they can be considered as purely virtual (transient) objects. In most - real world - cases however we have to consider them as static (persistent) objects. You may imagine the business role as a triple of keys - and not much more. Those are the keys of the functional role it points to, the constraint, if there is any and finally the permission which is used.
The authorisation

Authorization: when the business role is assigned to a digital identity the object authorization is created. By this assignment the very act of the role based privilege assignment is done. In reality the identity is assigned several business roles to define the planned information object use. All access information is stored in one or more authorization objects per identity representing the total use of all relevant information objects. Note: In this context the object authorization is often called user. But  not the using person is meant but the relation expressing the use.

Processes of model maintenance

Those were the fundamental objects (again). But how to get the strange animals called roles now? Well, if you are asking for processes I finally have to deliver processes. Let's not forget: this is what GenericIAM is about, generic processes of the identity & access management.

So which processes do we need at first? Model maintenance means the maintenance of all of its objects. So we obviously may expect …
  • Maintain functional role,
  • Maintain constraint,
  • Maintain permission and
  • Maintain business role.

Maintain functional role:

Due to the high overlap with job descriptions, the functional roles can be considered as the natural starting point for a role based privilege assignment.

If requirements for separations of duties (SoD) are defined, functional roles are the appropriate object to check for violations as separations of duties are defined purely functionally as well. If the SoD conflicts cannot be resolved otherwise the implementation of mitigating actions (aka compensating controls) might become necessary. This SoD check becomes necessary when functional roles are either edited or combined.

The process of functional role maintenance is triggered by the initial creation of new tasks or change of existing ones, e.g. caused by changes of business processes. In these cases creations or changes of functional roles might become necessary.

Owner of this process should be some kind of business architect. To model functional roles he clarifies, which tasks within a business process are planned. By following along its elementary activities (what a person does at in one step at one location) he lists the functions according to the enterprise model that are necessary to run this activity.

If SoD obligations have to be met the resulting functional roles have to be checked for segregation of duties conflicts. If present such conflicts can be either removed by remodeling or their inherent risk be reduced by implementation of compensating controls.

Maintain constraint:

Constraints are used to further restrict the functions acquired via the assignment of a functional role. The definition of constraints is a risk mitigating measure, which can be implemented additionally or alternatively to other controls (four eyes principle, separation of duties …) to function as a "compensating control".
The process can be invoked by "maintain functional roles" as it narrows their focus. It should be owned by the above before mentioned business architect too.
The necessity for the definition of constraints is originated by business departments, risk management or - if appointed - a business architect. Together they determine the scope limitation or the maximum authorization level.

Maintain business role

As mentioned above in this model the business role is the central element of access management. By assigning a business role to a person's digital identity they are granted their privileges. This assignment is stored in the authorization object. The business role is therefore the static projection of the functional role to certain information objects while applying some constraints.

In a 1st step a functional role is created as an empty container. It is given a meaningful name expressing the purpose of this role. Alternatively an existing functional role is selected from the enterprises pool of functional roles.

In a 2nd step corporate functions taken from a functional enterprise model are assigned to the functional roles. Note: in order to comply with the principle of least privilege (PoLP) only a minimum set of corporate functions should be selected in this step. Obviously for this purpose the functional enterprise model needs to be sufficiently fine grained. If necessary at this stage you may want to change functional roles or create new ones (maintain functional role).

In a 3rd step the constraints are applied to the
roles. This action obviously increases their number. A check for violations of segregation of duties requirements may be appropriate here as well.

In a 4th step permissions are assigned to the
roles. Obviously here the respective Information owners need to get involved. Remember: Permissions are defined as operations on information objects. In cases where no information objects are defined but systems or applications in place instead you may need to consider permissions as 'operations on applications'. If necessary those permissions need to be changed or created (using the process "maintain permission").

role can still be understood on the business level. Not surprisingly we suggest the business architect again to be the appropriate owner. He will not be able to do this job alone. He might need the support of the information object owner / application or system architect.

Maintain permission:

What's about the permission? Doesn't it need to be maintained as well? Yes it does. However most often this is done in a different system: In the target systems rather than in a central AM system. While modeling these processes on the essential level however we need not to deal with these system boundaries.

Of course to decide which ones of the possible permissions to be exposed to the business oriented role modelers is a business decision. On the other hand only those permissions can be exposed, which are offered by the underlying systems. Clearly this is the domain of the information object owner / application or system architect.

Moreover in those cases where the underlying systems offer their own role models and especially in situations when roles on system level are in use by an implemented access management already application- or system roles can be squeezed in between the permission on the bottom level and the 
business role

in the center. As in the essential model there is no reason for the introduction of an application role, some extra discussion will be required in order to find a set of rules for crafting good application roles - but elsewhere.

Applying and granting

Those were just the (simple) processes of model maintenance. Perhaps I should provide an online tool prototype to demonstrate how it may work in reality. Still missing are the processes which lead to an assignment of roles to persons respectively their digital identities. Granting access to Information objects by assigning roles to individuals is not trivial as it more often than not involves some carefully crafted workflow. These processes are not yet covered here. They will follow in my next post. So please stay tuned.