IdM Reference Architecture

Centralized Identity Management
REFERENCE ARCHITECTURE 09/2010
Copyright © Secproof Finland 2010
Reference Architecture
Hannu Kasanen, Secproof Finland

Table of contents
1. PREFACE............................................................................................................................. 1
2. IDENTITY MANAGEMENT – WHAT IS IT ALL ABOUT? ...................................................... 1
3. IDENTITY MANAGEMENT COMPONENTS .......................................................................... 3
3.1. IDENTITY MANAGEMENT CORE .................................................................................................3
3.2. IDENTITY STORE..................................................................................................................3
3.3. SOURCE DATA DELIVERY INTERFACES .........................................................................................3
3.4. IDENTITY DATA DELIVERY INTERFACES........................................................................................4
3.5. END-USER INTERFACE ...........................................................................................................5
3.6. MANAGEMENT USER INTERFACE ................................................................................................5
3.7. MANAGEMENT API...............................................................................................................5
4. SECPROOF – THE IDM EXPERT.......................................................................................... 7
APPENDIX: EXAMPLE OF A CENTRALIZED IDM SERVICE
About the author
Hannu Kasanen is leading a team of Identity and Access Management (IAM) and Enterprise
Architecture (EA) specialists. He is also working as a consultant in a variety of Identity
Management initiatives. The writer is typically supporting customers operating in a global
environment to fulfil their IdM requirements. A typical assignment includes working in close
co-operation with the customer to figure out what should be done and how to get it done
in the most efficient manner, as well as making sure that agreed actions are, in fact,
carried out by vendors, subcontractors and other parties.
Trademarks
All trademarks, product names and registered trademarks are the property of their respective owners. Any third-
party trademarks, service marks and logos are the property of their respective owners.
Terms of use
This document can be freely copied and printed for an offline internal use. The content of this document may not be
sold, reproduced, or distributed without prior written permission from Secproof Finland. Any further rights not
specifically granted herein are reserved.

1/7 Copyright © Secproof Finland 2010
1. Preface
This document presents Secproof’s vision of centralized Identity Management (IdM) reference
architecture. In addition, the document intends to elucidate IdM-related concepts in layman’s terms to
the largest extent possible.
This reference architecture outlines a general solution for a centralized Identity Management without
committing itself to any specific business needs. The reference architecture describes components
typically associated with an Identity Management system at an abstract level. It can be used as a model
and planning tool in IdM development initiatives.
Please note that there are plenty of features and technologies in the Identity Management domain,
which are not addressed here. This reference architecture merely describes the fundamental
components that are – or at least should be – present in each Identity Management system.
2. Identity Management – What is it all about?
In this context, Identity Management refers to the management of the users’ digital identities
and associated access rights (a.k.a. entitlements), as well as the delivery of this identity and
access rights information to relevant parties.
The ultimate goal of the Identity Management is to ensure that the right users have access to right
resources at the right time – and that all of this done as easily and effectively as possible. The user in
this case may be a natural person (e.g., a company employee, partner, customer, etc.), a fictitious
person (e.g., a test user), an application or a process. The resource, for its part, can be some (business-
essential) piece of information, application or part thereof, or even some physical premises.
Thanks to Identity Management, an organization is able to effectively respond to, for example, the
following questions:
 Who are the users?
 What information, applications or services do (or did) they have access to? Why?
 Who is authorized to approve access to the information, applications or services? Why?
 How to make sure that unauthorized access rights are removed in a timely manner?
Identity Management is more than just IT systems and technology. It also involves people, processes
and policies that are supported, enhanced and enforced by the Identity Management.
Identity Management vs. Access Management
What is the difference between Identity Management and Access Management? In this
context, the former means the management of users and their access rights through
predetermined processes and policies, while the latter means the run-time
enforcement of such access rights.
An Identity Management service is, for example, responsible for setting up default user
accounts and access rights for a new employee. Access management comes into the
picture only when the employee makes the first attempt to use the access rights
assigned to him/her (e.g., log into an application).
Identity Management and Access Management have a strong symbiotic relationship. An
organization must adequately manage both of disciplines in order to achieve tangible
benefits.

Identity Management typically includes the following features:
 Identity lifecycle management (including identity creation, modification, removal, archiving,
etc.)
 Attribute generation (including ID numbers, usernames, email addresses, etc.)
 Modelling of access right structures (including roles, groups, resources, rules, constraints, etc.)
 Management and automation of access right requests and related workflows (including follow-
up, approval, delegation, etc.)
 Reporting and auditing
 Delivery of identity data to other parties (a.k.a. provisioning)
