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.

the identity

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 organization. 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 organization – or when an official regulation demand a termination.

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

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 organizations, 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 organization 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 organization 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 organization 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 organizations 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 organizations 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 organization. This representation is needed to associate the acting entities to the right component of the organization structure and this association is one key aspect in the control of access rights.

2.2.1 Organization

The Organization 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 Organizational entity

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

• Entity Name
• Description
• Owner, Manager
• Type of organizational 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 Organizational 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 Organization.

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 Organizational 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, Organizational 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 organization, a corresponding digital Identity is created in the IAM System. More complex organizations (Holdings, whom many organizations 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 organization. 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 organization.
An existing user is locked out of an Organization

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 Organization
• Primary Assignment to an organizational Structure
• Change of the primary Assignment
• Assignment to an additional organizational 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 organizational 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 unnecessarily costly to perform a full implementation for events that are not planned or to seldom for a small organization 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, starting from the simplest and cheapest (the NIL implementation) through the most sophisticated.

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 organizations there is no need for an explicit process to instance an organization, change and delete it, because there is the only one of it. Larger Organizations 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 refinement 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 greatest 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 Organization, 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 need 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

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

• business driven identity management
• industrialization 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 standardization 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