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?

Modelling fundamentals

I once mentioned, that follow the essential systems modeling (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 Modeling 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 artifacts from the model in order to prevent them from influencing future models. And this ability is exactly 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:

1. 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.
2. Analysis of the fundamental concepts of the current system:
• Deriving of the essence out of the current system.
• All implementation specific artifacts are removed in this step.
• Using "perfect technology" as the guiding principle.
• The result is the current essential system.
3. 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.
4. 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 artifacts 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

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 organization
• 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 organization to another
• This apparent complexity is a result of customizing 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 modeling’.

It therefore may be worth to stay tuned.

Business layer

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

1. 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 is account. But to be precise in terms of semantics it is more about the use rather than the user. 

In terms of the Access Management (AM) however it deems to be more appropriate to name the relationship “is authorized to use” and the resulting derived object “authorization”. 

2. The operation: authorization to operate on the resource

Users may be authorized to operate on resources: In other words: they are performing operations. This relation in turn may carry attributes. Again a derived object can be defined: the operation.

3. Permission = operations on Resources

According to the RBAC framework [Ferraiolo and Kuhn, 1992] operations on resources (objects) may be labeled with permissions. Permission is an approval of a mode of access to a resource. Sometimes permissions are called “entitlements”. More generally they are defined as “operations on objects” –just a different wording for “operations on resources”. 

4. The Identity belongs to an organization

Once we have referred to RABC the obvious need pops 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 its attributes. It wouldn’t make any sense to care much for a digital identity – unless it has a relationship to an organization: In a way the digital identity belongs to an organization as it plays a role there. There might be more than one elementary relationship – usually an agreement or a contract. And there are many possible specializations 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 emphasize that a role characterizes a type of relationships:

• The role is a predefined class of a relationship a digital identity may have to an organization.
• When the role is assigned to a digital identity, parameters are set to form the authorization.

This type vs. actual discrimination turns out to be useful general modeling principle. There are many possible specializations of the relationship class role and its incarnation authorization. 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.

5. 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 chunk of pre-built business which makes it easier to close a contract. Hence the role relates to the authorization like products to contracts. And the authorization looks similar to an employee contract. Let’s summarize:

• The product generalizes the contract. It is a contract type (aka product).
• The contract in turn instantiates the product (or contract type).
• The role generalizes the authorization.
• The authorization in turn instantiates the concept of a role.

Both may in fact be combined into one agreement. They also may as well be left separate for the ease of handling. Recognizing the close relationship between 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 identified. 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

6. Role vs. authorization

At our starting point we took the naïve approach of an individual (represented by its digital identity) uses resources and derived the use as the relationship object to contain the relevant information about the use. For our purpose we called it the authorization. Next we recognized that there was room for some abstraction. The role now carries all the abstract use. The instantiation of this role – we called it the authorization – has then to keep all the actual information: the link to the digital identity, to the role, start- and end-dates and the like.

7. The whole picture

By considering the identity’s relationship to two different objects – namely to the resource and to the organization we received two distinct branches which should belong to one tree.
Both have two objects in common: the identity and the authorization. Combining them however needs to rethink the reason for doing so. If the role abstracts the authorization it should be the role too who defines of the operations on the corporation’s resources. 

Meanwhile the whole picture has grown and became more complex. But it still is far from being complete. It is worth to have a closer look to the role as the way we use this concept here differs a bit from the common use in daily life. The role as we defined it here is expressed solely in business terms. That’s why some call it a business role. But in daily life, if we talk about the role some plays in a corporation, our perception is more one of the function person has for that particular corporation. So here the function is the role a person plays – so why not call it the functional role? Following this definition however we receive a role which is not information rich enough to contain all privilege determining dimension. If for example your functional role is to be a salesperson you may be restricted to a certain sales area or to a certain group of products. So there is something beyond the functional role constraining their full potential. Let’s call it the constraint for now – and go more into depth later. So we split up the “organization” into functional roles and constraints. 

More even the picture offered here 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.