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.

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 4^th 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)
   1^st the functional roles should be selected, 2^nd 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.