Centralized Identity Management solution provides the above-mentioned functionalities to the entire
organization from one central location. This allows not only for cost-effective implementation, but also a
thorough perception of the overall picture – spanning across individual organizational units and IT
systems.
The benefits of centralized Identity Management can be divided into three categories:
1. Better control
• Complete view of users and their access rights
• Complete identity life cycle management
• Prevention of an accumulation of access rights
• Segregation of duties
• Well-defined responsibilities and traceable approval procedures
• Reduction of human errors related to manual work
2. Better operational efficiency
• Less manual work
• Faster time to productive work
• Better ability to manage organizational changes
• Faster and easier auditing and demonstration of compliance
• Faster and easier application development
3. Better end-user experience
• Password change and reset as a self-service in a centralized manner
• Access rights granted quickly and/or automatically
• Access right requests as a self service
• Ability to follow up request handling in real-time

3. Identity Management components
The figure below illustrates the typical components and interfaces of a centralized Identity Management
system. Each one is described in more detail in subsequent chapters.
Figure 1 Typical components and interfaces of an IdM system
3.1. Identity Management core
There is an “engine” in the heart of an Identity Management system, which implements pertinent
policies, processes and workflows. This engine can be configured to meet the needs of an organization
using the management user interface (UI) described in section 3.6.
3.2. Identity store
All the identity-related data (including users, access rights and resources) is kept in an identity store. It
can also be used to store the runtime configuration of the system. Typically, the identity store is
implemented using a relational database, LDAP directory or file system, or combination thereof.
Identity store can only be accessed via the services provided by identity management core, that is,
direct access from outside the IdM system is typically prohibited.
3.3. Source data delivery interfaces
Identity Management system is usually integrated with one or more authoritative source systems. A
prime example is an HR system, which typically provides some information about the employees and
the conditions of their employment, as well as the organizational hierarchy. Other examples include
supplier and contract databases and CRM systems.
The IdM system uses one or more interfaces to import the source data from the source systems. The
implementation of these interfaces typically involves product or technology-specific connectors, as well
as intermediate data storage (e.g., intermediate tables within the database of a source or IdM system).
Also, transferring csv or xml-formatted files is quite common.

The Identity Management core often contains logic that automatically maintains identities and access
rights based on the information received from various source systems. For example, the IdM system can
automatically set up pertinent access rights, including user accounts and mailboxes, for every employee
added into the HR system (see the Appendix at the end of this document for an example). Similarly, the
termination of employment or other contractual relationship typically leads to immediate removal of
existing access rights.
3.4. Identity data delivery interfaces
Identity Management system typically provides identity data to a variety target systems. In practice,
this means replicating the user identities and associated access rights into the IT systems, applications
and other resources, in which the identity and access rights information is ultimately used. This process
is commonly referred to as provisioning. Without the provisioning, changes done within the IdM
system would not have any impact on the users' access rights in real life.
The data delivery interfaces are implemented using either target system specific connectors or generic
provisioning mechanisms. A prime example of the latter is a corporate directory (e.g., Microsoft®
Active Directory®), on which the individual target systems can rely while performing authorization
decisions. The proliferation of service-oriented architectures (SOA) is likely to increase provisioning
based on SOA world standards. Examples include SPML (Service Provisioning Markup Language) and
XACML (eXtensible Access Control Markup Language).
Often, the identity data delivery cannot be automated for each and every target system. In such a case,
the provisioning can be done using email or other work orders. Here, the provisioning is completed by a
party (i.e., a person) responsible for maintaining the target system in question. The majority of the
benefits of a centralized IdM can be achieved irrespective of this manual step.
Figure 2 Identity data delivery interface
Additionally, the identity data delivery interface can be used to relay back target system side changes to
identities and access rights. This process is generally referred to as reconciliation. The purpose of
reconciliation is to keep the identity data consistent across the Identity Management system and various
target systems. Typically the IdM system acts as the authoritative source of all identity data, thus
rendering all target system side changes forbidden. It is, however, possible that some of the identity
attributes, such as a phone number, are maintained outside the IdM system. In such a case, the
reconciliation process would be responsible for delivering up-to-date phone numbers to the IdM system.

3.5. End-user interface
At a minimum, Identity Management system provides end-user community the ability to view, and
possibly maintain, their identities and access rights. In practice, this usually means that the user is able
to see his/her personal data and existing access rights, as well as request for additional access rights
and follow up the request handling. In addition, users in supervisory positions can typically view and
maintain their subordinates, as well as approve their access right requests.
Some of the Identity Management systems also provide the end-users with an opportunity to administer
access right structures (e.g., roles, privileges, policies, constraints and workflows) by themselves. In
such a case, Identity Management can be truly delegated to the end-user community, thus rendering
dedicated user administration resources unnecessary. For example, an application owner could self-
maintain the system roles and privileges associated with that particular application.
In this context, “end-user” refers to not only employees, but increasingly also a variety of “external
users”, such as sub-contractors, partners, customers and, say, external auditors. Typically, the external
users are only offered a limited set of functionalities.
Figure 3 Example of end-user interface
The usability of the end-user interface is of critical importance when delegating the administration of
identities. The end-users must be provided with an interface that is intuitive enough for an average
user. The end-user interface can also be incorporated into an enterprise portal or an electronic desktop
to achieve a seamless user experience.
3.6. Management user interface
Identity Management system administrators are typically provided with a separate user interface, which
can be used to maintain the system configuration. Unlike the end-user interface, management user
interface usually requires familiarity with the underlying products and technologies.
3.7. Management API
It is sometimes necessary to access Identity Management features from other applications and services.
The IdM system may therefore provide an application programming interface (API) for other

