How to find roles

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

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

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

What are roles?

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

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

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

What is the organization?

Figure 1: Roles link process to resources

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

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

• Business processes express the organization's dynamic behavior. Often they are the starting point. They are best understood and perceived as been the essence of the corporation - something to excel or to fail in.
  
• Processes themselves are made up of elementary actions which can be understood as some atomic activity - what one person does at a time in one location.
  
• These actions are performed by someone - not yet individual persons but on class level roles instead. So here they come into play - the roles, functional roles still.
  
• To be able to perform the singular actions these functional roles need appropriate access to resources. The functions are bound to resources. They are being "localized".
  
• Constraints drive this localization. They further restrict the roles access to certain subclasses in order to reflect the real world's needs. Those constraints express the privilege determining information dimensions like organizational unit, region, contract type, customer group and more. The resulting "business role" finally is the one which can be used for access control as it defines the intended privileges - still defined in business terms.

So processes and roles can't be modeled independently - without being incomplete. But only by taking constraints into account makes the model sufficiently determined to derive privileges for information object access from functional roles.
This picture to my opinion is more straight forward and easier to comprehend than the so called Stanford model:

Figure 2: Stanford model enterprise and system abstractions. McRae, R., The Stanford Model for Access Control Administration, Stanford, University, 2000 (unpublished but cited by Ferraiolo, D., and R. Kuhn).

Obviously role finding requires good and - even more important - explicitly documented knowledge of the business domain (best to be expressed in a formal enterprise model), some experience in related business modelling areas and a sound portion of intuition.

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

The static IAM objects

The static IAM-Objects

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

The identity	Identity: the digital identity is the digital representation of the individual, which has a defined relationship to the corporation. It is stored and maintained as long as the as long as the interest in this relationship lasts and no legal or regulatory requirements restrict its use.
The functional role	Functional role: a bundle made up of business functions as defined in a functional enterprise model which represents the tasks which have to be performed. So the functional role just specifies functions to be performed. The functional role can be understood as a projection to the enterprise model. In case the enterprise model is purely functional (in contrast to object oriented), the functional role just lists corporate functions. It doesn't contain any hints on how to grant access to information objects or applications. Even more; only in special cases you may be able to derive the affected information objects they are acting on from the role's names. Note: This applies if you have a functional enterprise model at hand. This is most commonly the case. Situation might look slightly different if there is an object oriented (means class based) enterprise model available.
The constraint	Constraint: constraints narrow the focus of a functional role. Well known examples are defined authorisation levels, to limit transactions by a maximum value (value authorisation) or to limit the scope of activity to certain organisational units or regions (structural authorisation). Value authorisations in turn can be further split into direct and indirect value authorisations. For example the permission to close contracts or to grant discounts up to a certain (direct) limit can be expressed as an amount of money. On the other hand there can be also maximum values defined for parameters (maximal validity period, or maximum mileage - both of a leasing contract) which can be converted to an amount of money after some form of transformation only (indirect). Furthermore it is rather common, that the contract type (employee, contractor, interim manager …) might lead to further restrictions of a role's full privileges. More types Constraints are possible of course and more discussion on this object is necessary I fear.
The permission	Permission: The elementary object of access management is the elementary privilege (permission). According to the RBAC standard it is defined as operation on objects. In case the privileges cannot be defined via access to information objects, privileges alternatively can be defined the access to systems.
The business role	Business role: In this model the business role is the central structuring element. It expresses all information necessary for the (technical) privilege assignment on business level. But you could also call it the localized Role.  By the introduction of the business role the purely functionally defined functional roles are finally bound to the specific Information objects (or alternatively systems). This can be done by linking directly to elementary permissions. (In some cases, when applications or systems offer some kind of roles already, the business role may link to these 'system roles'. But their introduction needs its own discussion) Here the constraints unfold their by definition restricting effect. If you manage to bind the information objects strictly rule driven to the functional roles you may not need to store the business roles. In this (lucky) case they can be considered as purely virtual (transient) objects. In most - real world - cases however we have to consider them as static (persistent) objects. You may imagine the business role as a triple of keys - and not much more. Those are the keys of the functional role it points to, the constraint, if there is any and finally the permission which is used.
The authorisation	Authorization: when the business role is assigned to a digital identity the object authorization is created. By this assignment the very act of the role based privilege assignment is done. In reality the identity is assigned several business roles to define the planned information object use. All access information is stored in one or more authorization objects per identity representing the total use of all relevant information objects. Note: In this context the object authorization is often called user. But  not the using person is meant but the relation expressing the use.

Processes of model maintenance

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

So which processes do we need at first? Model maintenance means the maintenance of all of its objects. So we obviously may expect …

• Maintain functional role,
• Maintain constraint,
• Maintain permission and
• Maintain business role.

Maintain functional role:

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

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

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

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

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

Maintain constraint:

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

Maintain business role

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

In a 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 segregation 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 AM system. While modeling these processes on the essential level however we need not to deal with these system boundaries.

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

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

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

Applying and granting

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

essential IM processes

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 is 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

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:

1. into Identity Management & Access Management
2. into operational and managerial processes
3. 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

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

IAM-objects & non-IAM-objects

Everything starts with an agreement …

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

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

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

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

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

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

… and ends up in an "authorization".

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

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

Incompetence

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 Weisheit 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 erstmalig 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?