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.
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.
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
According to our experience and the reports of the main analysts the definition of processes for the Identity & Access Management (IAM)[1]requires major effort.
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. Obviously considerable similarities between the processes of different corporations exist.
This situation raises the questions: Why do we always start with a blank sheet of paper? Why " reinvent the wheel" again and again? Shouldn't we instead focus our efforts on the obvious differences and use the common set of standard processes " off the shelf" ?
The NIFIS[2]initiative " GenericIAM" (Generic processes for the Identity & Access Management) was set up with the mission to extract a generic IAM process model from existing IAM processes implemented in major corporations.
However we found that even for the most experienced process modelling experts abstraction and documentation of generic commonalities from enterprise specific solutions following a bottom-up approach turned out to be remarkably difficult.
Based on the assumption that the IAM processes of an enterprise could be described completely by the actions of a limited and manageable number of subjects (actors) on an equally limited number of objects (figure 1), we herewith try to derive a generic model following a seven-step top-down approach.
The 7 steps are …
- Identify the fundamental objects which are involved in IAM processes.
- Detect the derived objects which describe the relationships of the fundamental objects.
- Identify the subjects (actors) who operate on the objects.
- Name the elementary actions which …
- express the actions of the subjects on the objects,
- express the interactions of the objects, or
- perform object state transitions.
- Detect business events as triggers for processes.
- Assemble essential processes by combining the elementary actions to net of flows yielding a meaningful result in business terms.
- Complement the essential processes by physical actions (check-, translation- and transport-steps) in order to cope with imperfections of existing implementations.
The intention of this series of posts is to demonstrate how the top-down- and the bottom-up approach combine seamlessly to a self-contained and consistent model.
[1] Identity and access management combines processes, technologies, and policies to manage digital identities and specify how digital identities are used to access resources.
[2] Nationale Initiative für Informations- und Internet-Sicherheit (NIFIS e.V., http://www.nifis.de/)
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?
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.