applications and services to use. The API may provide, for example, the same features as the end-user
interface. This type of API enables integration with, for example, a GRC solution1
.
On the other hand, the API may provide an opportunity to externalize authorization decisions from
individual target systems. For example, a CRM system can use the API to inquire as to whether “Bob” is
entitled to manage customer “Acme, Inc”. In this case, the centralized IdM system shall make the
decision on behalf of the CRM system – in accordance with the policies and rules defined by the
organization. The most common standard used to implement such functionality is XACML (eXtensible
Access Control Markup Language).
The above-mentioned functionality extends the traditional scope of Identity Management into Access
Management domain. This is by no means a mandatory feature for a centralized IdM system. In fact, it
is possible to set up an IdM system with no management APIs whatsoever.
1
The term GRC (Governance, Risk management and Compliance) is referred to in conjunction with Identity
Management as being a "business control layer" above, which dictates how the identities and access rights should be
maintained. GRC covers, for example, policies and segregation of duty (SoD) rules derived from the business. In such
a case, the role of an IdM system is to implement the above-mentioned policies and rules.

4. Secproof – The IdM expert
Are you looking for a competent partner with strong vision on Identity Management? Do you want to
know how to improve your operational efficiency while reducing the risk and improving security?
Contact us; we are pleased to tell you more.
Our strengths:
 Expertise and experience
Identity Management is our core business. All of our IdM specialists are seasoned agents with
several years of practical experience in various Identity Management initiatives. We are familiar
with the technologies, including the capabilities as well as limitations. We can also tell how the
development initiative should be phased so that it will produce tangible benefits as quickly as
possible.
 Integrity and objectivity
We are independent from specific technologies or vendors. We do not represent individual products
or trade licences. Our task is to ensure that you get the best possible solution. We will tell you if we
feel that some things should be done in a different manner - or even be completely left to be done.
We can also justify and explain our opinions.
 Practicality
Instead of academic paper exercises, we try to achieve tangible results - quickly and efficiently. We
believe that an assignment is successful only if it leads to measurable cost savings and/or reduces
real business risks.
 Versatility
Secproof is also a renowned expert in risk management, continuity planning and security. In
conjunction with our identity and access management expertise, we can offer our customers a
comprehensive vision under one roof.
Our contacts:
Ismo Sillanpää, Sales Director
Hannu Kasanen, Head of Architecture
Email: firstname.lastname@secproof.com
Internet: www.secproof.com

Appendix: Example of a centralized IdM system
This appendix provides a very simple example on how the centralized Identity Management system can
be used to effectively grant access rights to new employees.
Figure Example of a centralized IdM system
The figure above illustrates the on-boarding process of a new employee.
1. The new employee shall be added into the HR system, which acts as the authoritative source
for employee data. In this example, the HR system is built on SAP® technology, to which the
IdM system can be connected using a ready-made connector. Information about the new
employee and the employment shall be automatically transmitted to the IdM system.
2. The IdM system shall establish a digital identity for the new employee, including a unique
username and email address, and stores this information into the identity store. The IdM
system uses the information originating from HR, such as first name and last name, to set up
the identity.
3. The IdM system shall automatically add an account for the new employee into the corporate
directory, which in this example is a Microsoft® Active Directory®. In addition, the employee
shall be added as a member of to appropriate security groups within the directory. As a result,
the employee can access basic IT services available in company intranet, including email and
enterprise portal.
4. The IdM system shall send a work order to Help Desk. The Help Desk personnel shall provide
the employee with access to company premises by delivering a key card and adding the
employee (manually) to a physical access control system (PACS). Access is automatically
granted to the employee’s primary location only.
5. In addition, the employee shall be able to request other access rights for him/herself via the
end-user interface. In such a case, the request shall be sent to employee’s manager and/or
other authority for approval. The employee can monitor the request handing using the same
end-user interface.
Note: Instead of requesting and approving individual access rights, the employee can be
assigned to a role. As a result, he/she shall receive at once all the access rights associated with
the given role. For example, an employee having a “controller” role would gain access to the
annual reports and associated financial data – regardless of where such information is kept.

This kind of Identity Management is generally referred to as role-based access control or
RBAC.
The ultimate goal is to get new employees to productive work as quickly and easily as possible. A new
employee should be able to use the basic IT services, such as email, starting from day one. On the
other hand, centralization and automation of Identity Management will minimize the risk of redundant
or hazardous access rights.

Competence
Common
sense
Success

IdM Reference Architecture

More Related Content

What's hot (20)

Similar to IdM Reference Architecture (20)

Recently uploaded (20)

IdM Reference Architecture