A M ETHOD FOR I MPROVING O RGANISATIONAL I DENTITY M ANAGEMENT

de-signing organisation’s identity management. To conclude this section, a method to improve organisational identity management architecture is presented. The method consists of six steps.

Step 1. Identify the owner of identity management infrastructure

At first, ownership for the identity management related issues in the organisation needs to be decided. Usually, the owner is located in the senior management of the organisation’s IT services unit. The owner needs to have a broad perspective of the business of the organisation, which makes it easier to focus the refinements on the issues that are most essential for the success of the organisation. The owner has also potential to become the project’s key proponent in the organisation. In project management literature [SCHW07:75], this role is often known as the champion of the project.

Step 2. Get top management support

Identity management related projects have influence and need commitment and re-sources in several parts of the organisation. In order to drive changes affecting sev-eral organisational units, the commitment of the top management is a success fac-tor of the project. This is a well-known advice both in project management literature [SCHW07:58] and in business process re-engineering literature [VOND96:151].

Top management support is needed, because identity management projects cause not only technical changes, but also the changes in the processes in the organisa-tion. Otherwise, the ideas would be rejected by the middle management. As de-scribed in Section 3.6, organisational units do not necessarily see how their

proc-40

esses relate to the identity management architecture of the organisation, and tend to optimise the processes to reflect their own needs.

Step 3. Analysis phase

The analysis phase reflects the three motivations of identity management presented in Table 1 (page 2). The risk analysis examines the probability and severity of re-alisation of risks related to identity management. What are the assets that require most protection? Are there risks related to unauthorised access, reliability of au-thentication or inerasability and non-repudiation of the audit trail? How to balance the risks and the costs of protection?

Analysis of the potential to improve efficiency focuses on reducing costs. Is there potential to cut overlapping maintenance of identity information in the organisa-tion? Could improved authentication and single sign-on reduce the time people spend on logging in to information systems? Could role-based authorisation poli-cies or a general-purpose workflow engine for applying and granting permissions ease management and auditability of authorisation?

Analysis of potential for new businesses or new ways to organise internal informa-tion management tries to identify ways how improved identity management could enable issues that have not been possible or have been too difficult earlier. For stance, standard interfaces could ease outsourcing of information systems. New in-formation systems which make use of the rich set of attributes available for end us-ers could be introduced.

Step 4. Requirements specification phase

Based on the three dimensions of the analysis phase, requirements for the organisa-tional identity management architecture are specified. Are there external regula-tions that the organisation needs to comply with? What are the needs for identity flows in the organisation? How soon should an end user’s account be closed when he departs? What kind of attributes does the organisation want to utilise in its iden-tity management and which of them have potential in authorisation? What are the needs for authentication; who needs to be authenticated strongly and where? What are the requirements for audit trail?

Step 5. Design phase

In the design phase, the identity management architecture fulfilling the require-ments is designed. Owners for different pieces of identity information are agreed on; for instance, the HR unit becomes the owner of employees’ names and em-ployee numbers and IT services unit owns their email addresses. Once the owners of attributes are known, they are able to decide the authoritative sources for the

at-41

tributes; for example, the authoritative source for employees’ name and employee number might be the HR registry. The owners of the attributes become also re-sponsible for defining the attribute semantics, including vocabularies, if any.

Having agreed on authoritative sources, some of them are elevated to base regis-tries, which are the places where new identities enter the organisation. A map of the organisation’s IT systems can now be drawn, where some systems are base reg-isters for identities, some are authoritative sources for attributes and the rest of the systems rely on the identity data provided to them. This results in a design of iden-tity flows in the organisation.

Because the identity management architecture is strongly coupled with the proc-esses in the organisation, necessary changes to the procproc-esses need to be identified and designed. For instance, if HR registry is used as the base registry for em-ployee’s identities, process changes may be needed to ensure that the data in HR registry is always up-to-date. If identity data is designed to flow from HR registry to the building access system, the management process of the building access sys-tem need to be changed so that the porters will not any more enter employees’

identity data to the system when providing them with access cards. If permissions to use information systems have been based on circulating signed paper forms, re-placing them by a workflow engine causes process changes. Designing the process changes requires considerable amount of understanding of the organisation’s func-tions.

Step 6. Incremental implementation phase

In the implementation phase, the design is put into practice. The organisation ac-quires necessary products, such as a metadirectory, and integrates them to the base registries, authoritative sources and other connected systems. Necessary changes to the organisation’s identity data semantics and vocabularies are implemented and new processes introduced. Necessary changes to the processes of the organisation are implemented.

The first five steps followed the well-known waterfall model for systems develop-ment lifecycle. For the impledevelop-mentation phase, an incredevelop-mental model is proposed, consisting of a series of partial products (increments) throughout the project time-scale [GRAH92]. New systems and features are delivered gradually, trying to minimise the disturbance it causes to the daily life of the organisation. Early re-sults of the project can be shown, inspiring further development of the identity management architecture. Benefits of the identity management architecture can be first introduced where the analysis has shown biggest benefits, whereas the less important features can be delivered later.

42

This section presented a method to improve the implementation of organisational identity management architecture. However, improving identity management is a continuous process. Changes in the organisation’s business, new needs and the new possibilities provided by technology lead to changed requirements and the re-design of the identity management architecture. Some of them may be influenced by federated identity management, which is going to be introduced next.

43