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.