GenericIAM.org BLOG

apply & approve

2012-02-09T14:31:00.001+01:00

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.

We still view this world on the essential level (see Modelling fundamentals).So as long as we just model the essence of systems we (still) need not to bother with such on-trivial artefacts 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 "use"

Apply - approve - grant or revoke can in principle be understood as the maintenance processes (as in how to find roles) for the object "use". 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.

"Use" as a derived object

Ok, as a maintenance process we would expect the CRUD crowd again: create - read - update & delete. However, "use" 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 "use" 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 organisation in focus, e.g. region, organisation 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 authorisation found to be in use.

Grant authorisation
Withdraw authorisation
Deactivate authorisation
Reactivate authorisation
Instantaneous withdraw authorisation
Change of position
Deploy temporarily

The most common are grant and revoke (withdraw). But as authorisation should be granted with and end-date of its validity set while approval, the reverse action can be done as well: deactivate an authorisation 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 authorisation". However in an essential model (remember, we have perfect technology!) it simply collapses with "Withdraw authorisation". 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.

created by an subject,
triggered by time,
fired by embedding business processes,
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 authorisation

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

apply

Select identity
Usually either the applicant himself or one of this subordinates.
Select business roles(s)
1^st the functional roles should be selected, 2^ndConstraints should be assigned (based on rules) and / or selected. Rules may restrict the focus of the selectable roles.
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 organisational complexity to this activity.

approve

Usually the choice which has been made has to be approved.
It is possible however to pre-approve it via a policy, if appropriate.
Typical approvers are the superior of the identity (for contractors this may be the contracting counterparty) and the information object owner.
In case of unresolvable SoD conflict leads to compensating controls, more approvers can be involved.
Usually a time limit is set after which an escalation is triggered.
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

2011-09-18T12:05:00.000+02:00

Not, many of you may have read this Blog post before here which I had posted at Sat. June 30^th to the GenericIAM Blog. Here I made the statement that "Roles are the organisation". 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 organisation 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 organisation 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 organisation?

Figure 1: Roles link process to resources

Processes - Roles - Rules - they express the abstract Organisation. 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 organisation.

So let's follow a top-down modelling approach:

Business processes express the organisation's dynamic behaviour. 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 "localised".

Constraints drive this localisation. 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 organisational 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 modelled 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 organisation 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 flavour 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.

	*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.
	*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.
	*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.
	*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.
	*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 too 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.
	*Use: when the business role* is assigned to a digital identity the object use 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 use objects per identity representing the total use of all relevant information objects. Note: In this context the object use 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 compensating controls might become necessary. This SoD check becomes necessary when functional roles are either edited or combined.

The process 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 separation of duties conflicts. If present such conflicts can be either removed by remodelling 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 authorisation 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 use object. The business role is therefore the static projection of the functional role to certain information objects while applying some constraints (e.g. authorisation levels).

In a 1^st 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 2^nd 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 3^rd step the constraints are applied to the business roles. This action obviously increases their number. A check for violations of separation of duties requirements may be appropriate here as well.

In a 4^th step permissions are assigned to the business 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").

The business 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 IAM system. While modelling these processes on the essential level however we need not to deal with these system boundaries.

This process no longer is located on the business layer. Of course to decide which ones of the possible permissions to be exposed to the business oriented role modellers 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 centre. 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.

essential IM processes

2011-06-21T10:36:00.013+02:00

If we restrict our considerations to essential processes (see Modelling fundamentals) there are mainly the identity maintenance processes to be taken into account. Only when we (later) extend our view to the physical implementation processes like provisioning, reconfirmation (re-certification), format transformation, reconciliation among different data storages and the like come into play.

The first and most fundamental object to be considered of course it the digital identity or just identity. Under the assumption, that the organisation and an individual's contract relationship with the organisation is modelled elsewhere (outside of the IM and the AM) just the functional role (business role) and the constraint are left to be taken into account.

