IdM Reference Architecture

3,676 views
3,584 views

Published on

This reference architecture outlines a general solution for a centralized Identity Management (IdM) system without
committing itself to any specific business needs.

Published in: Technology

IdM Reference Architecture

  1. 1. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 Copyright © Secproof Finland 2010 Centralized Identity Management Reference Architecture Hannu Kasanen, Secproof Finland
  2. 2. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 Copyright © Secproof Finland 2010 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.
  3. 3. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 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.
  4. 4. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 2/7 Copyright © Secproof Finland 2010 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
  5. 5. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 3/7 Copyright © Secproof Finland 2010 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.
  6. 6. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 4/7 Copyright © Secproof Finland 2010 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.
  7. 7. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 5/7 Copyright © Secproof Finland 2010 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
  8. 8. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 6/7 Copyright © Secproof Finland 2010 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.
  9. 9. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 7/7 Copyright © Secproof Finland 2010 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
  10. 10. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 Copyright © Secproof Finland 2010 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.
  11. 11. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 Copyright © Secproof Finland 2010 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.
  12. 12. Centralized Identity Management REFERENCE ARCHITECTURE 09/2010 Copyright © Secproof Finland 2010 Competence Common sense Success

×