There is probably not much left to be said about the digital identity as I devoted an own BLOG post to it here (http://genericiam.blogspot.com/2010/06/identity.html) nearly one year ago.

But what's about the business role? I also called it - perhaps more straightforward - the functional role. It just expresses the functions out of the functional (static) business model which are bundled in the functional role. I will probably dedicate one future post to the way how to find functional roles.

And there the strange remaining object called constraint. What's that? In this object we collect all additional constraining and determining information like authorisation limits, organisational unit (OU), region, contract type (fixed term employee, interim manager, contractor, …) or the like. This information is certainly necessary. Only if it is wise to stuff them all into one object and calling it constraint is left to the modeller's discretion to decide. For now and for the sake of simplicity I will not split it off into its probable components but leave it untouched.

How to derive processes now? Well, obviously we need some maintenance processes, the CRUD processes (create, read, update & delete). But it all starts with an event. Otherwise there will never be a need to start a process.

For the creation the triggering event is the very moment when an individual starts a relationship with the organisation. So whenever an individual enters the enterprise ecosystem 1^st time its digital identity is created.

This should be done regardless if it is a user or not as being a user represents a class of roles already.

As an example the activity employee.create is among the 1^st steps of an on-boarding process within HR. The equivalent is true for CRM, PRM & IAM.

The digital identity hereby is the individual's digital sibling. Its lifetime is determined by the lifetime of the enterprises interest in it and / or by legal or regulatory requirements.

The digital identity is global and unique within the enterprise ecosystem during its life span - or the identities' space-time-continuum, if you prefer science fiction slang. It just carries the minimal necessary set of identifying attributes.

So 3 fundamental business process groups remain for now which are tied to the digital identity:

on-boarding,

off-boarding &

change processes

They are split of by the type of the digital identity.

These processes differ slightly by the type of digital identity to reflect the difference of the underlying relationship between the organisation and the individual.

How to find IAM processes

2011-06-13T17:21:00.008+02:00

Just recently I made an eye opening experience. While delivering experts advice to a customer in a large IAM project I was asked if I could confirm that the set of IAM process descriptions that was delivered by a colleague of mine was correct, complete and compelling.

Hmm, my colleague is an experienced practitioner. He did this job several times before. He knew what he did. I trust his expertise. So I asked him how he derived them.

"Well I just know that you need these processes. And taking into account the special situation at this customer's site this is the most reasonable result" he argued.

"But they couldn't have appeared from nowhere. There must be a convincing and compelling way to rigorously derive them from the situation we are in" my customer replied.

This was déjà vu. Here it was again - the demand for a generic set of processes for the Identity- & Access Management. So I felt we finally should come up with an answer. And I tried. It goes like that "

First step is getting some order into the seemingly unlimited number of possible IAM processes by grouping them. The Processes of the Identity Management " not surprisingly - may be grouped in several ways. Her I propose the following sequence:

into Identity Management & Access Management
into operational and managerial processes
into essential and physical processes

1. Separating Identity Management from Access Management

Identity management has a justification sui generis. It needs not to be regarded as an appendix of security management or just the precondition for Access Management.

Access management - of course - can be and should be built on top of Identity management.

The key question however is where to draw the line between IM and AM.

The digital identity, i.e. the object "identity" clearly is in scope of IM. Out of scope of IM and of AM on the other hand are the objects "organisation", "contract type" and "contract". They should be modelled elsewhere in the enterprise model.

But what's about the business role? It defines the functions an identity is meant to perform in relation to the organisation. And defining the relationship should be still considered as a part of the IM. To my opinion it is more safely located in the IM than in the AM.

2. Subdividing into operational and managerial processes

1^st rule: keep processes short: "the best way to manage workflow is to avoid it"
Operational processes tend to follow this rule.
However in the back office they tend to grow ever longer.
Regulation, compliance issues and security concerns are the drivers.
There are just a few operational AM processes: identify, authenticate and authorise
IM processes are purely managerial by their nature.
There will hardly be any strategic IAM processes found ever.
The bulk of the processes are managerial by their very nature.

3. Order by essential and physical processes

Follow the rule: essential system 1^st − physical ring 2^nd. Meaning you start with the stable essential core of processes. And only if this set is complete, they are followed by the more volatile physical ring.

Hereby essential processes …

represent the business' intended behaviour.
They can be identified assuming "perfect technology"
They need not to care for transport, translation or audit activities.
They are implementation independent.
They form a durable core of the business.
They only change if business changes
example: administer and use the essential business functionality

Whereas physical processes …

are introduced to deal with the imperfect outside world.
Here transport, translation & audit processes are introduced.
Physical processes are implementation dependent.
They are more volatile and subject to frequent change.
When re-implemented the physical ring will be different while the essential core may stay unchanged.
example: integrate, transport, transform and "provision" to deal with the "cruel dirty world" outside.

In my next post I will follow my own recipe by applying it to the Identity Management (IM) first. This should be the easy part - with harder parts to come.

Objects of the corporation - slightly revised

2011-06-10T17:38:00.004+02:00

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 form this model.

Everything starts with an agreement …

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

Let’s state therefore: the identity has closed a contract with the organisation, 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 organisation. 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 business role.

The business 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 in order to bind it to specific permissions. The result is stored in the localised business role. There are of course many more localised business roles than business roles, accessing different incarnations of the same information object type.

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

… and ends up in a user.

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

Identity specific constraints may be specified in additional agreements and applied to the user. For example the amount of money a bank clerk is allowed to sign a credit contract for may be limited. Or the authorisation to purchase material may be limited to a specific organisational unit.

Incompetence

2011-03-10T22:31:00.003+01:00

This post will be essentially in German as it deals with some German language idiosyncrasies. Although I have the strong and irrefutable impression, that we do have this cognitive dissonance in the English language universe as well I would like to leave it to a more competent person to comment on the confusing use of the word competence.

Die junge Disziplin des Identity- & Access Managements (IAM) bringt Welten zusammen. Nein, ich will nicht schon wieder auf dem Punkt hinaus, dass diese häufig der IT zugeschobene Aufgabe rein organisatorischen Charakter hat. Organisation und Personal allerdings lebten bisher offensichtlich ebenfalls in verschiedenen Welten. Erkennbar wird das an der Kompetenz.

Ich habe mich – bevor ich mich daran gemacht hatte, diese Zeilen zu schreiben - gefragt, ob ich kompetent genug bin, über die Kompetenz und ihre schillernde und verwirrende Verwendung in Unternehmen zu schreiben. Aber wenn es niemand sonst tut, will ich mich gerne opfern.

Habt Ihr schon einmal Stelleanzeigen gelesen? Sicher nur aus Versehen und nebenbei. Denn ein wirklicher Crack lässt sich ansprechen und sucht nicht in formelhaft gestalteten Angeboten. Da ist dann, wenn Techniker gesucht werden, immer wieder die Rede davon, dass sie bitte schön auch die nötige „Sozialkompetenz“ mitbringen mögen. Das will uns sagen, dass sie die Fähigkeit haben sollen, dem Gegner ins Auge zu sehen und mit ihm eine mehr oder weniger zivilisierte Debatte führen zu können. Darüber dürfen dann aber andere Kompetenzen nicht zu kurz kommen, etwa die vorausgesetzte Basiskompetenz, die Fachkompetenz, formale, hierarchische und soziokulturelle Kompetenzen.

Ganz anders die Orgs (nein nicht Orks!), der Personenkreis also, der sich mit der Organisation von Unternehmen befasst – so es ihn denn wirklich gibt: Hier meint Kompetenz die mit einer bestimmten Stelle verbundenen Berechtigungen und Pflichten. „Haben sie überhaupt die Kompetenz, einen Bürodrucker zu bestellen?“ oder „Da hat der Kollege Meier seinen Kompetenzrahmen mal wieder voll aus geschöpft!“.

Während Personal also vom Können spricht, reden die Orgs vom Dürfen – und beide verwenden dabei ein- und dasselbe Wort. Wie ist das eigentlich in der übrigen Welt – da draußen jenseits der Büromauern? Befragen wir doch einmal die Weißheit der Massen: Wikipedia sagt uns: „Kompetenz (lateinisch competere: zusammentreffen, ausreichen, zu etwas fähig sein) steht für:

• Fähigkeit, Handlungskompetenz (beruflich)

• Fähigkeiten und Fertigkeiten allgemein (Psychologie),

• Fähigkeiten und Fertigkeiten (Pädagogik)

• Sprachwissen im Gegensatz zum Sprachkönnen (Sprachwissenschaft),

• Fähigkeit von Zellen, außerhalb der Zelle vorliegende DNA aufzunehmen (Mikrobiologie),

• die mit einer bestimmten Stelle verbundenen Berechtigungen und Pflichten (Organisation),

• Zuständigkeit von Behörden oder Gerichten (Verwaltung)

Alle sind sich einig – nur Organisation und Verwaltung fallen aus dem Rahmen. Und das soll gut gehen? Na ja bisher konnte man einander ja fein aus dem Weg gehen. Aber IAM lässt nun wieder zusammen wachsen, was zusammen gehört. Personal und Organisation müssen ertmalig miteinander reden und sich sogar auf eine gemeinsame Sprachregelung einigen.

Und hier kommt es zum clash of cultures. Wir kennen doch den alten Konflikt um Rollen und Berechtigungen. Da gibt es das Lager das meint, eine direkte Berechtigungsvergabe an Personen sei out. Erst müsse man die Rolle definieren, die sie im organisatorischen Ablauf innehat. Die Rolle drückt aus, was sie zu tun hat und muss folglich mit den notwendigen Rechten ausgestattet sein. Dann muss man dem Individuum – am besten im Anstellungsvertrag – nur noch die Rolle zuweisen und alles ist paletti.

Das war gut gemeint – aber nur die halbe Wahrheit. Neben der (fachlichen) Rolle bestimmen noch weitere Dimensionen (durchaus orthogonal zu verstehen) die Zuweisung von Rechten: Region, Nation, Organisationseinheit, Vertragsart, Mandat und ggf. Weitere. Das sind alles Beschränkungen (constraints), die die über die Rolle vergebenen Berechtigungen weiter einschränken. Und hier kommt dann auch jene ominöse Kompetenz ins Spiel.

Was ist damit gemeint? Stellt Euch vor, ein Kreditsachbearbeiter, hat das Mandat Kredite bis zur Höhe von 500.000 Euro zu vergeben. Bis zu einer Höhe von 2 Mio. darf es sein Chef, weil der die ganze Kreditabteilung leitet und darüber muss der Gesamtvorstand entscheiden. Das ist nicht unrealistisch – so etwas gibt es. Und dieser Verfügungsrahmen wird dann mit Kompetenz bezeichnet.

Wenn wir nun die Skills der Rolle Kreditsachbearbeiter definieren wollen und für ihn eine gewisse Fachkompetenz vorschreiben, damit die Personalabteilung die Stelle richtig ausschreiben und besetzen kann – dann haben wir den Salat.

Kompetenz ist also ein ganz blödes Wort – zumindest eine höchst unglückliche Wahl.

Was aber dann dafür nehmen? Schließlich gehören treffende Bezeichnungen zur Kernkompetenz eines Modellierers. Also ich bin für Mandat, oder doch Befugnis? – Was meint Ihr?

Modelling fundamentals

2010-08-22T11:07:00.004+02:00

I once mentioned, that follow the essential systems modelling (esm) principles. As not everybody necessarily will be aware of what this term is about I feel obliged to explain it here.

The Essential Systems Modelling Methodology was defined and applied by Stephen M. McMenamin and John F. Palmer back in the year 1984. It was published in a book surprisingly called essential systems analysis (McMenamin, S. & Palmer, J., Essential Systems Analysis, Yourdon Press Prentice Hall, Englewood Cliffs, NJ, 1984.).

McMenamin & Palmer use an event-oriented approach to process modelling. Their purpose is to identify the "essential (elementary or atomic) processes" being performed and their relationships to the events that drive the business. According to Steve McMenamin and John Palmer essential systems can be detected by the following gedankenexperiment …

"If we had perfect implementation technology (e.g., a computer with infinite speed, unlimited memory, transparent interface, no failures, and no cost), which of the requirements would still need to be stated?"
Every requirement that is still necessary in spite perfect technology is an essential requirement.

The prime purpose of esm is to remove legacy implementation artefacts from the model in order to prevent them from influencing future models. And this ability is exactely my motivation why I want to present this methodology here. In the 1^st attempt of the GenericIAM community to derive a generic process model from existing implemented physical models turned out to be surprisingly difficult; in fact it terribly failed. Or as I stated earlier: In fact it turned out, that especially the most experienced practitioners faced difficulties in getting to the next layer of abstraction.

How to derive the target implementation model in a 4-step Process

McMenamin and Palmer recommend to follow a 4-step specification process:

Analysis of the current system

build a model of the actual implementation of the current system.
This is the physical system like it is implemented in reality - the current physical system.

Analysis of the fundamental concepts of the current system:

Deriving of the essence out of the current system.
All implementation specific artefacts are removed in this step.
Using "perfect technology" as the guiding principle.
The result is the current essential system.

Include new requirements into the essential model:

Build the new essential model by adding new requirements.
This model represents all functional requirements.
Ideally it is still free of any design- and implementation consideration.
The result is the new essential system.

Design the new physical model:

Build the implementation model of the new system.
The result is the new physical system.

Finding the essence by this modelling cycle removes implementation artefacts leaving us with the pure functional essence.

The 3rd step in this approach is represents the core of the requirements definition. Here the essential business requirements are documented stating what has to be implemented without defining how it will be done.

This separation enables us to implement the same unchanged essential system using different target technologies. Even when using the same technology maintaining the essential model may turn out to be very helpful. When significant changed are applied to the essential (=functional) model the optimal new physical model may be implemented by a considerably different design that the current physical model.

Avoiding technical "folklore" by assuming "perfect technology"

The assumption of perfect technology leads to the following model characteristics:

Inside the system there are neither errors nor processing or waiting times.
No audit-, translation- or transport processes are necessary.
But the environment of the system is considered as imperfect - as is.
Along the systems boundary a ring of audit-, translation- and transport processes connects to this real world - the physical ring.

There are more rules, which help us composing the essential systems model, are:

Essential Processes may be triggered by an external or a time event.
Fundamental essential processes yield an externally useful result.
Administrative essential Processes store their results in an essential store to be used by a fundamental essential process.
Essential Processes communicate asynchronously via essential stores - they are time decoupled.
Essential processes may be expanded to form nested essential models on a lower layer; essential models in turn may be collapsed to serve as essential processes on a higher level.
At the lowest level the essential processes represent elementary activities.
The elementary activities can be found by discovering state transitions of the fundamental (persistent) business objects.
Elementary activities typically bundle all actions, which are done by one processor without a necessary interruption.

In order to form business processes elementary activities are grouped by their inherent business relationship.

The business relationship is expressed in the value chain and can be taken from there.

Business processes behave like travelling guests

they are created by an event,
they are themselves transient objects.
they undergo several state transitions.
they change their state by elementary activities.
they carry along their local knowledge about triggering events, acting processor, affected business objects.
after delivery they terminate their active life by may be archived.

Equipped with this methodology and keeping these rules in mind in my next post I try to do my first cautious steps to derive essential IAM processes - which hopefully will turn out to be truly generic.

objects, subjects & actions

2010-08-17T12:24:00.014+02:00

As from a purely static picture we will never be able to derive the dynamics, i.e. processes, clearly time has come for some dynamic considerations.

Remembering the RBAC definition of permissions as ‘actions on objects’ we are clearly still missing that someone who performs these actions, the actors. Hence these special objects, which are able to act, turn into subjects:

In processes subjects (actors) act on objects.

Subjects may be users or managers

Managers are owners or clerks.

Owners are responsible
Clerks act on behalf of owners
Owners delegate to clerks

Subjects act or react

Their activity triggers an event
Reactions often are decisions (like approvals)

What now is the difference between acting and reacting? Does any subject really act on its own discretion?

Keeping in mind that we only regard events triggered by subjects which are confined in the IAM system any action which are triggered by external events can be regarded as actions.

Follow-up actions whose events were triggered by preceding actions can be regarded as re-actions.

Time may act as a (virtual) subject

Time acts on behalf of the organisation
Time triggers a predefined action
The action is driven by a policy
Time-triggered events are common

events

I mentioned the term ‘event’. Events trigger the dynamic, the make the system move.

actions (and whole processes) are triggered by events.
There are events …

fired by embedding business processes.
created by an subject
triggered by time
fired by state transitions

Events from outside the IAM system we call business events. Without business events there would be no need for the entire IAM system.

Request & approval

Let’s have a closer look to the action itself. What happens when an individual applies for access to an object? It requests access. In an abstract view a subject requests an object. As done before we can derive an object from this relationship: the ‘request’.

The request is a transient object but it may well be persisted.
It is the central workflow object found in IAM systems.
It can be understood as the instantiation of a process type.
The request is created by an event, e.g …

when a subject requests access to an object.
when time has come to re-validate a role / privilege.
when the defined response period has been passed without an activity (escalation)
…

Who now approves a request? As a general rule the owner of the requested object has to decide whether to approve or to deny.

The objects’ owner decides on the request
Hereby he changes its state
States are:

new
approved
rejected
escalated

We can expect as many requests as there are object owners.

To make the situation even more complicated - objects owner may delegate the decision to someone else or activate a policy which acts on behalf of him following pre-defined rules.

Subjects decide on requests

Let’s summarize:

In workflows subjects (actors) act on objects
The acting subjects may be owners or a clerk
Owners are responsible
Clerks act on behalf of owners
Owners delegate to clerks
Owners may pre-define their decisions by activating policies.
Subjects act or react
Their activity triggers an event
Reactions often are approvals

Every object has an owner

The guiding key concept is the concept of ownership, assigning the responsibility for an object to its owner:

Each object as one owner
The owner is responsible for the object
The owner may delegate object management to a custodian.
The owner may temporarily transfer ownership (full responsibility) to delegate.
Owners differ considerably from one organisation to another
This apparent complexity is a result of customising a simple model

In my next post I should try to identify elementary action which we later may use to compose IAM processes.

But before doing that I like to insert a few words on the modelling approach we use here: the ‘essential systems modelling’.

It therefore may be worth to stay tuned.

Business layer

2010-07-28T14:33:00.003+02:00

Do you remember the company “Business Layers”? It was among the 1st who implemented a user provisioning software, called “day one”. What a perfect name for a company! Expressing their very business purpose - to promote privilege assignment from the technical level one level up to the business layer – in their corporate name. But later they successfully sold to Netegrity who successfully sold to CA who put all into a big melting pot and not much of the original ideas and products remained.

Last Sunday while jogging though the quiet very early morning Hamburg this company came into my mind again when I was suddenly missing – well – the business layer.

To explain it a bit more in-depth let’s have a look at the NIST original RBAC definition:

(Source: Ferraiolo, Sandhu, Gavrila: A Proposed Standard for Role-Based Access Control, 2000)

Here the roles are introduced as an abstraction of the users who might be – no, typically are – different individuals whereas the role, which is tied to a list of resources, might stay unchanged. Hereby the role factors out the commonality of the individuals with respect to the permission assignment. As the RABAC concept is widely known and even mostly understood there is no need to further explain, that roles can be assigned temporarily on session basis and can themselves be ordered in a hierarchy. Permissions by RBAC are defined as ‘operations on objects’, equivalent to ‘actions on resources’ and so on.

These resources however are the real physical resources. So they are not ERP-system or ERP-system.general_ledger or or ERP-system.general_ledger.accounts_payable but SAP FI or JD Edwards EnterpriseOne.GL or Microsoft Dynamics NAV.genel.accpay. Whereas the corporation on the business layer simply has defined that this role should have read-/write-access to the accounts payables.

So at this side of the equation an abstraction is missing too. Like the role abstracts the individual (represented by the digital identity) some ‘generic resource’ should abstract the ‘real physical resource’. By this intermediate layer we could reduce the necessary number of roles and hence reduce overall complexity.

And allow business people to model roles on the business layer.

o.k, how now should we call this new object? Generic object, virtual object, abstract object? Hmmm … but what is your opinion? Can you eventually follow and agree to my esoteric thoughts?

Objects of the corporation

2010-07-05T13:34:00.018+02:00

The User: Identity uses a Resource

In many corporations digital identities first pop up as users. It is a short form of expressing that the digital identity is tied to resources: It „uses“ resources. It does so by performing activities.

This relation from the digital identity to the resource may carry attributes. It may be perceived as a derived object: the user.
Another a synonym for user is account.

The activity: user acts on the Resource

Users perform may different activities on resources: They act on resources. They usually do so by performing activities. This relations in turn may carry attributes. Again a derived object can be defined: the activity.

Permission = activities on Resources

According to the RBAC framework [Ferraiolo and Kuhn, 1992] activities on resources (objects) may be labelled with permissions: A permission is an approval of a mode of access to a resource. More often permissions are defined as “operation on objects” – which is just a different wording for “activities acting on resources”.

The Identity belongs to an organisation

Once we have referred RABC the obvious need pos up to define another object: the role.

Digital Identities don’t exist in isolation. In fact, if no one would be interested in its ID and / or attributes it wouldn’t make any sense to care much for a digital identity – unless it has a relationship to an organisation: In a way the digital identity belongs to an organisation.

There might be more than one elementary relationship. And there are many possible specialisations of this relationship. Again this relationship may carry attributes. And – not surprisingly - it turns to a derived object: the individual role.

It might sound a bit academic but it is worthwhile to distinguish between a role and a role type:

The role type is a predefined class of a relationship a digital identity may have to an organisation.
When the role type is assigned to a digital identity parameters are set to form the individual role.

This type vs. actual discrimination turns out to be useful general modelling principle. There are many possible specialisations of the relationship class role type and its incarnation role. Examples are employees' contracts, freelancers' contracts, partner- or customer-contracts. Obviously more than one such relationship may exist at the same time: means a digital identity may be assigned several roles.

The role

Let’s explore the nature of roles a bit deeper. The role type obviously is an abstraction.

It resembles very much the product which abstracts the contract. Keep in mind that the very justification of a product is to have a piece of pre-built business that is then easier to contract. Hence the role type relates to role like products to contracts. And the assigned individual role looks similar to an employee contract.

Let’s summarize:

The product generalises the contract. It is a contract type (or product).
The contract in turn instantiates the concept of a product (or contract type).
The role type generalises the individual role.
The individual role in turn instantiates the concept of a role type.

Both may in fact be combined into one agreement. They also may as well be left separate for the ease of handling. Recognising the close relationship between individual roles and contracts may help us finding appropriate roles by looking at the related contracts. If there is a contract there might as well be a role or more to be identifies. If there are roles defined there must be at least one contract – regardless whether documented or not. Hence not only employees also customers, suppliers or any partners may receive roles as well.

The role and the contract may well be one agreement (collapse to one). But for practical reasons we could give the contract a fine structure.

a contract defines the relationship
a role defines incarnation details
the contract’s details then are expressed by several roles

role vs. user

At our starting point we took the naive approach of an individual (represented by its digital identity) uses resources and derived the user as the relationship object to contain the relevant information about the usage.

Next we recognized that there was room for some abstraction. The role type now carries all the abstract usage. The instantiation of this role type – we called it the individual role – has then to keep all the actual information: the link to the digital identity, to the role type, start- and expiry dates and the like.

How then does the individual role differ from the user? Well, not very much. We just derive both objects on a different ways. The individual role type maintains the extra pointer to its role type – that’s alls. Therefore, once we have introduced the role type, there is no longer a need for a different object to be called a user. We can well merge them to be come synonymous: the user equals the individual role.

To each object policies can be applied

Everyone who is dealing with Access Management (AM) is aware of the truth, that role based access control will not alone save the world – or even to solve the access control issues.

There is obviously more about it: Each organisation has set up rules or policies in order to implement additional regulations.

Policies are sets of rules. The rules are generally applied on an objects state change. Applying rules to objects needs to be expressed as an abject of its own.

Policies can be attached to all objects

Very common in AM are SoD- (separation of duties) policies. A SoD policy applies to role types. A SoD policy contains several SoD rules. Only static SoD is considered here. Dynamic SoD requires the introduction of the object ‘session’ (which we still left out here).

The whole picture

Meanwhile the whole picture has grown and became more complex. But it still is far from being complete. It still expresses the static relationships only. It still does not distinguish between objects and subjects (actors). And the concept of ownership still needs to be introduced.

the identity

2010-06-30T13:41:00.017+02:00

Summarizing the work done before I try to identify the fundamental objects which are involved in IAM processes and the derived objects which describe the relationships of these fundamental objects.

When we talk about identity management topics not surprisingly the term identity pops up. It seems to be a good idea therefore to start with it. What is the identity after all?

In philosophy Identity is the sameness of two things.
In object-oriented programming Identity is a property of objects that allows the objects to be distinguished from each other.

But in Identity Management …

“We usually speak of identity in the singular, but in fact subjects have multiple identities.”
“These multiple identities or personas, as they are sometimes called, …”.

The sum of all these personas makes up the identity.
In turn personas are to be understood as its projection to the space of information demand in a specific context. The digital representation of this persona is what we call a digital identity.

The fundamental concept of identity management hence is the digital identity. In this context digital identity is defined as a minimal set of information (attributes) necessary to unambiguously identify an individual or a technical object. By this definition the digital identity is the “less rich” sibling” of the (real) identity.

This simple definition has some importance when it comes to data protection: the identity must not disclose more information about the individual than necessary for its identification. This minimal disclosure principle is hence rooted deeply in the very definition of the digital identity. Consequently it should apply to ID-cards (ID on a card) as well.

The digital identity’s lifetime is determined by the period the individual is of importance for the organisation. So, when an individual interacts with the enterprise ecosystem the first time, its digital identity is created, regardless whether it is a "user" of the enterprises resources or not. Being a user indicates a specific relationship already: the usage of resources. The digital identity’s life ends when it is no longer of interest for the organisation – or when an official regulation demand a termination.

Giovanni's view on: Standard Entities and processes for Identity Management

2010-06-19T23:05:00.007+02:00

As Giovanni Baruzzi does not maintain his own BLOG I (Horst Walther) undertook the job to publish his contribution on our GenericIAM-BLOG

Abstract: A generalized set of Entities and Processes for Identity Management is presented here to ease the implementation of real systems.

1 Introduction

Although most corporations regard their processes as unique and individually tailored, a core set of standard processes remains remarkably stable over the majority of examples. An accurate analysis reveals that, in spite of big differences between organisations, the considerable similarities exist between the processes for the same scope. Leveraging on this common aspects of these processes we introduce a model of Entities and Processes that can be of great help in the design of an IAM system for a generic organisation and we show that the differences lies not in the model, but in the different choices made in its implementation.

A set of entities and processes has been identified from a number of implementations. Those set are presented here for guidance.

2 Entities Map

The first step in our model is the definition of the entities involved. We restrict the scope of out modelling effort only to objects involved in the Identity and Access management, concentrating our attention on acting objects (person objects in most cases, but also juridical persons in the near future), the organisation itself, resources and right/access objects.

2.1 Acting entities

2.1.1 Person

A "Person" can be a natural person, a human being or a juridical person. Every person exists only once and can be identified through a set of attributes like Name, date Birth, place of Birth.

In the scope of GenericIAM we are not concentrating on persons but on the digital Picture of them: the Digital Identities.

For the IAM perspective, connections between the two is needed because only the person (natural or juridical) is entitled rights and duties and further the right to perform choices and the following actions. Hence, the entity "Person" is part of the acting entities.

Typical Attributes of a person:

Birthday
Name
Family Name
Location of Birth
Social Security Number
Taxpayer
…

2.1.2 Digital Identity

A Digital Identity is the representation of a natural person performing a Role inside the digital context of an organisation and is created normally as result of a contract.

The association of a digital identity is performed by the use of credentials, assigned at the Instantiation of the entity and presented before an action has to be performed in the system. Normally this action is a "log in" to the system. This association is needed because only the person is entitled the right to perform choices.

Although some very large organisations may chose to represent person and contract as separate objects, allowing more parallel digital identities per person, in the following discussion we would restrict us and assume that a person in an Organization has one and only one Digital Identity.

Typical Attributes of a digital identity:

Type of contract (e.g.. internal/external employee)
Status (e.g. active, temporarily inactive)
Date of beginning, pending End Date
Functional Role (e.g. user or Admin)
Business Role (Manager of a Unit, of a Cost Centre)

2.1.3 Account

An Account is a technical Object used to access an IT System and get access to resources. It represents one Digital Identity in the system. Credentials are used to guarantee that the acting person behind the account is the registered person.

In many organisations an employee owns only one account and this represent at the same time the Digital Identity.

An account is identified by an "account ID" through the IT System and to associate it to the Digital Identity owning it. Sometime a Digital Identity can have more accounts in a System if those have a different role (i.e. User or administrator).

Typical Attributes:

Account name
Password
Owner (digital identity)
Set of Access Rights
Membership in Security Groups

2.2 Structuring Entities

Structuring Entities are the building blocks used to represent the organisation. This representation is needed to associate the acting entities to the right component of the organisation structure and this association is one key aspect in the control of access rights.

2.2.1 Organisation

The Organisation is a legal entity implementing the IAM System and want to achieve a business goal. Actions are performed to achieve this business goal.

2.2.2 Organisational entity

Organisational Entities are structuring entities and describe the assembly of the organisation. They can contain inside itself even more Organisational Entities. A Digital Identity owns always a primary relationship to a Structure of this type. They can be: Organisational Units, Cost Centers, Locations, Companies, Projects, Business Projects and so on.

Typical Attributes:

Entity Name
Description
Owner, Manager
Type of organisational entity

2.2.3 Cost Center

To be done

2.2.4 Location, Locality

To be done.

2.3 Resources

2.3.1 Resource Object

To be done

2.4 Roles and Assignment Objects

2.4.1 Right Object (Application Role)

To be done

2.4.2 IAM Process Role

This type of role is connected to the IAM process itself and has a functional scope: Manager of a Organisational Unit, Data Protection Officer, IT Controller, Policy Manager, Decision maker, Exception decision maker etc.. Who can assume a set of activities and responsibilities in the context of IAM. A person through its Digital Identity can have many roles and a role can include sub-roles and have a hierarchical build.

Typical Attributes:

Role Name
Description
List of entitled persons

2.4.3 Business Process Role

A business process role is the bundle of one or more technical right objects and IT resources needed to accomplish a specific business process.

These Roles can be assigned directly to a digital identity (e.g. automatically through job description from the HR System) or assigned dynamically through IT Processes.

A role can include sub roles and associate more right objects in one or more IT Systems. It can be built hierarchically.

Typical Attributes:

Role Name
Description
List of entitled persons
List of included right objects

2.4.4 Policy

A Policy is an abstract object describing guidelines, rules and principles of an Organisation.

Some examples can be: "The email address of an employee is built from name+family name". "An Identity with the IAM-Process Role -Manager of an Organisational Unit- cannot have the right object XY". The Role IT-Service Z can only be assigned by the Compliance Officer" or "An Identity with the business role A cannot have a telephone number".

Typical Attributes:

Policy Name
Description
Policy Data
Policy Scope

3 Process Map

Every Object in the Entity Map is connected to a basic set of processes.

The Processes to create, modify and delete an object exist for all entities in the Object Map, although many implementation may choose to neglect some of those and do not explicitly implement them.

A second set of processes relates an acting Entity to business roles, digital rights, structural Entities (locations, Organisational units, cost centers) and resources, granting access to them.

The most central and most frequent processes are those involved in the life cycle of acting entities and the grant or revoke of rights. These are present in every implementation.

There are many ways to implement every single process.

The set multiplication of entities by processes and by implementation choices give as result the perceived complexity of IAM Processes.

3.1 Processes about the Acting Entities

3.1.1 Existence

After a Natural person signs a contract with an organisation, a corresponding digital Identity is created in the IAM System. More complex organisations (Holdings, whom many organisations belongs to) may choose to implement a two step structure, a digital object representing the person itself and an object representing the contract between the person and the organisation. One may think in the near future to extension of the digital identity to juridical persons too.

A new user enters the organization and a New Instance of an Digital Identity is created.

3.1.2 Deactivation of a Identity Instance

After an Entity has been disabled, it can not be anymore object or subject of an IAM Process, although the information about it is not deleted from the system until an archival time does not expire.

An existing user leaves the organisation.

An existing user is locked out of an Organisation

3.1.3 Deletion of an Identity

The archival time of an Identity is expired

3.1.4 Change of an Identity

The most processes in an IAM System involve changes in the Information about an Identity Object and the association of it to resources, roles and Structural Entities (locations, Organizational units, cost centers).

Change of description attributes (Address, Telephone, Email)
Change of Identifying attributes (Name, ID)
Change of Credentials (Password, Digital Certificates)
Change of relationship to the Organisation
Primary Assignment to an organisational Structure
Change of the primary Assignment
Assignment to an additional organisational Structure
Removal of additional assignment
Addition of a Business Role
Change of a Business Role
Removal of a Business Role
Change of Status
activation
deactivation
temporary deactivation
change of legal relationship

3.2 Processes about the policies

To be defined

3.3 Processes about structural objects

Existence
new structural unit
delete structural unit
Change/Modify
change organisational responsibility (Function, Role, Task)
change describing attributes
change of responsibilities

3.4 Validation Processes

3.5 Processes about Resources, Roles and Rights

Resources
Resource definition
Right objects
Roles

3.6 Processes about Assignment of Roles and Rights

Auditing processes
Attestation processes
Control Processes

4 Implementation choices

For all described processes the IAM-Architect can perform many choices during the design. It would be unnecessarly costly to perform a full implementation for events that are not planned or to seldom for a small organisation such as the creation of a new business unit. Nevertheless these processes have to exists implicitly at least at the start of the system.

It may be useful to design consciously the NOT-implement of something.

The aim of this chapter is the review of choices given for every process, startung from the simplest and cheapest (the NIL implementation) through the most sofisticated.

4.1 The NIL-Implementation

The NIL implementation of a process means that an Entity is defined at design time and that a change or deletion is not forecasted it until the system is redesigned.

For many organisations there is no need for an explicit process to instance an organisation, change and delete it, because there is the only one of it. Larger Organisations consisting of many companies may see the problem differently.

4.2 Software change

Rare events do not require oft fast reaction times. In many cases the implementation of a real time, online process is not needed and their implementation can be restricted to system information which is changed only in case of a Software Deployment. A new location is often a seldom event and the corresponding container in an LDAP Directory may be implemented during the deployment of a new software release.

4.3 Administrator's action

Today's administrators are burdened with many tasks: among them they have to define security groups, reset Users' password, assign shares, modify policies. Many designs assign the maintenance of many Entities to an administrator task. Caution has to be used here, because an administrator's action is seldom logged and a weak ring in a security concept as the are often the target of social engineering. The reconciliation processes are only a mean to mitigate the problem. In a good concept the task of administrator's should not include the grant of access rights.

4.4 Manager's Grant

The User applies for an access right and the line manager grant it. Instead of the line manager we can see the manager of the resource itself or the cost center manager. This is a very common way to implement a process and includes many variations; some build on top of simple paper processes, with forms and approvals, others involving security administrators up to signed text files sent at regular intervals. Unfortunately many of these implementations suffer oft under trivial problems: a simple mail based process may be easily tampered and a manual process suffer from poor performance and can show terrible reaction times if the case has to be escalated or if the approver is not available.

A very common variation on this theme is the regular delivery of a text file from the human resource department.

4.5 4-Eyes approval

The most reliable implementation of an approval process is the 4-Eyes approval supported by a digital system. It is the most costly but allows technical raffinesse fulfilling the desires of most auditors like digital signature an extensive Logging while presenting very interesting performance figures, being able to reroute a request and to escalate automatically.

5 Case Study "Medium sized automotive supplier"

The company of this case study is a product company, specifically set up to produce a very limited set of product for a large customer with the lowest cost and the gratest flexibility.

In this case the personal turn-over is very high and new workers have to be provided with access rights in minutes and not days. At the same time the number of security profiles is quite small and stable and such are the cost centers, locations and others aspects of the company structure.

The definition of Organisation, Cost Centre, Location are made at design time and changes are not forecasted. The definition of security Groups, policies, Business Roles and so on are deferred to the deployment of software and if they ned to change, they require a new software deployment.

Digital Identities are defined daily from a text file delivered by the Human Resource Department, but a Manager can use an Browser Application to quickly define a new digital identity for a new worker, subject to reconcile.

Access Rights are assigned through the association to a business role by a 4-Eyes automated Process, with support for digital signature and logging. The routing rules are so conceived to allow fast escalation of the application and result in the grant or denial in a few minutes.

drivers for generic processes

2010-06-14T11:15:00.010+02:00

Our move towards a more standardised approach of developing organisational processes fits nicely into two major trends to be observed in the general management context:

business driven identity management
industrialisation of services

Although the necessity for some kind of identity and access management reaches far back, it is regarded as a coherent and consistent discipline only recently [Windley, 2005]. As computers were used in the past by specialists only, IAM tasks were delegated to technical administrators. Since computer usage has become the mainstream toolset for any business, identity management tasks received acceptance as genuine management responsibility [Stuart, 1999] − yet with a strong technical component.

The second trend has two major drivers: at first, enterprises need to prove compliance with some regulatory requirements (e.g. Sarbanes Oxley Act[3]and the upcoming " EuroSOX" [4]), at second, the necessity to meet the challenges of global competition. Both drivers result in a more industrial perception of the enterprises as formal systems. By applying standard governance models (e.g. CobiT[5]), best practice models (e.g. ITIL [6]), or generic process models (e.g. GenericIAM), it is expected to reduce costs through standardisation and simultaneously ease the job of proving compliance while focusing on the core competencies of the business.

[3]The Sarbanes-Oxley Act of 2002is a United States federal law passed to enhance corporate transparency and responsibility [USA SOX, 2002].

[4]Directive 2006/43/EC of the European parliament and of the council of 17 May 2006 on statutory audits of annual accounts and consolidated accounts, amending Council Directives 78/660/EEC and 83/349/EEC and repealing Council Directive 84/253/EEC[EU DIR 2006/43/EC, 2006].

[5]The Control Objectives for Information and related Technology(CObIT) is a set of best practices for information technology management created by the Information Systems Audit and Control Association (ISACA), and the IT Governance Institute (ITGI) in 1992 [ITGI COBIT 4.1, 2007].

[6]The Information Technology Infrastructure Library(ITIL©) is a framework of best practice approaches intended to facilitate the delivery of high quality information technology (IT) services [OGC ITIL 2, 2005; OGC ITIL 3, 2007].

References

[Stuart, 1999]
Helen Stuart, Corporate Communications: An International Journal, Volume: 4 Issue: 4 Page: 200 - 207 DOI: 10.1108/13563289910299328, MCB UP Ltd., 1999
[Windley, 2005]
Phillip Windley, Digital Identity, O'Reilly Media, Inc., 1st ed., 2005

Exploring Generic Identity Management Processes

2010-06-13T14:51:00.023+02:00

According to our experience and the reports of the main analysts the definition of processes for the Identity & Access Management (IAM)[1]requires major effort.

This situation raises the questions: Why do we always start with a blank sheet of paper? Why " reinvent the wheel" again and again? Shouldn't we instead focus our efforts on the obvious differences and use the common set of standard processes " off the shelf" ?

The NIFIS[2]initiative " GenericIAM" (Generic processes for the Identity & Access Management) was set up with the mission to extract a generic IAM process model from existing IAM processes implemented in major corporations.

However we found that even for the most experienced process modelling experts abstraction and documentation of generic commonalities from enterprise specific solutions following a bottom-up approach turned out to be remarkably difficult.

Based on the assumption that the IAM processes of an enterprise could be described completely by the actions of a limited and manageable number of subjects (actors) on an equally limited number of objects (figure 1), we herewith try to derive a generic model following a seven-step top-down approach. The 7 steps are …

Identify the fundamental objects which are involved in IAM processes.
Detect the derived objects which describe the relationships of the fundamental objects.
Identify the subjects (actors) who operate on the objects.
Name the elementary actions which …
- express the actions of the subjects on the objects,
- express the interactions of the objects, or
- perform object state transitions.
Detect business events as triggers for processes.
Assemble essential processes by combining the elementary actions to net of flows yielding a meaningful result in business terms.
Complement the essential processes by physical actions (check-, translation- and transport-steps) in order to cope with imperfections of existing implementations.

The intention of this series of posts is to demonstrate how the top-down- and the bottom-up approach combine seamlessly to a self-contained and consistent model.

[1] Identity and access management combines processes, technologies, and policies to manage digital identities and specify how digital identities are used to access resources.

[2] Nationale Initiative für Informations- und Internet-Sicherheit (NIFIS e.V., http://www.nifis.de/)

GenericIAM - time for a re-boot

2009-06-10T21:05:00.005+02:00

Dear colleagues it has become quiet in the GenericIAM forums (Google, LinkedIn) & BLOGs (BLOG). The Web-site (GenericIAM) is not up-to-date and the off-line activities have stalled.

There are several reasons for that. But none of them should prevent us from overcoming it.

Surely we are in the financial crisis and everyone just tries to survive. Well, not everyone. The labor market is split into the haves and the not-haves. But even those who still have their jobs and are still well paid feel some pressure to contribute to the corporations’ income generation. Yes and my personal financial crisis started even earlier. So I had to look for a serious and income oriented challenging assignment. It took me far away to the Ukraine and kept me busy for 24 hours a day.

But there is more about it. Let’s look back. There were some things we did right – and some we did completely wrong.

Shocked by the fact, that u to 80% of all effort in IAM implementation projects has to be buried in process definitions we had the honorable idea to collect all those experiences and assemble a generic process model. Based on this generic IAM model (hence our brand became GenericIAM) most future modeling attempts should turn out to be much easier and hence cheaper.

This idea is still valid. Also the pressure of the modeling burden is still felt.

But on the way from an idea to innovation some lessons had to be learnt:

Timing: Let me 1st hint at the general problematic of innovation. As the brilliant Gunter Dueck, IBM distinguished engineer and frequent column writer once had uniquely put it to the point: If you come up with an innovation you will never be encouraged to move on with it. There are two choices. Either you are to early. In this case the commentators will say: “No, this never works. Forget about it.” Or, you are too late already. Now you will hear the ‘experts’ say ”Save your efforts, it already exits.” So, when is the time right? When you receive more or less the same number of answers out of each category. To my observation of the ‘market’ (if there is one) the window of opportunity has not yet closed. There are still prophets around issuing warnings. On the other hand some proprietary & well shielded process collections exist.
Costs: Let’s start from our most stupid idea at the very beginning in 2005. To cover our expenses for travelling, meetings and the like, we thought of a fee for our intended publications, so to sell them. Well, for tax reasons alone we would have had to set-up an administrative overhead that quickly convinced us to drop this idea. In the age of free open source software (FOSS) we should better contribute to some kind of free open org. Everyone has to cover his own costs.
Modeling approach: Modeling bottom-up seemed to us to be the natural approach. Collecting specific implemented models, anonymizing, harmonizing and normalizing them could let us derive truly generic models out of customer specific fragments. It only did not work. After a couple of volunteers had invested a huge amount of work and proudly presented their model the comment ‘well, but it still is not truly generic!’ during one of our meetings instantaneously destroyed their enthusiasm. In fact it turned out, that especially the most experienced practitioners faced difficulties in getting to the next layer of abstraction. The 2nd attempt was a top-down modeling approach deriving the basic processes from the interaction of corporations’ fundamental objects using the notion of Petri nets for the top-most layer. Here we at least achieved to jointly write, review & sign-off a paper) on this approach – and forgot to publish it properly. But the wider audience refused to understand Petri nets. So again dead end. In the 3rd attempt, our modeling group gave the top-down way another try. This time they got stuck after agreeing – more or less – on the fundamental objects. Well, and then the crisis came (see above).
Meetings: Most puzzling for me was, that, our quarterly meeting, which we held in different German cities, were always well accepted and attended by 10 to 20 participants. This was great. But at the same time the modeling progress slowed down. Even some of the frequent visitors of our meetings were reluctant to submit their at least half-baked models to out raw material collection. One of the frequent participants hit the nail on its head: “We IAM experts in our corporations otherwise don’t find anyone to talk to.” Hmmm, he was right. But it was not our intention to set up a German circle for the professional IAM dispute.
Collaboration: to my opinion IAM suffers heavily form the domination of IS-security aficionados. They usually try to provide for a maximum security for their companies - regardless of the adverse effects. After all perfect security can only be achieved in total isolation. A risk based ‘good-enough-security’ would fit most corporations better – but would be considered as a failure by them. Those people have problems to email & chat, write BLOGs or collaborate electronically with colleagues they have never seen. Web 2.0 is evil to them. They tend to keep everything secret. But we needed to work in the public space. Each one on this globe should see our progress and set-backs, participate real-time and online in it and of course contribute to it. So, BLOGs & Forums instead of Intranets & private mailboxes.
Language: There is only one language to be used for such activities: international English. No German, French or other tribal languages should be allowed in professional documents. They are great for art & literature but should be kept out of the professional arena. Well, for the small talk, we have a bit more relaxed opinion.

To sum it up: We learned that …

there is still a demand for generic IAM processes as open org,
we should deliver our results for free to the global community under a creative commons licence model,
we have to follow an top-down approach,
we need to collaborate publicly via the Web,
in case we feel the need to meet personally we should be sensitive for 2nd order effects,
we must document all our artifacts in international English.

So, it is time to reboot GenericIAM.

The good news is, that there are some volunteers who like to take the lead and push the activities relentlessly forward.

If you like to join please contact …

Andreas Netzer (andreas.netzer@ic-compas.de>, skype: andreasnetzer),
Marc A. Dierichsweiler" (m.dierichsweiler@impulsit.de) or
Martin Kuppinger (mk@kuppingercole.de, skype: martinkuppinger).

We should not miss the 2nd chance to create the 1st IAM standard process model.

Horst Walther, 2009-06-10, Kiev, Ukraine