Best Practices - IAM Solutions · · 2016-10-04Best Practices for Identity and Access Management 1 Introduction This document lays out best practices for identity and access management

Best Practices

for Identity and Access Management

© 2016 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi-ID.com{}/

http://Hitachi.com/

Contents

1 Introduction 1

2 Identity and Access Management 1

2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.2 Other names for the same type of system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Related, but distinct types of systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Business drivers 4

3.1 Internal controls and regulatory compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 Cost savings in security administration and the IT help desk . . . . . . . . . . . . . . . . . . 4

3.3 User service and SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 The intersection of process and integrations 6

4.1 Types of processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.2 Prioritizing processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.3 Types of and priority of integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.4 Integrations that do not manage accounts or entitlements . . . . . . . . . . . . . . . . . . . . 9

4.5 Small account repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.6 Integrations with all IT assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Deployment patterns 12

5.1 Corporate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.2 Partner portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.3 Consumer portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.4 Higher education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.5 Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.6 K-12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Assigning and managing unique identifiers 16

6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.2 New identities and accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.3 Name collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.4 Algorithms to assign user IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

i

Best Practices for Identity and Access Management

6.5 Algorithms to assign e-mail addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.6 Name changes with side effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.7 Mapping existing identities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 Managing other assets 22

7.1 Home directories and mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.2 Onboarding, transfers and deactivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

7.3 Building access badges and other physical assets . . . . . . . . . . . . . . . . . . . . . . . . 23

8 Role-based access control (RBAC) 24

8.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8.2 Motivation for roles: usability, efficiency and security . . . . . . . . . . . . . . . . . . . . . . 25

8.3 Application roles and enterprise roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8.4 Suitability of roles: patterns of access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8.5 Roles, risk management and internal controls . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.6 Initial entitlements versus complete rights model . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.7 Analytics in support of role development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8.8 Lifecycle management of the role model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8.9 Analysis of entitlements and role definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9 Multi-step processes 31

9.1 Onboarding and day-1 activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

9.2 Access deactivation, archive and cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

9.3 Certification and revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

9.4 Transfers with side effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

9.5 Name changes with side effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

10 Automation from authoritative sources 35

10.1 Applicability to user communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

10.2 Timeliness, reliability and granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

10.3 Polling, transaction tables and real-time API calls . . . . . . . . . . . . . . . . . . . . . . . . 36

10.4 Combining data from multiple SoR feeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

11 Integrations 38




11.1 Systems of record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

11.2 Managed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

11.3 Connector operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

11.4 Connector location and timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

11.5 Partial automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

11.6 Manual fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

11.7 Non-identity integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

12 Delegated and self-service management 42

12.1 Delegation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

12.2 Usability and navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

12.3 Visibility and privacy protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

13 Soliciting reliable action from unreliable actors 45

13.1 Human responsiveness versus service level agreements . . . . . . . . . . . . . . . . . . . . 45

13.2 Reminders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

13.3 Concurrent invitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

13.4 Delegation and escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

13.5 Impersonation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

13.6 Checking out of office status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

14 Internal controls and regulatory compliance 47

14.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

14.2 Approval of change requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

14.3 Risk scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

14.4 Access (re)certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

14.5 Segregation of duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

14.6 Returning users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

14.7 Out of band changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

15 Constructing and maintaining org-chart data 52

16 Generalizing policies 54

17 Analytics: trends and patterns 55




17.1 Similar users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

17.2 Related entitlements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

17.3 High privilege and high risk users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

17.4 Busy periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

17.5 Workflow participant load and responsiveness . . . . . . . . . . . . . . . . . . . . . . . . . . 56

17.6 Historical access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

17.7 Data quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

18 Service catalogs and general-purpose request systems 57

18.1 Request origination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

18.2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

18.3 Aggregate queue and trend visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

19 Incremental deployment and IAM programs 60

20 On-premise versus hosted/SaaS IAM systems 61

21 Standards: SAML, SPML and SCIM 62

21.1 Security Assertions Markup Language (SAML) . . . . . . . . . . . . . . . . . . . . . . . . . 62

21.2 Service Provisioning Markup Language (SPML) . . . . . . . . . . . . . . . . . . . . . . . . . 62

21.3 System for Cross-domain Identity Management (SCIM) . . . . . . . . . . . . . . . . . . . . . 63

22 Integration to social platforms and OAuth 64

23 Access from on-premise PC, VPN and mobile/BYOD 65




1 Introduction

This document lays out best practices for identity and access management systems. These systems maybe deployed in a variety of contexts – corporate, customer-facing, partner-facing, etc. These deploymentpatterns are also described.

2 Identity and Access Management

Identity and access management is a term often used by different industry participants – software vendors,integrators, customers and analysts – to mean different things. It makes sense, therefore, to start with somedefinitions:

2.1 Definitions

Following are the most basic definitions relating to identity and access management systems:

• Identity – A digital representation of a person or a purely virtual entity which is managed similarly toa person.

• Account – The representation of an identity on a single system or application.

• Credential – Something used by a person or virtual entity to prove his identity to a system or ap-plication. For example, a password, answers to security questions, a hardware token, a soft token,etc.

• Entitlement – An access right assigned to an account, typically within the context of a single systemor application. Most commonly entitlements are group memberships or application roles.

• Account repository – A database, either published (e.g., as a directory) or internal to a single systemor application, which enumerates accounts, along with related credentials and entitlements for eachaccount.

An identity and access management system (IAM for short) is a system which automates the managementof identities, accounts, entitlements and credentials. These artifacts are managed where they already exist,on one or more account repositories. Automation in the context of IAM refers to the execution of clearlydefined business processes, which have inputs – data feeds or user requests; implement policies; executeworkflows to interact with people and have outputs – integrations to account repositories.

Identity management is prerequisite to account management, which in turn is prerequisite to the manage-ment of entitlements and credentials. In most cases, it is the management of entitlements and credentialsthat is of interest and which yields value to an organization. The management of identities and accounts isa necessary prerequisite, but not very valuable in and of itself.

© 2016 Hitachi ID Systems, Inc. All rights reserved. 1


2.2 Other names for the same type of system

Just as the term identity and access management is sometimes used to refer to other types of systems, sotoo are other terms sometimes used to refer to IAM. These include:

1. Identity management (as though access rights are not also managed).

2. User provisioning (as though onboarding, but not change management or deactivation, is the onlyobjective).

3. Access governance (as though routine administration is excluded).

4. Identity and access governance.

Technically, products in this space are used for administration and governance of identities, entitlementsand credentials, but nobody calls these systems "identity, entitlement and credential administration andgovernance."

2.3 Related, but distinct types of systems

People new to IAM systems sometimes confuse them with related, but nonetheless distinct types of sys-tems:

• Directories – Contain lists of users and other objects, such as groups and computers. Publish thisinformation via a standard interface, such as the Lightweight Directory Access Protocol (LDAP). Di-rectories do not embody any business process – they simply house and make accessible a set ofdata.

• Authentication systems – Used to provide either more convenient or more secure mechanisms forusers to sign into systems, as compared to the passwords built into most account repositories. Theymay include hardware tokens, biometrics, smart cards or apps on mobile phones. Authenticationsystems do not manage any existing identities, credentials or entitlements. Rather, an IAM systemshould manage the directory that underpins each authentication system, and users should be able tosign into the IAM system itself using business-appropriate authentication methods.

• Federated access – A form of single sign-on where a user is authenticated by one service (the identityprovider or IdP) before being able to interact with another service (the service provider or SP). Typicallybased on an XML document standard for assertions about user identities and entitlements, suchas the security assertion markup language (SAML). IAM systems should manage the directory thatunderpins the IdP and users should be able to sign into the IAM system using federated assertions.

• Web single sign-on (Web-SSO) – Older forms of single sign-on, strictly into web applications, whicheither install an agent on each web application or proxy connections between users and web sites.Just like federated IdPs, Web SSO systems normally rely on a directory, which should be managedby the IAM system.

• Password management – Self-service systems allowing users to synchronize multiple passwords toa single value, clear intruder lockouts and reset forgotten passwords. Some IAM systems incorporate



self-service password management, while others may integrate with (e.g., to share integrations toaccount repositories) or simply co-exist. Whereas an IAM system mainly manages identities, accountsand entitlements, password management systems mainly manage credentials.

• Enterprise single sign-on (E-SSO) – Systems which detect login IDs and passwords typed by users,store these and replay them on subsequent logins to the same application. Normally based on "screenscraping" technology on the user’s endpoint device. Require a secure way to store credentials (apassword wallet) and may integrate with authentication systems prior to unlocking this storage. IAMsystems may have to inject passwords for newly created accounts into these systems.



3 Business drivers

Before considering the details of an IAM system, it is important to understand the motivation for automatingthese processes. There are broadly three types of reasons to automate IAM:

1. To improve internal controls and IT security, often in support of audit or regulatory requirements.

2. To reduce IT operating costs, in the form of a smaller team of people managing user access to systemsand applications.

3. To improve user service, in the form of simplified access requests, faster approvals and faster fulfill-ment.

3.1 Internal controls and regulatory compliance

One of the core problems IAM systems address is that users have excess access rights – beyond what isappropriate for their business needs. This may be due to:

1. Unreliable access deactivation processes, which result in orphan accounts (no known owner) or dor-mant accounts (not used, so compromises might go unnoticed).

2. Inadequate change management processes, so that as user needs change over time, old and nolonger needed entitlements are retained rather than revoked.

3. Users whose access rights include "toxic combinations" that allow them to bypass controls processes– i.e., failure to enforce segregation of duties policies.

4. Users whose access rights in aggregate represent high risk.

5. Access rights that are granted without appropriate approval or which are not periodically reviewed.

An effective IAM program should remediate these problems.

3.2 Cost savings in security administration and the IT help desk

Some number of people, either employees or contractors, are responsible for creating accounts and assign-ing entitlements in every organization. Another set of people is responsible for assisting users who havelogin problems, through password reset and unlock processes.

One of the functions of an IAM system is to automate as many of these processes as possible, so thatusers can help themselves or one another and the number of IT staff assigned to these tasks is minimized.Fewer people translates into a direct, measurable cost savings.



3.3 User service and SLA

It can be difficult for users to:

1. Find where to request access.

2. Fill in access request forms.

3. Figure out what entitlements are required.

Once a request has been submitted, it may take too long to approve and too long to complete.

The end result of all this is frustrating, slow access management. This impairs use of systems and appli-cations, as users who need access don’t get it in a timely fashion and may waste time, unable to work,waiting.

An IAM system should make access requests easy to find and complete. It should help expedite theapprovals process and fulfill approve requests automatically wherever possible.



4 The intersection of process and integrations

IAM systems create, manage and deactivate/revoke accounts and entitlements on account repositories.They do this as a consequence of business process. The value of an IAM system is a product of theprocesses it automates and the integrated systems on which these processes have an impact.

Implementing too many things at once is risky, so it makes sense to prioritize both integrations (mainlywith account repositories) and processes. Over time, more integrations are added and more processes areautomated.

4.1 Types of processes

All changes to identities, entitlements and credentials are driven by business processes. These processescan be categorized by two main variables:

1. The trigger. The options are mainly user input, inbound API calls or bulk data import.

2. Participants and how they relate to one another. The main participants are a requester and recipient,but there are often also authorizers, certifiers, escalates/delegates (i.e., people acting on behalf ofothers) and implementers.

The most common processes implemented by an IAM system are:

SoR-driven automation

Process: The IAM system monitors a system of record (SoR), such as an HR repository in acorporation or a student enrollment system at a college and automatically creates,modifies and deletes identities in response to changes in the SoR.

Triggers: Bulk data feed, API call or periodic check of a transaction log.

Participants: Requester is a virtual identity representing the automation process itself. Recipients areusers whose records changed in the SoR.

Self-service requests

Process: A user signs into the IAM system, typically using a web portal and makes a requestwhere he is the recipient. For example, updating his own identity attributes (new phonenumber, etc.) or requesting new access rights.

Triggers: User input on the IAM portal.

Participants: The user is both requester and recipient



Delegated requests

Process: A user signs into the IAM system and submits requests on behalf of others. Forexample, a manager may sign on and request the creation of an identity for a newcontractor, or access rights for an existing subordinate.

Triggers: User input on the IAM portal.

Participants: Two distinct users, related in some fashion that allows one to make a request on theother’s behalf.

Authorization

Process: A user is invited to approve or reject an already requested change.

Triggers: May be triggered by any request that is submitted to the IAM system.

Participants: A requester, a recipient and at least one authorizer. The authorizer may be chosenbased on the identity of the other recipients (e.g., manager of one of them), or becauseof a relationship to a requested entitlement, or because he is assigned to a policy or arisk-related process.

Certification

Process: A user is invited to review the identity and entitlement data for one or more users andeither accept it or ask for some items to be revoked.

Triggers: A schedule (e.g., periodic, bulk reviews) or an event (e.g., a transfer).

Participants: The certifier is related either to an entitlement (e.g., group owner) or to users beingreviewed (e.g., manager, department security liaison, partner representative, etc.).

Manual fulfillment

Process: A user is asked to manually complete a task that was already requested, validated andapproved but could not be completed with automation (connector not yet deployed or noteconomical).

Triggers: May be triggered by any request that is submitted to the IAM system for which noconnector has been configured.

Participants: The implementer is related to an entitlement or similar asset (e.g., building accessbadge, etc.). May in some cases be related to the recipient (e.g., verify completion oftraining, etc.).

4.2 Prioritizing processes

Most organizations try to maximize the impact of their IAM system while minimizing the number of usersinvolved. This is because user engagement can be costly, due to training, awareness programs and support.Moreover, many users have low tolerance for problems with systems they use, and newly deployed systemstypically experience a few problems when first deployed.

With this in mind, it’s reasonable to begin with SoR-driven automation if possible. Next, depending on thebusiness drivers (cost/service versus security/controls), the next phase may be delegated access man-agement or access certification. Self-service access requests and profile updates are usually rolled outlast.



Within the context of a request portal, most organizations deploy first to IT security staff, as they are a moretolerant community of users and may provide valuable feedback about problems, usability, etc. before thewider user community is invited to use the system. Next may be the entire IT group, for the same reason.Managers usually follow, as they make the most requests and are often invited to participate as authorizers.Users acting in a self-service capacity are usually engaged last, as they are the largest community, mayrequire the most support and may have the lowest tolerance for problems.

4.3 Types of and priority of integrations

Just as there are multiple types of processes that an IAM system can automate, so there are many kinds ofintegrations that can be deployed.

Account repositories may include any of the following:

1. Systems of record, such as PeopleSoft HR, SAP HCM or Ellucian/Banner.

2. Directories, such as Active Directory or other LDAP implementations.

3. Operating systems, including Windows, Unix, Linux, iSeries/OS400 or zOS/RACF-ACF2-TopSecret.

4. ERP applications, such as SAP, Oracle eBusiness Suite or PeopleSoft.

5. Database login accounts, such as Oracle, Microsoft SQL Server, DB2/UDB, Sybase ASE or MySQL.

6. Applications where user, entitlement or credential data is stored in database tables (other than ERPs,already mentioned above, and other than database login IDs).

7. Software as a service (SaaS) applications, such as Salesforce.com, Concur, WorkDay, WebEx, GoogleApps or Microsoft Office 365.

Other systems which should be managed, but may not have login accounts include:

1. On-premise e-mail systems, such as Microsoft Exchange or Lotus Notes – to create and manage mailfolders and aliases.

2. Filesystems – to create and manage home directories.

3. Strong authentication frameworks, such as RSA ACE/SecurID or Duo Security – to assign credentialsto new users and revoke access when people leave.

4. Building access badge systems (many types, few standards) – to grant and revoke facility access.

Most organizations prioritize integrations based on some combination of user population (the more widelyused a system, the higher its integration priority) and change frequency (higher priority for account reposito-ries whose user populations change rapidly). For example, AD and SAP may be integrated in a first phase,followed by systems with fewer users, such as iSeries or Linux.



4.4 Integrations that do not manage accounts or entitlements

Most integrations in an IAM system are user-centric. They include account repositories and systems thathouse other user-assigned assets, such as home directories, e-mail folders or authentication services.

Some IAM systems are also required to integrate with systems where no user-assigned assets will bemanaged. This includes:

1. E-mail systems, in the sense of sending notifications and invitations to users, rather than in the senseof managing mail folders.

2. Incident and request management systems, such as ServiceNow or Remedy. These integrations aretypically to create matching records on these systems, denoting activity that already took place on theIAM system, so that reports run on these systems include IAM-managed user service events.

3. Security information and event management (SIEM) systems, also to record incidents that happenedon the IAM system on common infrastructure.

4.5 Small account repositories

The account repositories mentioned above are assumed to each house logins for a sizable subset of anorganization’s total user community. For example, most corporate users have an AD account, a mail folder,etc. More generally, in a typical organization there are a small number (normally well under 100) of systemsand applications that each contain a sizable user population.

At the same time, most organizations also have a large number of much smaller account repositories.These may be specialized applications accessed by very small user communities or IT infrastructure –laptops, servers, network devices, etc. where only shared administrator accounts exist.

The relative sizes of various types of account repositories are illustrated in Figure 1.

For business user login accounts on small, specialized applications, integrations are often uneconomical(e.g., 3 days of consulting fees to automate integration with an application that only has 10 users). Instead, itmakes sense to bulk-load data into the IAM system regarding applications and their owners, to ask ownersto enter accounts lists into the IAM system and to require owners to complete changes to accounts andentitlements manually. This way, there is a single system to request and manage access to all businessapplications (large and small), but tasks are completed automatically or manually, based on what makeseconomic sense.

4.6 Integrations with all IT assets

IT assets where there are only a small number of accounts and where the accounts are more often shared/-generic rather than belonging to individual business users include:

1. Operating system images, typically running Windows or Linux. These are often just the runtime plat-form for databases or applications, where users may have accounts. Local accounts are administratoror service accounts, rather than personal user IDs.



Number

of accounts

per repository

Number

of account

repositories

1-10 10-100 1000+

1-100

100-1000

1000’s

Privileged accounts

on all systems

Small, specialized

applications

Corporate directory,

on-premise and SaaS apps,

Mainframe and legacy systems

Figure 1: Relative sizes of account repositories

2. Hypervisors, hosting the above – VMWare, Xen, Hyper-V, etc.

3. Database servers – Oracle, Microsoft SQL Server, IBM DB2/UDB, etc.

4. Network devices – routers, switches, load balancers, etc.

While this is rarely an early priority, eventually some IAM systems grow to include integrations to all ITassets, including the above.

Such integrations are first the responsibility of a privileged access management (PAM) system, whosefunction is not to create/delete accounts or assign/revoke entitlements, but rather to connect authorizedusers to pre-existing, shared, privileged accounts on these systems. Eventually, organizations may expandthe PAM functionality to include:

1. Lifecycle management for application or service accounts – i.e., developers or application teams re-questing the creation of database connection accounts, application service accounts, etc.

2. Managing the lifecycle of the ownership of systems and service accounts.

Since the number of integrations can be very large – e.g., thousands of systems of each type – infrastructureborrowed from privileged access management systems is required:

1. Automatic discovery of systems, for example based on data in a configuration management database(CMDB) or directory.

2. Automatic, policy-driven onboarding and removal of managed endpoints.



Automatic onboarding and deactivation of IT assets, to support lifecycle management of service and em-bedded accounts is illustrated in Figure 2.

Rules:onboard?

credentials?

Rules:attach topolicies

Connector

Authoritativesource: listof systems

ManagedEndpoint

ManagedEndpoint

Connector

Onboardingprocess

Classificationprocess

Discovered Accounts,Groups, Services

Managed Accounts,Groups, Services

Figure 2: Auto-discovery of managed systems



5 Deployment patterns

In the past, every IAM system was deployed and configured starting with a blank slate. Over the years, ithas become evident that most deployments fall into one of just a handful of patterns.

It makes sense for IAM vendors or integrators to offer pre-configured IAM systems that take these patternsinto account. This way, each deployment starts with an initial configuration which tries to match the desiredend state as closely as possible. What remains is then integration with the given organization’s accountrepositories and minor changes to attribute mappings, policies, user interface branding, etc. This approachcan eliminate 90% or more of the consulting fees associated with implementing an IAM system.

Following are the most common deployment patterns for IAM systems.

5.1 Corporate

User community: Employees and contractors

Typical scale (users): 1000 – 100,000

Business processes: • Users typically have directory, e-mail and application logins.• SoR-driven onboarding and deactivation for employees.• Request-driven onboarding and deactivation for contractors.• Users have definite reporting relationships to their managers.• Periodic access recertification of all users, including who they report to and

what access rights they have.• Departments and location for each user, and transfers.• Both scheduled and immediate deactivation.• Leaves of absence.• Detect and manage inadvertent rehires. Either re-enable an existing profile

or block the user’s return, as appropriate.• Self-service password management and updates of contact information.• Self-service requests for access to applications and groups.• Access may be granted directly (groups, accounts) or via roles.• Authorization required for many changes, sometimes by multiple approvers.



5.2 Partner portals

User community: Business to business


Business processes: • Users are generally identified by their fully qualified e-mail address, whichshould be validated by sending it a validation token during the onboardingprocess.

• Passwords likely do not expire, but accounts may be disabled after anextended period of inactivity.

• There is no SoR and consequently no automated onboarding/deactivationfor smaller partner organizations.

• Larger partners, with at least hundreds of users, may provide periodic SoRdata in the form of uploaded files and may integrate portal logins usingfederation (e.g., SAML).

• Each partner should designate at least one administrative user, who is thentasked with creating, deleting and supporting other users within the sameorganization.

• Users within any single organization can only see the profiles of other usersin the same organization.

• Partner admins can reset passwords for their own organization’s users.• Partner admins are periodically invited to recertify the validity of other users

in their organization. It is assumed that, otherwise, they will forget todeactivate access for departed users.

5.3 Consumer portals

User community: Business to consumer

Typical scale (users): 100,000 – 10,000,000

Business processes: • Users are generally identified by their fully qualified e-mail address, whichshould be validated by sending it a validation token during the onboardingprocess.

• Passwords likely do not expire, but accounts may be disabled after anextended period of inactivity.

• If there are pre-existing consumer relationships (e.g., banking, insurance,etc.) then automation is used.

• For net-new users, onboarding is driven by self-service requests, whichshould be authenticated either via social platforms (OAuth) and/orhumanness tests (CAPTCHA).

• Users may establish either a new, local password or may leverage anexisting account on a social platform (Facebook, Google, etc.) as a logincredential.

• User profiles are very simple – containing very limited data. The main userfeatures are enrollment of security questions and self-service passwordreset.



5.4 Higher education

User community: Students, faculty and staff

Typical scale (users): 10,000 – 500,000

Business processes: • Multiple communities of users, with some overlap, but where eachcommunity is managed separately.

• Automation drives onboarding/deactivation of students, alumni (fromenrollment system).

• Separate automation drives onboarding/deactivation of faculty, staff (fromHR)

• Each user may have multiple affiliations – e.g., staff in one department,student in another, researcher in a third, etc.

• Self-service and delegated (per school, faculty or department, or globally)password reset processes.

• Role-based access control may be driven by affiliation, course enrollment orproject affiliation.

• Mainly self-service access requests, auto-approved by affiliation or routed todepartmental staff.

• Often significant autonomy between organizational units.

5.5 Healthcare

User community: Caregivers in one or more hospitals


Business processes: • Caregivers and staff are automatically provisioned and deactivated based onan HR feed.

• Physicians and others with facility privileges may also have access, in whichcase they must be provisioned and deactivated by an access administrationteam.

• Self-service and delegated access requests and password reset.



5.6 K-12

User community: Students and parents, teachers and administrators

Typical scale (users): 10,000 – 300,000

Business processes: • Students typically identified by their student numbers, parents by their fullyqualified e-mail addresses and faculty/staff by employee numbers of networklogin IDs.

• At least two systems of record: faculty/staff and students driving automatedonboarding/deactivation.

• For students and parents, system interactions are mainly security questionenrollment and self-service password reset.

• Teachers may be able to reset passwords for students and onboard profilesfor their parents.



6 Assigning and managing unique identifiers

When creating new identities (onboarding) or adding login accounts to existing users, unique identifiersmust be assigned. In some cases, these identifiers are externally sourced – from a system of record suchas HR or via an access request form. A variety of best practices apply to the processes of generating,reserving and reusing identifiers.

6.1 General

Unique identifiers should follow some best practices:

1. Short and memorable: Identifiers should be easy for users to remember and type. If the identifieris based on identity attributes, such as the user’s name, attributes should be selected based on theirtendency to change. For example, given name is a better choice than surname, as people oftenchange their surname as a consequence of marital status, but rarely change their given name.

2. Stable: If possible, it is best to choose identifiers that never change. Such identifiers are typicallynumeric. By choosing a stable identifier, organizations can avoid having to orchestrate rename pro-cesses. For example, if a user’s ID is based on their surname, whenever they change their name(marriage, divorce, etc.) there may be impacts on audit records, home directory path, e-mail address,etc. Managing these changes can be complex and costly, so is best avoided if possible.

3. Persistent: Once assigned to a user, an identifier should never be assigned to anyone else, evenafter the user has ended their relationship with the organization. Moreover, if a user leaves and laterreturns, the same identifier should be reassigned. This creates continuity in audit records.

4. Consistent: Existing identifiers should be (re)used rather than creating new ones. This simplifiessystem interaction for users and makes it easier to correlate audit data between systems. This canhave consequences on how identifiers are generated, to ensure compatibility with the largest possiblenumber of systems.

6.2 New identities and accounts

New identities must be assigned at least one unique identifier. Following are some best practices for thisprocess:

1. Leverage users’ pre-existing identifiers: Users from outside the organization, such as consumers/-customers, business partners or parents usually already have an e-mail address. This is guaranteedto be both globally unique and memorable, so is an excellent choice for identifiers for a new user.Likewise, employees normally have an employee number, which can be used as a primary identifier.

2. Use the same identifier everywhere: Some organizations assign different login IDs to the sameuser, on different account repositories. This is inconvenient for the user and complicates later auditsand security event correlation. It is better to choose identifiers that are compatible with all accountrepositories and assign the same user the same identifier everywhere.



3. Reserve identifiers: Early in the process of onboarding a new user or creating a new account, theidentifier for that user or account should be reserved. This eliminates the risk that two requestsprocessed in rapid succession, either for the same recipient (impatient requesters) or for two similarlynamed individuals, will result in either two people getting the same identifier or one person getting twodifferent identifiers.

4. Clean up reservations: Once an identity has been created, the entry associated with the accessrequest in the reservations table can be removed, as it becomes redundant vis-a-vis account reposi-tories. Identifiers linked to abandoned requests, which were never completed, can also be released,free for assignment to new requests. In fact, the only scenario where an identifier assigned to oneuser should ever be available to assign to another user is if the initial assignment was associated withan abandoned request and never provisioned to account repositories.

5. Check if new users are actually returnees: Requests to onboard a new user should always bechecked to see if the new user is, in fact, new. It’s always possible that a request to onboard a newuser is actually related to the return of a previously departed user, in which case the old identity shouldbe reactivated. Returnees can be identified by retaining profile data about all users, both active anddeparted, and comparing attributes such as name, date of birth, social security number, mobile phonenumber, personal e-mail address, etc.

6.3 Name collisions

New identifiers are often based on a user’s name – for example, a combination of some number of lettersfrom the user’s first and last names. Algorithms that generate new identifiers from names may sometimestry to assign the same identifier to multiple users. This is called a name collision.

Name collisions must be resolved, to avoid assigning the same identifier to two people. This can be donein one or both of two ways:

1. Change the algorithm when a collision happens.

2. Append a suffix or insert a prefix to make the generated ID unique.

For example, Jane Smith might at first be assigned the ID jsmith. If there is already a jsmith, thealgorithm could try other variations: smithj, smithjane, janes, etc. If that fails (more collisions), it couldassign jsmith01, jsmith02, etc.

While the above example is common, as mentioned earlier, using a numeric identifier eliminates this prob-lem. Jane Smith could simply be assigned 001335 with no risk of collisions. If the name attribute mustbe used as part of the identifier (users like this as name-based identifiers are more memorable), assigningjane01 is often better than jsmith since Jane Smith may well change surname at marriage or divorce,but is less likely to become Mike Smith.

6.4 Algorithms to assign user IDs

The best user IDs are short, easy to type, stable and do not collide. In other words, short sequences ofdigits. E.g., 001335.



Second best are IDs based on a user’s name. First names or nicknames are better than surnames becausethey change less often. Since names do collide often, it makes sense to add some digits to make themunique. E.g., jane02.

IDs based on surname are possible, though they change more often so are less desirable. E.g., smith02.

IDs based on department or job function are not recommended, since people are almost certain to changeroles within an organization and triggering changes to user IDs at each role change is too much work.The only exception to this is shared or functional IDs, that are used by automated processes or shared bypeople, but which do not represent individual people. E.g., db_backup.



6.5 Algorithms to assign e-mail addresses

Users are commonly assigned e-mail addresses. Most users and most organizations prefer addresses thatare based on a user’s full name, such as [email protected]. This is a good format where thereare no collisions, but it causes problems (a) when people change their names and (b) where multiple peoplehave the same name.

A more scalable approach is to append two random, unique letters or digits to all e-mail addresses. E.g.,[email protected] where hl is randomly assigned (not sequential or meaningful). Thisworks better than digits such as 01, 02, etc. because people will more easily misremember digits thanrandom letters. This strategy also has the benefit of blocking spam e-mails to guessed addresses.

6.6 Name changes with side effects

As mentioned above, people do sometimes change their names. Where identifiers are based on a user’sname, they should change to match. This leads to some required side-effects to name changes:

1. If a user’s name changes, and their login ID is based on their name, then they should be assigned anew login ID based on the new name.

2. If the user’s login ID changes, and it forms a part of their home directory path, then the home directorymust be moved.

3. If the user’s e-mail address changes (typically as a consequence of a name change), then their previ-ous primary e-mail address(es) should be retained as (an) alias(es), and a new primary e-mail addressassigned, based on the user’s new name. Users should retain old e-mail addresses indefinitely, sincethere is no way to predict how long people they correspond with will retain their old address and it isundesirable for e-mails intended for the users whose name changed to be incorrectly routed to newusers who "inherited" their old e-mail address.

Changes to user IDs are often fragile, since IDs may be embedded in scripts or other infrastructure (ex-ample: job scheduler metadata). There is no way for an automated user ID rename process to find andremediate every instance of a user’s old ID, across an entire network. Changes to user IDs should there-fore be handled with care, and preferably with human oversight, to identify and resolve problems with IDsembedded in scripts or infrastructure.

6.7 Mapping existing identities

IAM systems are rarely deployed into clean or empty environments. Depending on the style of deployment(corporate, partner, consumer, etc.), users may have multiple login accounts on multiple systems. Whereusers have multiple accounts on different systems, those accounts may have different login IDs. This maybe due to different practices by different platform administrators (Unix versus Windows versus ERP, etc.), orchanges in the standard naming system over time (default ID format changed after the user was onboardedand before at least one new account was created), or previous mergers (IDs in one organization do notmatch IDs in another).



Where users have different login IDs on different systems, these different IDs must be mapped to aggregateuser profiles, so that all of a user’s entitlements can be managed together.

There are several possible strategies for ID mapping. Which strategy to use depends on the available data:

• Leverage existing mapping data:

This is the simplest approach. It works where some process has already been in place, typically formany years, to track ownership of every ID on every system. The IAM system can simply consumethis source data and map IDs accordingly. The approach works only where the data exists, and isboth comprehensive and trustworthy.

• Match identity attributes on accounts:

Where there is no mapping data, but where accounts on each system have sufficient attribute datato link to one another, attribute based mapping can be used. For example, if every login ID on everysystem has an employee ID attribute, then accounts can be mapped to their owners using this data.Ideally, the mapping attribute is uniquely identifying, reliable and reliably populated.

In practice, these conditions are rarely met, so attribute-based mapping may be based on weaker data,such as the user’s name. Mapping on name is problematic for several reasons: user names may beinconsistently entered (case, spaces, spelling mistakes) which causes failures to match. Worse, inlarge organizations there are often multiple people with exactly the same name (Michael Smith iscommon in English, for example). This can lead to incorrect matching, which can lead to securityproblems later, due to access being inappropriately granted to or revoked from the wrong profile.

In short, where name-based matching is used, extra care is required to find approximate matches andto inspect potentially duplicate matches, to avoid security and operational problems.

• Ask users to map their own accounts:

Users must know their own login IDs and passwords, or they would be unable to sign into theseaccounts. Based on this premise, a viable strategy for mapping IDs to their owners is simply to askusers. This is not as simple as it seems, however:

– Users may not know what the system that they sign into is called. For example, IT may think ofthe mainframe security product as RACF but users may think it’s called Attachmate (a commonterminal emulator).

– Users may not want to be bothered providing this information.– Users may be malicious (or just mischievous) and claim ownership over accounts that they do

not own.

To address these problems, an IAM system that asks users to attach their own IDs to their own profilesmust:

– Remind users to enroll. Automatically send e-mails and possibly other types of invitations,asking them to enter their various user IDs.

– Give users an incentive to enroll, by offering some sort of reward. Most commonly, this ispassword synchronization, i.e. users who attach their IDs to their profile will be able to moreeasily set one password across multiple accounts – a significant convenience.

– Validate ownership of claimed accounts. This is done by asking users to enter both an ID andpassword. The IAM system can connect to the system in question with the credentials provided.



If the login works, the user has demonstrated ownership of the account in question, and it is safeto attach that account to the user’s profile.

– Avoid system names. Prompt users for login credentials without reference to what system theuser normally signs into. The IAM system should be able to infer what systems contain an ID likethe one the user typed and which of these IDs have no known owner. It can then test login toeach of these systems with the provided credentials to see which one(s) belong to the user. Thiseliminates the need for users and the IAM system to agree on what a given system is called.

This strategy is the most generally applicable, as it does not require pre-existing or reliable mappingor attribute data. That does not make it simple, however – a robust program for engaging users andsoliciting action is required.

Regardless of the strategy chosen, many systems have login IDs that do not belong to human users. Theseinclude service accounts, shared administrator accounts, guest accounts, test accounts, accounts used byone application to connect to another, etc. These may also include orphan and dormant accounts – whichbelonged to people in the past but should be (and may not have been) deactivated. Most of the abovestrategies only work for actively used, human accounts. Some number of accounts, either inactive or notassociated with humans, will be left unassociated and must be assigned an owner manually.



7 Managing other assets

Identities, entitlements and credentials are managed as a consequence of lifecycle events – onboarding,departures, transfers, etc. At the same time that users move through these processes, artifacts beyondjust login accounts need to be created, updated, archived and deleted. It makes sense to automate themanagement of these artifacts at the same time as automating the artifacts of login IDs.

7.1 Home directories and mailboxes

In some IAM contexts, users get home directories and e-mail mailboxes. This is most commonly true ofcorporate IAM systems, serving employees and contractors. B2C and B2B systems rarely use these assets,but higher education and K-12 systems often do.

Where users are commonly assigned these assets, it makes sense to create, manage and deactivate themwhen automating other IAM functions, like creating and deleting accounts. This increases the impact of theIAM system in terms of reducing the cost of manual administration and improving SLA.

When managing home directories and mailboxes through automated processes, it is important to implementrules regarding where to place these assets:

1. Based on user location.

2. In some cases, also based on organizational structure (department, corporate subsidiary, etc.).

3. In some cases, also based on free disk space.

These rules are most simply articulated as lookup tables, e.g. given a user’s location and organizationalaffiliation, look up the appropriate parent folder for the user’s home directory, mail database and mail server,etc.

7.2 Onboarding, transfers and deactivations

When adding integrations to manage assets such as home directories, e-mail folders, building accessbadges, etc. it is tempting to focus only on the onboarding process. However, it is important to alsoconsider other user lifecycle events, including transfers (especially to a different location) and terminations.

For example, when a user is transferred to a different location, it may be appropriate to move that user’shome directory to a share or folder on a server closer to the user’s new location. The same is true for mailservers – users benefit from proximity to a mail server.

Termination processes are often more complex than onboarding because they involve multiple steps, spreadover a long time period. Consider this:

1. Before a scheduled termination date, the user’s manager should be reminded of the impending deac-tivation and given an opportunity to defer it (change the date).



2. On a scheduled termination date, access should be disabled but entitlements and other artifacts leftin place, in case the deactivation is in error and access needs to be reactivated.

3. After a cooling period, artifacts such as mail folders and home directories should be modified so thatcontent is accessible to interested parties. For example, ownership may be changed to the user’smanager, access permissions set to read-only and the artifacts may be moved to a different location.

4. After a further cooling period, accounts and perhaps other artifacts may be deleted. Identity attributesshould be retained, however, to support checking for a return of the same user.

7.3 Building access badges and other physical assets

In the context of a corporate IAM system, the idea of automating as many steps as possible in user lifecyclechanges is appealing. This may include allocating a building access badge to new hires, configuring aphysical access control system (PACS) so that the user gains access to appropriate parts of just the rightbuildings, etc. Onboarding often also includes allocating physical space (e.g., an office or cubicle), activatinga phone line and network port, assigning and imaging a PC, delivering a physical desk phone, ensuringthere is adequate furniture (desk, chair) in the user’s location, assigning software licenses and more.

There is usually an incident or service request system in place as well as an IAM system, so the question is:which system should be used to manage requests for every type of asset? Separately there is a questionof which system should originate requests, especially for onboarding new and deactivating existing users.The question of request origination is discussed in greater detail in Subsection 18.1 on Page 57.

In most cases, it’s probably best to leave service provisioning to the existing request management system,especially if the request is for something physical, like a PC, desk or phone, where the IAM system doesnot add much value. There are some edge cases where IAM integration can make sense, however:

1. Allocating new and releasing old software licenses – the IAM system could send the relevant eventinformation to whatever license management system is in place.

2. Assigning building access badges to new users and collecting them from departed users – inexpen-sive assets are often not efficiently tracked in other applications, so the IAM system can be used to"close the gap" by tracking individual small items (such as proximity badges) by location, assigneduser, serial number and responsible individual.

3. Assigning users physical access to relevant parts of buildings. This is essentially like role basedaccess control, where users are assigned roles based on their location and business needs. This isoften a low priority integration, however, for two reasons:

(a) Most medium to large organizations occupy multiple buildings, which are commonly leased. Eachlandlord may operate a different PACS in each building, so PACS integration may actually meanintegration with many different PACS systems, each of which only supports a modest user pop-ulation.

(b) PACS systems are normally deployed when a building is constructed or undergoes significantrenovations. As a result, they are frequently in operation for multiple decades between upgrades.As a consequence, there are many very old PACS systems in use, many of which have nointegration capability, or, at best, have very old and hard-to-integrate APIs.

Because of these challenges, PACS integrations are often uneconomical.



8 Role-based access control (RBAC)

In corporate environments, organizations may employ many users and each user may be assigned manysecurity rights. The assignment of a security right to a user is an entitlement and the number of entitlementsis correlated to the product of the number of users and the number of available entitlements.

Roles are defined to reduce the number of entitlements that must be managed. A role is a named collectionof other entitlements. If many users need the same set of entitlements, it can be simpler to define a rolethat includes those entitlements and assign it, rather than the individual entitlements, to the relevant users.This simplifies the management process – there are fewer things to manage. This can also make requestsmore user friendly, where roles are assigned business-friendly names.

The complexity of assigning security rights directly to users and the leverage that roles can add to theprocess are illustrated in Figure 3.

Before:

Complex!

Users Entitlements

Simpler!

BrowseVendors

After:Users Roles Entitlements

DeleteVendors

AddVendors

EditVendor

BrowsePayments

AddPayments

CancelPayments

BrowseVendors

AddVendors

DeleteVendors

EditVendor

VendorManagement

PaymentManagement

BrowsePayments

AddPayments

CancelPayments

Figure 3: Using roles to simplify access management

8.1 Terminology

Many participants in the IAM industry use a single term – role – to refer to two distinct concepts – organiza-tion structure and collections of entitlements – using the same term: role. Using one label for two conceptscan lead to confusion and bad designs, which in turn can lead to project risk, cost and schedule overruns.

To avoid these problems, it is important to define clear terminology, as follows:

• A security group is a set of people that exists on a managed system or directory and to which securityrights have been assigned. For example, Active Directory has security groups, SAP has activity



groups (also, confusingly, called SAP roles), RACF has group profiles, etc. The general term for all ofthese and their equivalents on other systems is simply ’security group.’

• Entitlements are low level security rights that can be assigned to users. On almost all systems,entitlements are either login accounts (e.g., AD account, RACF login, SAP user, etc.) or securitygroup memberships.

• Roles are named collections of entitlements. They may contain login accounts, security groups orother roles. The ability of a role to contain other roles means that a role hierarchy can be defined (rolenesting is another term for this).

Note that none of the above makes any mention of an organizational structure. The terms above all relateto entitlements, either as they exist on target systems or how they are aggregated within the IAM system.

There are separate terms relating to organizational structure and the relationships between people:

• A user class is a set of users (i.e., identities or people). Users might be added to a user classindividually, but the more common scenario is to group users with a rule – for example, based on theirdepartment, location, business unit, etc.

• An organizational hierarchy is a linkage between users or containers. For example, users may belinked to their direct managers, creating a hierarchy of people. Departments may be connected toother departments, creating a hierarchy of people-containers.

Clear terminology supports clear definitions of processes, such as the following

• Roles or group memberships can be automatically assigned to members of user classes.

• Members of a user class may be invited to approve the assignment of entitlements.

• Managers may be invited to review the entitlements of their subordinates.

8.2 Motivation for roles: usability, efficiency and security

Assigning entitlements indirectly, through roles, rather than directly, is intended to produce the followingbenefits:

• Usability:

Entitlements on systems and applications often have obscure, hard to understand names. Replacingthem with business friendly role names simplifies the request process for business users. Moreover,it is anticipated that requests will include fewer parts where roles, rather than individual entitlements,are used.

• Efficiency:

By assigning multiple entitlements at once, it is possible to accomplish more in less time – improvingthe efficiency of access administration staff.



• Security:

If roles capture exactly the access rights that users who fulfill a given business function need toperform their job, then assigning them only the appropriate role ensures that they have only the accessrights they need, and nothing more. This supports a policy of least privilege.

8.3 Application roles and enterprise roles

Most nontrivial applications already incorporate a role model. This includes SAP (activity groups and roles),Oracle eBusiness Suite and others. For clarity, roles or similar structures that exist inside a single applicationare referred to as application roles.

This can be looked at another way – only applications that expose very few access rights, or applicationswhich have many access rights but whose security model is poorly designed, do not have application roles.

An IAM system should assign access rights at the highest level of granularity exposed by each system orapplication. In the simplest applications, it only creates or deletes accounts. In more complex systems, italso assigns and revokes group memberships. In the most complex systems, it should assign and revokeapplication roles.

From the perspective of integration with an IAM system, application roles are no different than groups – theyare security rights that may be assigned to an account in the context of an account repository.

Enterprise roles are collections of entitlements defined on an IAM system. Because an IAM system may beintegrated with multiple systems and applications, enterprise roles may include entitlements on more thanone account repository – such as groups on simple systems and application roles on complex applications.Because of this, enterprise roles can be used to model all of the access rights required to perform a givenjob function, rather than only the rights required for a function within a single system or application.

8.4 Suitability of roles: patterns of access

Roles can provide powerful leverage to make access management more efficient, secure and user friendly.Because of this, some people assume that roles should always be used, and are foundational to the imple-mentation of IAM systems.

In reality, the power of roles arises only when many users need exactly the same set of entitlements. Rolesprovide leverage by reducing the linkages between users and entitlements, as shown in Figure 3. Where toofew users share the entitlements in question, the leverage diminishes. In the extreme case where exactlyone user needs the entitlements in question, roles actually reduce efficiency, by adding a layer of indirectionbetween a single user and his entitlements, which is of no value when managing the entitlements of anyother user.

Complex organizations that attempt to model the access needs of all users with roles may find that thenumber of roles exceeds the number of users. This is clearly undesirable.

This leads to the question: how many roles should an organization strive to define? Alternately, at whatthreshold should a role be defined – i.e., how many users should have shared needs before a role makessense to help manage their entitlements? There can be no hard and fast answers to these questions –every organization is different, but a reasonable rule of thumb for a moderately complex organization is to



define no more than 100 roles, making sure that each role pertains to at least 10 people.

8.5 Roles, risk management and internal controls

A belief shared by many IAM practitioners is that using roles to manage entitlements is necessary, andpossibly sufficient, to improving internal controls and complying with regulations.

It is true that, if a role is carefully designed, it should contain only the entitlements required to perform agiven function. If user access rights are managed using only such roles, it follows that users will have justthe right entitlements, and this is certainly beneficial for security.

As mentioned above, roles are really only economical when they apply to many users. In most organiza-tions, there are certain segments of the user population that fit this description. For example, point of salesstaff at a retailer, tellers at a bank, nurses at a hospital, etc. It makes sense to manage the access rights ofsuch users with roles.

In practice, it is not these users who represent the highest risk to most organizations. In a financial institu-tion, risks arise from rogue traders or data analysts with access to extensive customer records. At a retailer,finance department staff probably represent the highest risk. At a hospital, it may be someone with accessto bulk patient data, rather than one record at a time. The users described here are members of small sets,and in many cases unique within their organizations. In other words, the more suitable roles are to a givencommunity of users, the less likely it is that the users in question pose catastrophic risks to the organization.

In most cases, regulations are concerned primarily with catastrophic failures in internal controls – includingbulk compromises of privacy related data, large and unauthorized financial transactions, compromisedclinical or technical data, etc. It follows that, while role based access control is a useful tool, because itfocuses on large communities of shared-needs users, it is not especially helpful for regulatory complianceor in general to manage the most serious risks.

Other mechanisms, such as segregation of duties policy enforcement, risk scores, access recertification,approval workflows or data loss prevention are more suitable tools for mitigating risks of catastrophic con-trols failures.

8.6 Initial entitlements versus complete rights model

When a role is assigned to a user, the user is assigned the entitlements that are members of that role.There are options regarding what comes next, however:

1. The role can be assigned such that its entitlements represent all of what the user gets. If the user hadother entitlements, they are revoked.

2. The role can be assigned in a permanent manner, such that changes to the role definition – adding orremoving entitlements – is automatically reflected in the entitlements assigned to every user who hadbeen assigned the role.

Whether roles should be used just to assign entitlements initially, or to manage the evolution of user enti-tlements over time, depends on the type of user in question. Users who are frequently reassigned through



an organization, or who move between projects, have entitlements which are difficult to manage with roles.These users may benefit from initial role assignment, but will soon acquire legitimate exceptions to the role– often just additional entitlements. On the other hand, users with rigidly defined job functions may notrequire any exceptions. Their entitlements may be more efficiently managed by requiring them to exactlymatch the definitions of one or more assigned roles.

8.7 Analytics in support of role development

If an organization plans to use roles to simplify entitlement management, then both roles and user classesneed to be defined. This can be a daunting task, where thousands of users perform hundreds of jobfunctions.

Analytics can help address this challenge, but cannot eliminate the need for human judgment:

1. Clusters of users who share values in attributes that might predict their job function can be automati-cally identified. For example, an IAM system can be asked to identify groups of users who share thesame location and department, or the same department and job code. These groups of similar usersare candidate user classes.

2. Clusters of entitlements that are co-assigned can likewise be identified. For example, an IAM systemcan be asked to identify all entitlements that are commonly co-assigned with one or two manuallyselected entitlements. These groups of co-assigned entitlements are candidate roles.

If a set of users are all already assigned the same entitlements – i.e., if a candidate user class materiallyoverlaps with a candidate role, then both a role and a user class can be defined.

In practice, data quality limits the effectiveness of this approach:

1. Users often have inappropriate or no longer needed entitlements.

2. Users attribute data may be incorrect or obsolete.

As a consequence, there are rarely "perfect matches" in either the user class or entitlement cluster analysis.When defining roles and user classes, it is therefore often necessary to make adjustments, to bring usersinto compliance with the role model:

1. The entitlement cluster may include entitlements which only some of the users in question have.

2. User attributes may have to be corrected, so that users satisfy user class inclusion criteria.

3. Users may have to be assigned some new entitlements.

4. Some existing entitlements may have to be revoked.

It is dangerous to do any of these things automatically, hence the need for a role analyst, who must interactwith business stakeholders and verify that proposed corrections are appropriate.



Because most roles will require this kind of analysis and correction, entitlement analytics and role definitionare quite time consuming (and costly). Organizations wishing to pursue a role-centric approach to IAMshould therefore assign significant time and resource budgets to this activity, both initially and ongoing, tomaintain the model.

8.8 Lifecycle management of the role model

A role model consists of both user class definitions (identify sets of similar users based on their attributes)and role definitions (collect entitlements into named sets). Over time, these may change:

1. As applications are onboarded or retired, entitlements within those applications may be added to orremoved from role definitions.

2. As business needs evolve, the set of users performing a job function may grow or shrink.

3. As processes evolve, the set of tasks users must perform, and consequently the set of entitlementsthey require, will change.

In response to these changes, the definitions of both roles and user classes should be reviewed regularly,in collaboration with relevant business stakeholders.

Analytics can support this review. For example, if a job function evolves, prior to changing the relevant roledefinition, users may already contact the access management team and request additional entitlements.Analytics can retroactively identify entitlements that are not part of a role but that are held by some or allrole members. Similarly, users who did not perform a job function before but now do, may have requested(and received) entitlements that are also available via a role. Analytics can identify users who effectivelyalready have a role (because they have the relevant entitlements) but have never been assigned that roleexplicitly. In these cases, it may be appropriate to expand the user class used to assign that role.

When user class or role definitions change, an IAM system should be able to automatically apply the newdefinition to impacted users. For example, if an entitlement is added to or removed from a role definition,then users who have been assigned the role should automatically be assigned that entitlement, or have itrevoked.

Automatically revoking entitlements due to role definition changes is actually more complex than this mightimply, since a user may be assigned multiple roles, and the same entitlement might be a member of morethan one. IAM automation should allow for such edge cases, and only revoke entitlements that are truly nolonger needed.

8.9 Analysis of entitlements and role definitions

Having defined a set of roles and user classes, it is reasonable to periodically reexamine these policyobjects, to respond to organizational changes and optimize the model:

1. Identify roles with overlapping entitlements – should they be merged?

2. Identify user classes with materially overlapping user populations – should they be merged?



3. Identify roles with too few users – perhaps they should be retired.

4. Identify roles with too many users – perhaps they are too coarse-grained.

5. Identify users with too many entitlements – they could cause technical problems on end systems andprobably represent high business risk.

6. Identify users with too few entitlements – do they still need access to systems or applications at all?

7. Identify entitlements that are included in too many roles – perhaps they should be attached to a baserole, which is then nested into higher level roles.

8. Identify entitlements not included in any role – should they be?

9. Identify users not assigned any role – should they be? Are they members of a large enough communityfor this to be economical?

10. Identify users assigned too many roles – do they have too many access rights? Do new, higher-levelroles have to be defined?

11. Do any roles violate SoD policies internally (i.e., entitlements in the role are mutually exclusive)?This can happen when SoD policies are defined after the roles, and should be remediated – illegalcombinations should not be so easily requested.

12. Which roles have many users that, in turn, have many out-of-role entitlements? How many out-of-roleentitlements do users assigned each role have, on average? This suggests either incomplete roledefinitions (add entitlements) or users that do not fit well into a role model.



9 Multi-step processes

IAM systems automate user lifecycle processes – conceptually made up of "joiners," "movers" and "leavers."In many cases, these processes are implemented at a single point in time, in a single step. In some cases,however, these processes can run over weeks or months and involve many steps, some mandatory andothers conditional. Following are common examples of multi-step processes.

9.1 Onboarding and day-1 activities

A common problem when onboarding new users is how to set and communicate their initial passwords.If the user requested the profile or account themselves (i.e., self-service enrollment, typically only used inbusiness-to-consumer scenarios), then the user can set the password. Otherwise, some communicationwith the user is required prior to first login.

Users often have to complete other day-1 activities, such as reading and accepting policy documents,enrolling security questions and providing other information about themselves.

In a corporate IAM system, following is a recommended best practice process:

1. Create any new accounts for the user with a random password. Do not communicate that passwordto anyone.

2. Acquire a limited amount of personally identifying information (PII) about the user in the onboardingprocess, either from an HR feed or a manager-operated request form. For example, ask for the user’sdate of birth, driver’s license number, mobile phone number, personal e-mail address, etc.

3. Use this information to authenticate the user on first login. For example, ask the user to enter a PINthat was sent to his mobile phone number or personal e-mail address, and then type his mother’smaiden name or date of birth in a second step.

4. Ask the user to read and accept ‘acceptable use policy’ or other documents.

5. Ask the user to enroll security questions that will be used in the future in the event of a forgottenpassword. PII may be good enough for a first login, but is probably not secure enough to use again,once the user’s accounts have access to sensitive data. If mobile phone number or personal e-mailaddress were not acquired earlier, ask for them now.

6. Having authenticated the user in this way, ask the user to select his own initial password.

7. Delete some or all of the PII at this point, as it should not be used again.



9.2 Access deactivation, archive and cleanup

Real-world access deactivation in a typical, complex environment can be a time and effort consuming,multi-step process. Following is an overview of a typical sequence.

Day Participants Steps

Before 0 Prior to access deactivation

HR, Manager View, set, modify scheduled termination date.

IAM system Read new scheduled termination date from SoR.

IAM system Send manager advance warnings of impending date, soit can be changed.

0 At the scheduled deactivation time and date

HR, Manager,IT Security

Optionally request immediate/urgent deactivation

IAM system Deactivate all login IDs, disconnect any "live" sessions;leave everything else in place.

0 to X After deactivation, before archiving

HR, Manager Request reactivation (i.e., did not notice erroneoustermination date).

X Archiving

IAM system Move user’s accounts to "disabled users" OUs.

IAM system Remove user from security groups and mail distributionlists.

IAM system Add user to "disabled users" security group.

IAM system Move, change ownership of user’s home directory, mailfolder (e.g., expose to manager).

IAM system Archive contents of user’s home directory, mail folder.

X+Y Cleanup

IAM system Delete accounts on target systems, but retain identityinformation (in case of rehire).

After 0 Rehire detection and blocking

IAM system Prevent new users from being created who appear to bethe same person. Ask user to reactivate profile or informuser that this user is not allowed back.

In the above, 0 is a scheduled termination date, X is typically 30 days and Y is typically 60 days.

In the above process, rehire scenarios are mentioned. This is because the termination and onboardingprocesses should be linked, such that attempts to onboard a departed user as though they are a newuser should be blocked – old users should either be reactivated (if they left on good terms) or blockedfrom returning (if they left under difficult circumstances). Rehire detection should be automatic and basedon retained attribute data and matching rules, since identity data provided in the onboarding process isunlikely to perfectly match retained identity data from when the user was deactivated.



9.3 Certification and revocation

Access certification mainly consists of a business stakeholder, such as a manager, reviewing a list of en-titlements, for example those of each subordinate, and identifying items that should be revoked. Certifiersmay not be 100% sure of what should be revoked, but should nonetheless be encouraged to flag itemswhich, at least based on their description, appear to be disconnected from business need.

To avoid inappropriate access revocation on the one hand and reluctance on the part of certifiers to flagentitlements as inappropriate on the other hand, it is important to route requests for revocation to a secondlevel of approval before actually deprovisioning anything.

1. When managers review the access rights of their subordinates, resource owners should be invited toapprove identified access revocations.

2. When managers mark subordinates as terminated, HR should review the requests before any accessis disabled.

3. When managers mark subordinates as transferred, HR and/or the user’s new manager should ap-prove the change.

4. When resource owners mark entitlements as inappropriate, users’ managers should approve revoca-tion.

5. When policy owners mark entitlements to remove – for example to eliminate SoD policy violations,resource owners and/or managers should approve the revocation.

Once an access revocation has been approved, a third class of participants may be invited to actuallydeprovision the access: human implementers. This is true where a connector is unavailable or has not yetbeen deployed, and where fulfillment remains a manual process.

9.4 Transfers with side effects

People inside an organization are often transferred – to a different location, to report to a different manageror to work in a different department. Each of these changes may trigger side effects, which must beconfigured to happen automatically:

1. Changes in a user’s affiliation (manager, location, department) may cause the user’s account objectin a directory to be moved to a new container (OU).

2. Changes to location in particular may trigger moves of the user’s home directory and/or mail folder toa server near the user’s new work location.

3. Changes to any profile attribute, including affiliation attributes, may cause the user’s roles to be re-computed, which in turn could lead to some entitlements being assigned and others revoked.

4. Changes to department or manager should trigger a recertification of the user’s access rights, by theuser’s new manager. Some entitlements that made sense in the user’s former affiliation may not makesense in the user’s new department or under the user’s new manager.



Side effects are a general pattern, with affiliations being the most obvious examples. An IAM system needsa general-purpose infrastructure to compute side effects which result from changes to any identity attributesin a user profile.

9.5 Name changes with side effects

Changes in a user’s name, for example due to a change in marital status or even declared gender, oftenrequire other cascading changes to their profile:

1. Where the user’s profile ID or login IDs to individual systems were derived from the user’s name, thenthose IDs need to be recomputed.

2. Wherever login IDs changed, other items, such as home directory paths, may have to be modified.

3. Where a user’s e-mail address is based on the user’s name, the old address should be "demoted" toan alias and a new primary e-mail address should be computed.

All of the above changes must enforce uniqueness. No two users may have the same profile ID, or the samelogin ID on the same system, or share an e-mail address. Collision resolution algorithms must be appliedto name changes, just as they are to onboarding requests.



10 Automation from authoritative sources

The first part of an IAM system deployed by many organizations is automation. The basic model is tomonitor one or more systems of record for changes and to grant or revoke access in response to detectedchanges. For example, in a corporate deployment, an HR system may be a SoR for employees and accesscan be created or deactivated in response to new hires and terminations detected in the SoR.

10.1 Applicability to user communities

Automation is attractive when it works, as it does not require new interaction with users. However, it onlyworks when there is a suitable SoR. This depends on the style of deployment and user communities in-volved:

1. In corporations, one or more HR applications may be suitable SoRs for employees, but usually not forother types of users, such as contractors or partners.

2. In educational institutions, HR is a suitable SoR for faculty and staff, while an enrollment system isoften a good SoR for students.

3. In B2B (partner portal) or B2C (e-commerce) systems, there is usually no plausible SoR, so automa-tion is not possible.

Where automation is viable, SoR’s should be identified and linked to user communities. The IAM systemshould support multiple SoRs, such as regional HR applications used by multinational corporations or HRversus enrollment in universities.

10.2 Timeliness, reliability and granularity

Automation is only as good as the quality, reliability and timeliness of data in the SoR. This raises thequestion of who populates the SoR, when they do so and how reliable they are?

Consider an HR system which is populated only in time for each payroll run. Employees may be added tothis SoR later than their start date, so automation to grant them access would happen too late. Conversely,an employee may have left an organization but remain on payroll for some time because of an agreed legalsettlement. In both cases, the SoR could reflect changes too late for the IAM system’s needs.

In practice, the IAM system should support SoR data which is (a) updated late; (b) obsolete or (c) absent:

1. Users, such as managers, should be able to request changes via the IAM web portal, for changesthat the SoR should have but did not yet reflect. When the SoR system eventually includes the sameupdate, the IAM system should recognize the change as redundant and not respond.

2. Users should be able to make corrections to data that is normally sourced from an SoR. For example,users might change their home contact information, managers might change who a user reports toor what department they work in, etc. Ideally, such corrections can be written back to the SoR by



the IAM system. In practice, most organizations only expose a read-only SoR data feed, which hasconsequences:

(a) The IAM system can ask a human being to correct the SoR data, but cannot correct it directly.

(b) Even if the SoR is taken to be ’most authoritative’ for a certain attribute, the IAM system shouldbe able to override that attribute for a period of time, until its value is changed in the SoR.

Moreover, SoR data is normally coarse grained. An HR feed may be able to tell what department a userworks in, but not exactly which applications the same user needs to be able to sign into. This means thatSoR data can establish baseline access but requests are needed for more fine-grained access.

10.3 Polling, transaction tables and real-time API calls

Given that the IAM system will monitor the SoR for changes and create access change requests as aresult, the next question is how and how often the IAM system should connect to the SoR? There aretwo contradictory priorities here: on the one hand, it is desirable to detect changes on the SoR as soonas possible, so as to grant and revoke access promptly. On the other hand, it is desirable to minimize oravoid altogether change controls on the SoR application platform, and only loosely couple the IAM and SoRapplications.

1. Polling:

The most common approach is for the IAM system to poll the SoR daily or every few hours, detectchanges (new records, deleted records, changed values) and propagate those into value updates oraccess change requests as appropriate.

• Pros: can usually leverage an existing (e.g., SQL) interface into the SoR data, no local softwarerequired on the SoR application. The load on the SoR from daily polling is minor.

• Cons: changes in the SoR are not detected until the next run, which might be as long as a dayaway.

2. Triggers and transaction tables:

On some SoRs, and in particular on SQL databases, it is often relatively easy to implement databasetriggers that record changes to one table in another table, in real time. The IAM system can poll thesecond, transaction record table more frequently (e.g., every few minutes) and create access requestsaccordingly.

This is feasible since, while the main SoR data table may contain tens of thousands of rows, thetransaction table will, at any given time, either be empty or contain a handful of records. Pollinga small or empty table every few minutes is much more reasonable than polling a large, tens-of-thousands-of-rows table every few minutes.

• Pros: still relatively minor change control on the SoR, but now with more timely automation.• Cons: does require some code on the SoR application or database; somewhat more complex to

setup; race conditions may cause some transactions to be dropped, so should be combined withthe previous full-list polling approach, which increases complexity.

3. Real time via IAM API:



To get real time responsiveness, write code on the SoR application platform to call IAM APIs andrequest access immediately, whenever SoR changes are written. For example, when a new employeeis hired, the HR application is modified to call the IAM system to request access.

• Pros: real time access grant and revocation.• Cons: maximum change control on the SoR application. More complex, costly, may impair

version upgrades to the SoR, presupposes that the SoR application platform is able to call outto third party APIs in response to events such as onboarding and deactivation, requires SoRapplication development skills.

In most cases, same-day or next-day responsiveness to SoR data is acceptable, so the first method aboveis used. Only where there is a business need for faster access should more frequent polling or otherapproaches be considered.

10.4 Combining data from multiple SoR feeds

As mentioned in item 10.1 on Page 35 earlier, many organizations have multiple SoRs. Where this is thecase, special care is required:

1. The IAM system should not be configured with the assumption that any one system (SoR or not)contains all users. User profiles may derive from one or more SoRs.

2. The primary user identifiers on each SoR must either be the same as the identifier assigned to thesame user in other SoR’s or must be guaranteed to not overlap. This is best illustrated by examples:

(a) In a university, people are often assigned a unique, numeric ID. The same ID should be assignedto the same person in the HR system (assuming the individual is faculty or staff) and in thestudent enrollment system.

(b) In a corporation, different regions may use different HR applications. Where this is done, eitherall HR systems should assign consistent employee numbers (through some integration betweenthem), or they should use different format employee numbers, which can therefore never collide.

3. Where multiple HR systems are used, the case of employees being transferred between regions mustbe considered. In particular, when a user is transferred from one HR system to another, some linkageis required between the two HR profiles, to allow the IAM system to link them together, so that it doesnot deprovision the user as he leaves the jurisdiction of one HR system and re-provision the sameuser as he joins the other jurisdiction. It is far better (no lost files, no lost access rights) to transfer thesame identity over, than to delete/recreate, and this requires a linked identifier.



11 Integrations

The value of an IAM system is in large part due to automating processes. This is impossible withoutintegrations, both to systems of record, which indicate changes that are required, and to managed systems,where identities and entitlements are managed.

11.1 Systems of record

SoRs should be integrated wherever feasible, as described in Subsection 10.1 on Page 35 earlier. Auto-mated processes should drive onboarding, deactivation and changes for each user community that is wellrepresented in an SoR which contains reasonably accurate and timely data.

Integrations with SoRs can technically be bidirectional: in addition to reading user data from the SoR, theIAM system can accept corrections to user data via its request portal and it can write those changes backto the SoR. In practice, few SoR application owners are willing to allow a third party application, such asan IAM system, to autonomously write updates to their system, and consequently most real-world SoRintegrations are read-only.

Also, as mentioned in item 2 on Page 35, where the IAM system supports corrections to the SoR, if theSoR integration is read-only, then (a) a method is required to notify SoR application users to make the samecorrection and (b) the IAM system should be able to temporarily override obsolete data from the SoR datafeed until the same item in the SoR is updated.

11.2 Managed systems

Most of the integrations in an IAM system are to managed systems. These are the directories, systems andapplications where the IAM system creates and deletes accounts, enables and disables login privileges,assigns and revokes privileges, etc.

Ideally, all such integrations are bidirectional, in the sense that the IAM system both monitors the identitiesand entitlements on each managed system and, when required, writes updates to that system. As a rule ofthumb, default to fully automated, bidirectional integration with any system that has thousands of users orwhere there are at least hundreds of access changes annually.

11.3 Connector operations

An IAM system may need to implement any of the following "primitive" operations on a target system:

• List existing accounts and groups.• Create new and delete existing accounts.• Read and write identity attributes associated with a user object.• Read and set flags, such as “account enabled/disabled,” “account locked,” and “intruder lockout.”• Change the login ID of an existing account (rename user).• Read a user’s group memberships.• Read a list of a group’s member users.



• Add an account to or remove an account from a group.• Create, delete and set the attributes of a group.• Move a user between directory organizational units (OUs).

In addition, on systems with passwords or other credentials, some subset of the following operations arealso required:

• Set / reset passwords and PINs (e.g., on tokens, smart cards).• Other token-specific operations, such as issuing emergency pass-codes and clock synchronization.• Retrieve unlock codes from key recovery systems supporting smart cards and full disk encryption

products.• Clear intruder lockout flags on systems that support intruder lockout.• Set account enabled status on systems that support enable/disable.• Update password expiry information.

Connectors normalize these operations, so that the IAM system invokes a connector and asks it to performa given operation, and the connector communicates with the managed system in question, using its nativeAPI, communication protocol, etc. to perform the required action.

11.4 Connector location and timing

In practice, IAM connectors work as follows:

1. On a schedule (typically at least daily), read identity and entitlement data from each integrated system.On the few systems that support it (typically AD), pull only deltas. On most systems, pull a full list ofall such data.

2. As change requests are approved (i.e., throughout the day), write updates back to each integratedsystem.

While it’s possible to deploy local agents on end systems and detect changes on integrated systems inreal time, the change control required to do so, especially when there are hundreds of such integrations, isundesirable for most organizations. Consequently, agent software installed on target systems is avoided inalmost all cases.

11.5 Partial automation

In many cases, it is uneconomical to deploy a connector to a target system. This may be for any combinationof the following reasons:

1. Target system has too few users or changes are very infrequent. It makes no sense to spend 3-4 daysof consulting time to configure, test, migrate to production and document an integration if the systemin question has fewer than a hundred users or if fewer than 100 changes per year are applied to thatsystem.



2. The IAM system does not come with a built-in connector for the type of system or application in ques-tion, and developing one would be cost prohibitive (connector development may cost up to $10,000per custom integration with Hitachi ID Systems and much more with some other products).

3. The system or application in question has no usable API or other scriptable interface, and it wouldtherefore be very difficult from a technical standpoint to develop an integration.

4. The application vendor does expose a suitable API, but charges significant fees for its use.

5. The application vendor does not expose a suitable API and is litigious with customers who developnon-sanctioned integrations.

Where full automation is uneconomical, it may nonetheless be possible to implement partial automation.Partial automation means that some connector operations are handled by a connector, but others arecompleted by people. Most commonly, listing identities, groups and group memberships is automated butcompleting updates is left to implementers (people).

Partial integrations are desirable as they enable the IAM system to perform governance functions, such asensuring that access is deprovisioned when people leave the organization, locating SoD policy violationsand performing access certification.

11.6 Manual fulfillment

In some cases, even partial integration is infeasible. Consider the case of an organization that has 500 fullycustom applications, where no two applications are the same and each application has only a few users. Inthis case, it may not be economical to even build list-only connectors to these systems.

In this case, the human administrators of each application can be prompted to (a) provide lists of currentusers and entitlements and (b) manually complete approved changes.

Manual fulfillment is still better than no representation of an application in the IAM system, as it creates a"one stop shopping" experience for requesters and a consolidated view of all access, held by all users, onall systems and applications.

11.7 Non-identity integrations

IAM systems are often integrated with other types of systems – i.e., not used as an SoR and not managedto create/delete accounts and assign/revoke entitlements. This may include:

1. E-mail: to invite users to act and notify users of events.

2. Incident management / ticketing systems:

• Outbound integration: to create, update or close incidents.• Inbound integration: to leverage a service request platform as a request user interface which

automatically submits IAM requests to grant or revoke logical access.

3. Security information and event management (SIEM) systems:



• To notify the SIEM of events that may have security consequences, such as IAM login subsystemlockouts or changes to user access.

• To share identifier mapping data (ID aliases) with the SIEM, so that it can map events on differentsystems to people.

4. Short message service (SMS) broker services, to send messages to user mobile phones.

5. Mobile device management platforms, to initialize new or wipe out existing corporate phones and toset user passwords.

6. Strong authentication and federated access platforms, as a login service into the IAM portal.



12 Delegated and self-service management

Even after automation from an SoR has been fully realized, there usually remain changes that must still bemanaged:

1. Communities of users not represented in any SoR, such as contractors, vendors, partners or cus-tomers.

2. Fine grained and temporary access rights, which the SoR cannot predict but which users nonethelessrequire.

These changes must be managed via a request portal, supported by policies and authorization processes.

12.1 Delegation models

There are a number of models commonly used in real-world IAM deployments:

1. In corporate deployments:

(a) A manager/subordinate model, where managers make requests on behalf of people reporting tothem, directly or indirectly.

(b) An HR/employee model, where people in the HR department make requests on behalf of em-ployees within their jurisdiction.

(c) A regional or departmental IT security model, where IT staff designated specifically to manageaccess rights within a given segment of an organization make requests for other users within thesame part of the organization.

2. Business to business partner portals:

(a) An administrative user / regular user model, where each partner organization designates at leastone administrative user, and administrative users are able to create, modify or delete other userswithin their own partner organization.

12.2 Usability and navigation

A core problem in all IAM systems is how to help requesters articulate access requests, be they for them-selves or for others.

Requesters rarely know exactly what entitlements, on what systems, are required and consequently theytend to formulate their requests, at least when communicating with the help desk, as "please make Bob likeMary." Copying all entitlements from one user to another is clearly undesirable, since the source user mayalready have excess access rights and the destination user likely does not need all the rights of the sourceuser anyways.



A number of best practices are recommended to help requesters. They can be combined to further enhancethe user experience:

1. Where user access needs are predictable, users should be automatically assigned business roles,where the roles encapsulate all requisite entitlements. This eliminates the need for users to submitrequests at all. Unfortunately, such an RBAC approach is static and only cost effective for large groupsof users with identical requirements.

2. Link from the corporate IT portal and/or the service request portal to the IAM system.

3. Package commonly assigned sets of entitlements into roles, with business-friendly descriptions. En-courage users to request roles rather than individual, more "technical" entitlements.

4. Assign friendly descriptions to roles and entitlements, and populate as much metadata as possible.Provide a search interface to requesters to help them find the most appropriate entitlement. Search isthe most preferred user interface paradigm for selecting from large lists, and in particular is preferredby users over an information hierarchy.

5. If possible, intercept "Access Denied" error dialogs and provide a means for users to navigate fromthese dialogs to appropriate access request pages. Users frequently try to access what they wantbefore asking for assistance, and this way users can begin formulating a request, starting from thedesired business context.

6. Requesters often know which users already have an entitlement they wish to ask for, even withoutknowing what the entitlement is called. Provide a request form that allows requesters to compare theentitlements of a model user with those of the recipient and to select just a subset of those entitlementsfor their request.

12.3 Visibility and privacy protection

Many IAM systems manage sensitive data about users. For example, user profiles may include contactinformation, such as home address and mobile phone number, which are not normally shared widely. An-other example is scheduled termination dates, which may be benign for contractors but very sensitive foremployees about to be let go, and who may not know it yet.

Because of the sensitive nature of some user profile data, it is essential to protect access to this data.Broadly, what one user can see or modify in another user’s profile should depend on how the two users arerelated. Following are some examples to illustrate this point:

1. A scheduled termination date should be visible to:

(a) The user’s manager; and

(b) HR, but not to the user, in case the user is an HR worker.

2. Personal contact information should be visible to HR and in some cases to a workplace safety/securitygroup, but rarely to others – usually not even to managers.

In some organizations, users are able to control the visibility of some information in their profiles. Forexample, in a college setting, users may be able to grant or block access to their school e-mail address byother members of the campus community.



The aforementioned examples have a technical consequence, which is that access to user profile attributesmust depend on how a requester and recipient are related. Traditional models, such as role based access(i.e., "HR can access data type X for all users") or hierarchical access (i.e., "managers can review data typeY for all subordinates") simply do not fit real-world business requirements.



13 Soliciting reliable action from unreliable actors

One of the core features of any IAM system is to invite people to act. There are three main contexts thatshould be considered for IAM initiated invitations:

1. Authorization: Invite one or more people to approve or reject a change request.

2. Fulfillment: Invite one or more people to manually complete an approved change.

3. Certification: Invite some users to review the access rights of others, possibly flagging some itemsfor revocation.

13.1 Human responsiveness versus service level agreements

The problem with inviting people to complete tasks is that people are not, generally, reliable participants inprocesses:

1. They may not notice or ignore invitations to act.

2. They may be busy and repeatedly defer responding to invitations.

3. They may be unavailable – in meetings, on vacation, sabbatical, etc.

Without prompt response from people invited to participate, workflow processes can either not complete orrun very slowly. This can adversely impact service levels required by requesters and recipients.

13.2 Reminders

The first line of defense against unresponsive users is to send them reminders. A typical Service LevelAgreement (SLA) for approval of fulfillment is defined as 1 day or less, while reminders can be sent every 2to 3 hours.

13.3 Concurrent invitations

Another, complementary strategy is to invite multiple people to perform a single task. With this approach,hopefully someone in the list of invited people responds promptly and the process can continue.

This strategy is effective in many cases, but not all. Specifically, most users have only one manager, andit is difficult to invite N people to perform a task assigned to just a single manager. On the other hand,assigning N owners to an entitlement or to approve exceptions to a policy is usually straightforward.



13.4 Delegation and escalation

Workflow participants should be able to designate people to act in their behalf, if they will be unavailable fora period of time. For example, a manager who frequently approves requests should be able to temporarilydelegate his authority prior to leaving for a trip.

Delegation can also be applied automatically, if a request was sent to a given person, there has been noresponse after N reminders and the request still requires attention (i.e., not canceled or already resolvedby someone else). In these cases, the request can and should be escalated to someone else, typically theinitial person’s manager.

13.5 Impersonation

A specialized form of delegation is the ability of one person to sign in with another person’s profile andperform actions as the person being impersonated. This pattern is very common with managers and theiradministrative assistants, who may read the manager’s e-mails, approve requests on behalf of the manager,etc.

Impersonation differs from delegation in that it is a permanent relationship, where person A may performany action as person B, at any time. The IAM system should support impersonation as part of its loginprocess and record who acted on whose behalf in its logs.

13.6 Checking out of office status

Escalation normally takes place only after a given person repeatedly fails to respond to reminders followingan invitation to act from the IAM system. This is a time consuming process, and in some cases the delayis predictable. Most people set an out-of-office message on their e-mail account when they intend to beunreachable for an extended period of time, such as a trip. The IAM system should be able to check forout-of-office settings and preemptively escalate requests early on during the workflow.



14 Internal controls and regulatory compliance

One of the core functions of an IAM system is to apply effective controls over user access rights. Controlsfailures can lead to security incidents ranging from small (someone finds out early about an upcomingtermination) to catastrophic (rogue financial trades, massive compromises of privacy data, health and safetyproblems). Consequently, it is far better to have more complex but effective internal controls than to risk theconsequences of control lapses.

14.1 Definitions

Broadly, controls over access rights, or entitlements, mean:

1. Users do have the entitlements they need.

2. Unneeded entitlements are either eliminated or minimized, where they represent low risk and whereeliminating them entirely is costly.

3. There is minimal delay between business events that cause changes in user needs (e.g., transfers,terminations, project changes) and when unneeded entitlements are revoked.

4. Dangerous combinations of entitlements are identified and blocked, remediated or, if truly required,approved alongside reasons and compensating controls.

A fundamental problem with the above is defining just what entitlements are business appropriate. Thisambiguity underpins many of the processes defined in the following sections.

14.2 Approval of change requests

One way to determine if a particular entitlement is appropriate for a given user is simply to ask. The questionis then who to ask? Common choices include:

1. Members of the HR department – helpful in cases of onboarding, terminations, transfers, etc.

2. The user’s current or – in the event of a transfer – new manager.

3. Owners of the entitlement or of the system where the entitlement grants access.

4. Policy owners assigned to SoD policies, roles, etc.

It is important to distinguish between reliably predictable entitlements and those which are requested. If anentitlement being assigned to a given user is predictable, then it should be automatically assigned, with noapproval process at all. This improves SLA for recipients and reduces the burden on authorizers.

It is also helpful to risk-score each access request:



1. Low risk requests can be automatically approved, again improving SLA and reducing workload forauthorizers.

2. High risk requests should be flagged as such, to help authorizers understand that they really shouldnot "rubber stamp" the request and instead should examine it carefully.

14.3 Risk scores

As mentioned above, it is helpful to calculate risk scores, both for requests and for users. Risk scores canfeed into other processes:

1. Reducing the need for approvals on low risk requests.

2. Drawing the attention of already-assigned authorizers to high risk requests, or inviting additional au-thorizers to review these requests.

3. Identifying users whose entitlements should be reviewed (recertified) more frequently.

Risk scores are subjective and consequently the logic employed to compute them varies among organiza-tions. Following are general guidelines:

1. Assign a risk score to entitlements of interest.

2. Separately, assign a risk score for policy violations, such as a user violating a specific segregation ofduties rule or having more rights than his assigned role suggests.

3. If desired, assign risk scores to additional items, such as specific job codes, departments or locations.

Some organizations also assign risk scores to:

1. How recently a user was certified (if at all);

2. Frequency of access requests in the past month where the user was a recipient.

Add up all of the above elements to compute a per-user risk score. For access requests, add up the user’spre-request and post-request scores and subtract one from the other to score the risk associated with therequest.

A word of caution: Risk scores are just an aggregate of many subjective decisions (how risky is a giventhing?). Aggregating variables, each of which has a lot of uncertainty, yields a score with even largeruncertainty. While it can be helpful to assign risk scores to users and entitlements, getting overly complexis not necessarily productive. Moreover, risk scores are no substitute for more concrete policies, such asperiodic access certification, change authorization by relevant business stake-holders, privacy protectingaccess controls, etc.



14.4 Access (re)certification

Another form of internal control designed to separate business-appropriate access from no-longer-requiredentitlements is access certification. Certification, sometimes referred to as attestation, is a distributedreview and cleanup of users and their entitlements. It works by asking managers, application owners anddata owners to review lists of users and entitlements. These stakeholders must choose to either certify orrevoke every user and entitlement in the list they are presented.

The advantage of access certification is that business judgments are made by business stakeholders, apply-ing contextual knowledge that cannot be readily captured by automation. The drawbacks of this process arethat stakeholders are often busy and entitlements frequently have technical descriptions that stakeholdersdo not understand. Both of these phenomena result in a tendency for reviewers to blindly approve current-state entitlements, rather than flagging anything for revocation. Some care is required when communicatingthe need to perform a review to certifiers, to remind them that a rubber-stamp approach is inappropriate.

Certification rounds, or campaigns, may be recurring, regularly scheduled events or triggered to run justonce. They generally include a scope (which users, which entitlements) and a mapping between users orentitlements being reviewed and the people performing the review. Scheduled certification rounds normallycover a large population of users while ad-hoc rounds are more commonly assigned to just one user, forexample as a consequence of a transfer.

Reviewers who complete a certification round are normally asked to sign-off. Technically, this amounts tore-authenticating to the IAM system on a page which summarizes the changes they proposed and includessome legal language.

Certification suffers from the same timely-and-reliable response issues as workflow approvals, as describedin Subsection 13.1 on Page 45. It follows that reminders, delegation, escalation, out-of-office checking, etc.are appropriate here, as in all other IAM workflow processes.

An additional incentive that can be brought to bear in certification is to block the ability of a manager tosign-off on their review until their subordinate managers have done so. With this process, an executive suchas the CEO or CFO, who wishes to implement strong internal controls to support a regulatory complianceprogram, will pressure his direct subordinates to complete their own reviews. They will be unable to sign offuntil their own subordinates have finished and so a downward pressure is created through the organizationto complete the audit.

14.5 Segregation of duties

Another common type of internal control is a segregation of duties (SoD) policy. These policies are generallymuch less subjective than access certification or change approvals – they simply identify combinations ofentitlements that no single user should be assigned, because a user who does have these combinationscould single-handedly cause harm to the organization.

The point of an SoD policy is to split up access rights, so that harm to the organization cannot be carriedout by a single person. Multiple people must either collude or make a set of related mistakes before harm,such as fraud, large-scale privacy compromise, etc. is caused.

An effective SoD subsystem should support:



1. Flexible policy definitions:

• Users with N of M entitlements deemed to be in violation.• Entitlements may include login accounts on indicated systems, being assigned a role or being a

member of a security group.

2. Approved exceptions:

Sometimes users legitimately do need to violate an SoD policy. A mechanism is required to identifyand (hopefully, temporarily) approve an exception to policy.

3. Preventative controls:

Requests for access processed by the IAM system should detect that the end result would be aviolation, and block such requests, or at least ask for an approved exception.

4. Detective controls:

Access that was provisioned outside the IAM system or which pre-exists the definition of an SoD rulemay cause a violation. The IAM system must be able to identify such violations and help controlowners to resolve them.

5. Effective violations:

Nested roles, which are defined as sets of other roles and individual entitlements, form a hierarchy.SoD policies may be defined in terms of fine-grained entitlements – at the lowest level of the hierarchy– or in terms of roles, higher in the hierarchy. In practice, an SoD policy violation may occur ata different level of the entitlement/role hierarchy than the level where the SoD policy was defined.Most commonly, SoD policies are written in terms of individual entitlements, but access requests areformulated in terms of higher level roles.

The SoD policy engine in an IAM system must detect and block violations which occur at a differentlevel of the role/entitlement hierarchy than the level where a given SoD rule was defined.

14.6 Returning users

Another type of control is to detect, during the onboarding process, that apparently-new users are actuallyreturning users who had previously left. This is important for two reasons:

1. Returning users should be reassigned their old identifiers, to ensure continuity in the audit record.

2. Some users depart on bad terms, and should not be rehired / reactivated.

Returning users do not reliably acknowledge that they are, in fact, returning. Moreover, returning userscannot be relied upon to recall and provide their old identifiers. Detecting returnees therefore requirespattern recognition, to assess the likelihood that an individual is actually not new. This assessment yields ascore which is computed by matching retained information about old users with information available aboutnew hires. This may include the person’s name, date of birth, contact information (e.g., personal e-mailaddress, home and mobile phone numbers, etc.) and government-issued identifiers such as social securitynumber or driver’s license number.



A high matching score can be assigned to government issued identifiers and contact information such asphone numbers or e-mail addresses. Name matches are assigned a lower score, because of mis-spellings,changes (marriage, divorce) and changing user preferences (first name versus nickname versus middlename, etc.).

When an apparently new user matches an existing profile with a low confidence score, warnings shouldbe generated but the onboarding process should be allowed to proceed. When an apparently new usermatches an existing profile with a high confidence score, the onboarding process should be blocked andparticipants should be asked to either reactivate the old profile or block the process in the organization, notonly in the IAM system.

14.7 Out of band changes

Once an IAM system is deployed, it is reasonable to expect that all changes relating to identities and en-titlements on integrated systems be made through the IAM system, rather than out-of-band. In principle,changes made out of band may either be in response to a legitimate business need or attempts to circum-vent IAM controls:

1. If legitimate, why could the IAM system not be used? Perhaps an enhancement is required?

2. If circumvention, by whom, for what purpose, and what can be done to remediate the controls viola-tion?

At a minimum, the IAM system should be configured to detect out of band changes, by retrieving lists ofaccounts and entitlements from each integrated system and comparing current-state data to its internalmodel. A response may be required for detected changes:

1. If a system is still frequently managed by other tools, then just update the internal model in the IAMsystem to reflect the system’s current state.

2. If a system should no longer be managed by other tools:

(a) Send an e-mail to application or group owners; and/or

(b) Submit a workflow request to reverse, approve or investigate the change.

For example, if an Active Directory account was attached to the Domain Administrators group out of band,then the IAM system could send an e-mail to an IT security audit events distribution list and proactivelycreate a workflow request to remove the user from the group.

Unfortunately, on many systems, there is no readily accessible record of who made such changes, onlywhen. This is a problem which can be solved by adding a privileged access management system to theenvironment.

Moreover, malicious users who already have elevated privileges could make an unauthorized, out-of-bandchange to user entitlements, use that change to perform some action and then reverse the change. Usingthis race condition, they can evade detection by the IAM system, as IAM systems generally only detectentitlement changes in periodic samples, as described in Subsection 10.3 on Page 36.



15 Constructing and maintaining org-chart data

An OrgChart is data linking each user profile to that user’s manager.

While many people have “dotted line” relationships with multiple managers, in most organizations every per-son has a primary manager, with authority to review access rights, to terminate the employee or contractor,to review performance and pay, etc.

OrgChart data is often essential to the operation of an IAM system. Some of its uses are in:

1. Authorization: Managers may be invited to approve changes to their subordinates’ entitlements.

2. Certification: Managers may be required to review a list of their subordinates and their entitlements,to identify and remove access rights that no longer serve business need. Access certification is auseful tool for compliance with regulations and internal controls requirements.

3. Escalation: When one person fails to respond to a request to act, that person’s manager may, in turn,be invited to act in their place.

Most HR systems can represent OrgChart data, such as the identity of each employee’s manager. Unfortu-nately, this data is often inadequate for use by an IAM system:

1. Coverage: Some classes of users, such as contractors and vendors, are often excluded from HR.

2. Stale: HR data may not reflect changes in the organization.

3. Incomplete or inaccurate: HR data may simply not have been entered for some users, and may beerroneous for others.

4. Approximate: HR data may not be personal, in the sense that employees and managers are attachedto organizational units, but not to each-other. This means that some users may be associated withmultiple managers, and others with none.

While it is possible to hire a team of consultants to work with HR and interview managers, to constructOrgChart data, this approach is undesirable:

1. It is costly, requiring a lengthy consulting engagement.

2. OrgChart data collected at the start of the project may be obsolete by the end of the project.

3. There is no way to keep the data complete and accurate after the project is over.

OrgChart data can be updated by inviting managers to identify their subordinates and to mark which ofthose subordinates are, in turn managers.

In an "org-building round," each manager receives an e-mail inviting him to perform a review of subordi-nates. Managers click on a link and see a list of their direct reports. They may transfer some of these toother managers or identify missing people, who do report to them but are not shown in the list. Crucially,managers must also identify which of their direct subordinates have subordinates of their own.



Managers are asked to sign-off on a corrected list of subordinates. Anyone they marked as having theirown subordinates is then invited to repeat the process.

To ensure broad and timely coverage, this process must also include impersonation (e.g., a manager’s ad-ministrative assistant performs the review on behalf of the manager), reminders, escalation and delegation.

The OrgChart update process should be integrated with existing sources of data, such as HR applicationsand LDAP directories:

1. Existing manager/subordinate data should be loaded into the IAM system initially and updated peri-odically.

2. Updates made to manager/subordinate data via the IAM system should be reflected in the HR systemor directory, either automatically or, where this is not allowed, by inviting people to make changes inthese systems to reflect corrections made via the IAM system.



16 Generalizing policies

IAM systems enforce a variety of policies, including:

1. Who should approve a given change request?2. How to compose new, unique identifiers and e-mail addresses?3. Where to place directory accounts (OU), home directories (UNC) and mail folders (mail DB)?4. How often to remind users to respond to workflow invitations?5. Who to invite in place of non-responsive users?

At first, it may seem desirable to embed these policies in workflow processes. For example, define a processfor onboarding employees and, within the process, create request forms, approval forms, authorizer routing,logic to calculate IDs and assign containers, processes to send reminders and handle escalation, etc. Inreality, however, this approach of embedding policies and processes inside workflow definitions is difficultto maintain where there are a large variety of processes and where there is a natural requirement to ensureconsistency across related processes. Moreover, policies become opaque, as they are ’hidden’ inside avariety of process definitions.

A more mature approach is to create a taxonomy of policy types and define rules within the context of eachpolicy type, independent of individual workflow processes.

In practice, general-purpose policies should control:

1. Access controls over user profile data.

2. Unique identifier assignment.

3. Calculation of identity and request attributes.

4. Authorizer selection.

5. Workflow reminder frequency.

6. Preemptive escalation (because a participant is out of office) and escalation due to too many re-minders.

7. Delegation controls.

Once this is done, individual processes become much simpler to define – create a request form, assignaccess controls and, for automated processes, link the request to event triggers. The rest is then handledby a shared policy framework.



17 Analytics: trends and patterns

Once an IAM system is operational, it makes sense to monitor the data it pulls in as well as its operation, tolook for both problems and opportunities to improve service.

Entitlement analytics were already discussed in the context of role based access control – please refer toSubsection 8.9 on Page 29 for details.

17.1 Similar users

Users with (near) identical subsets of profile attributes are candidates for the definition of user classes.User classes are groupings of users which may be leveraged in a variety of IAM processes, includingautomatically assigning entitlements, granting access rights within the IAM system, being invited to approverequests, etc.

17.2 Related entitlements

Users with (near) identical entitlements are candidates for role definitions. In this case, it is the entitlements,rather than users, who are collected into a role definition. Where many users share the same entitlements,it is economical to define a role, for easier assignment, either automatically or via request/approval.

17.3 High privilege and high risk users

Organizations can assign risk scores, as described in Subsection 14.3 on Page 48 to both entitlementsand users. Risk scores can be used to identify high privilege and/or high risk users, who may then besubjected to more stringent controls, such as more frequent access certification and additional approvals inthe context of workflow requests.

17.4 Busy periods

Utilization of the IAM system, in terms of requests, approvals, updates applied to target systems, loginsinto the IAM web portal, password changes, etc. vary over time. For example, password changes tend tohappen in the first hour of the work week, onboarding tends to happen earlier in the week, deactivation laterin the week, etc.

It’s a good idea to monitor the system for utilization rates, broken down by department, location, activitytype, time of day and day of week. Activity spikes exposed through this analysis can then lead to serviceoptimization: why are there many requests in a given department? Perhaps more automation can be used.Which locations generate high (or low!) activity? Perhaps they represent higher risk (or need training).



17.5 Workflow participant load and responsiveness

A core function of each IAM system is workflow, which is used to invite people to approve requests, man-ually complete approved changes and review user access, as described in Section 13 on Page 45. It isreasonable to consider the effectiveness of human participants in these processes – who approves quickly,who is slow to complete tasks, who has a lot of work and who has very little? These metrics can drive pro-cess and organizational changes, such a redistributing work, taking remedial action with staff who respondslowly or complete fewer tasks than their peers, etc.

17.6 Historical access

Organizations may sometimes have to perform forensic audits – who had access to X at time T? Whorequested and who approved this access? Is the access still active or, if not, when was it removed? An IAMsystem should support tracking this data and responding to questions such as these.

17.7 Data quality

IAM systems aggregate data about identities and entitlements from multiple sources – managed systems,systems of record, etc. Identity data is often of poor quality – missing on some systems, inconsistentbetween different systems, violating formatting or other constraints, etc.

The IAM system should be used to identify such quality issues in identity data on integrated systems. It maythen be used to automatically correct some problems (e.g., missing data on some systems, inconsistencieswhere one of the values clearly takes precedence over others). In other cases, where the remediationis less clear, the IAM system should at least identify the problem, flagging it for further investigation by ahuman.



18 Service catalogs and general-purpose request systems

Many organizations have deployed or are planning a consolidated portal where users may request any andall IT services. The idea is to publish a curated, searchable catalog of most or all IT services. The objectiveis to make IT service requests user friendly through a consumer-like request process.

18.1 Request origination

Once a service catalog is deployed, many organizations consider adding identity and access requests tothe service catalog. Does it really make sense for users to visit one request portal to ask for a new PC andanother to ask for a login ID?

There are three options for where users should enter access requests:

1. Originate all requests in the service catalog.

2. Originate all identity and access requests in the IAM system.

3. Originate some requests on each system – which raises the question of which requests should beentered on which system and how users should navigate between the two.

While all of the above scenarios are technically possible, there are clear best practices:

1. Request the most common and coarse-grained services – typically onboarding, urgent terminationand scheduled deactivation – in the service catalog. Bundle physical access, assets such as PCs andbadges, software licenses and logical access as components in easy-to-use, monolithic services.

Integrate the service catalog with the IAM system to fulfill logical access elements of the requestwithout further approvals – directory accounts, e-mail folders, home directories, application logins,etc.

2. Provide an integrated login process that allows users who have already signed into the service catalogto navigate into the IAM system without re-authenticating. Use the IAM system’s request UI to entermore fine-grained or specialized access requests:



Types of requests that should be madedirectly into the IAM system

Why using the IAM portal for these requesttypes is easier

• Request membership in roles, groups oraccess to applications.

• Request an entitlement that might violate asegregation of duties policy, and also ask foran approved exception to the policy.

• Request a change in the roles assigned to auser (and implicitly that some entitlementsbe added, others removed).

• Review the list of people who report to amanager. Add some (missing from theoriginal list), transfer others to their (new)correct manager and identify people whohave actually left the organization andshould be deactivated.

• Review the list of entitlements per user(organize by user or by entitlement) andmark the ones which are longer appropriatefor removal.

• The IAM system automatically maintains aninventory of available groups, by scanningintegrated systems and applications.

• Segregation of duties policies need to beapplied to these requests, which dependson knowledge regarding currently assigneduser rights (entitlements data) and policydefinition (detect whether requestedentitlements might trigger a violation).

• Selection of suitable authorizers may becomplex – e.g., user’s manager plus groupowner plus regional or departmentalsecurity officer.

• The request may be constructed bycomparing the entitlements of the recipientand some other, "model" user.

• The relationship between the requester andrecipient can be assessed by the IAMsystem to determine the extent of recipientdata the requester is allowed to access andto restrict the types of request formsaccessible to the requester in the givencontext.

• Some request forms are specialized – e.g.,comparing two users’ entitlements orperforming an access certification.

3. Link navigation to the IAM request portal into the service catalog, so that requesters do not have toconsciously navigate between the two. One easy way to do this is to embed the IAM system’s userinterface in an IFRAME in the service catalog.

4. Automatically create, update and close service requests in the service catalog whenever requests arecreated in, updated or closed in the IAM system.

18.2 Integration

Regardless of where any given request type is entered, integration between the IAM system and the servicecatalog / service request system is recommended:

1. Track IAM request numbers in the service request system.

2. Track service request ticket numbers in IAM access requests.

3. Enable the service catalog or service request system to automatically submit access requests to theIAM system, including their request number.



4. Enable the IAM system to create new and update existing service requests, to reflect activity andchanges in request status.

5. Single sign-on between the service catalog request portal and IAM request portal.

6. Embedding the IAM request portal, as a monolithic UI, into the service catalog request portal.

If at all possible, avoid polling – each system should push updates to the other in response to events.Neither system should have to monitor the other for such changes.

18.3 Aggregate queue and trend visibility

Once integration such as the above is implemented, it will be possible to monitor some elements of IAMsystem performance via the service request system:

1. Size and content of the request queue.

2. Responsiveness of workflow participants.

3. Popularity of request types and entitlements.

4. Total request volume and trends over time.

While it is possible to generate all of these reports and dashboards directly via the IAM system, it is oftendesirable to use the same tool to monitor the same things across different parts of the business, and thatshared tool is more likely to be the request management system.



19 Incremental deployment and IAM programs

Identity management and access governance projects tend to be long and indeed may never end, asdeliverables are continually added over the life of the system. Organizations go through both business andinfrastructure changes: reorganizations, hardware upgrades, new operating systems, new applications,etc. These changes trigger matching requirements in the identity management and access governanceinfrastructure and consequently lead to implementation and maintenance effort over the life of the system.

This is not to imply that individual deliverables cannot be implemented quickly and operated at low cost.Rather, it means that successful implementation of one feature or integration usually triggers interest by awider range of stake-holders, who request further work, to deliver more features and integrate with moreinfrastructure.

With this in mind, it can be helpful to think of identity management and access governance implementationin terms of a process of continuous optimization, which is the responsibility of a permanent team, ratherthan a single, finite project.

Successful organizations respond to this by instituting a permanent identity management and access gov-ernance program, rather than staffing for a finite-term deployment project. This team should include apermanent technical application administrator and a permanent application owner, at a minimum.

As with any long term program, it is important to have clear buy-in from stake-holders and an up-frontagreement on project scope, deliverables, duration and cost in order to sustain investment and deliver onbusiness expectations. Without such early commitment by stake-holders, project work may be abortedbefore deliverables are reached.



20 On-premise versus hosted/SaaS IAM systems

Organizations increasingly prefer to move applications from on-premise hosting to a software-as-a-service(SaaS) delivery model. This is as true for IAM as it is for any other category of software.

IAM-as-SaaS (IAMaaS for short) is a valid delivery method for IAM systems.

A SaaS delivery model has both advantages and disadvantages. These apply to any software category,and should be considered if IAMaaS is an option:

Pros Cons

Faster start-up. Typically higher total cost of ownership, over thelong run.

More frequent version upgrades. More effort required to keep integrations andcustomizations working on new releases.

More standardized setup. Less ability to customize.

Easily accessible from non-corporate devices,including off-site.

Exposed to attack from the public Internet.

Most organizations use IAM systems to manage, among other things, identities, entitlements and creden-tials on their existing systems and applications, many of which are on-premise and some of which arein the cloud. On-premise systems typically include AD, Exchange, LDAP, ERP applications, sometimesmainframes, etc. Cloud applications may include WebEx, Google, O365, Concur, Salesforce, etc.

Where the IAM system is moved to a SaaS hosting model, it still requires connectivity to on-premise systemsand applications, without which it cannot discover current state or push updates to these systems. Thereare basically two ways to provide this:

1. Deploy an on-premise proxy server:

(a) This may be reachable from the cloud-hosted IAM system, typically via an on-premise reverseweb proxy; or

(b) It may periodically call out to the cloud-hosted IAM system, asking for instructions.

2. Implement a virtual private network (VPN) between the cloud-hosted IAM system and private corpo-rate network.

In either case, on-premise servers and configuration are required to support integration between the cloud-hosted IAM system and on-premise systems and applications.

Consequently, even where the IAM system is delivered in a SaaS form factor, there is nonetheless someon-premise footprint – software plus either hardware or VMs. This is unavoidable in all organizations thatretain some on-premise systems and applications which must be managed.



21 Standards: SAML, SPML and SCIM

IAM standards are intended to improve the reach and lower the cost of integrations and interoperabilitybetween systems. While there are many standards that pertain in some way to IAM, three protocols havethe strongest bearing, especially for on-premise corporate IAM systems:

21.1 Security Assertions Markup Language (SAML)

SAML is used by an application, referred to as a service provider (SP), to externalize user identification,authentication and (in some cases) authorization to another application, referred to as the identity provider(IdP). In other words, it enables standards-based federation interoperability between SPs and IdPs.

IAM systems normally manage the contents of one or more directories, while IdPs consume directory datato identify users, possibly to authenticate them (testing passwords via LDAP binds or similar methods) andpossibly to authorize them (based on attributes and group memberships in the directory).

In some cases, such as login interoperability with a service catalog, as described in item 2 on Page 57, itis desirable to enable federated login into both the IAM system and other systems. This is the IAM-as-SPscenario, useful in larger IAM deployments.

Some IAM systems are able to, in addition to IAM functions, respond to SAML requests and issue SAMLassertions about users. This is the IAM-as-IdP scenario, and while it’s not strictly an IAM function, it canreduce overall TCO by folding SAML IdP functionality into the IAM system.

SAML is described at:https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

21.2 Service Provisioning Markup Language (SPML)

IAM systems integrate with other systems and applications in a variety of ways: by invoking their remoteaccess management application programming interfaces (APIs), through SQL injection, through scriptedcommand-line interaction or even through scripted interaction with their user interfaces. The reason for thevariety of integration styles and the need for many connectors is that few applications are developed withIAM integration in mind and so the IAM system must use whatever means necessary to read current identityand entitlement data and to push updates to these data.

It would be nice if applications exposed a standards-based API for managing accounts, entitlements andcredentials, instead of either proprietary APIs or none at all. SPML was designed as a standard protocolfor this purpose. Applications would respond to SPML requests and create/delete accounts, assign/revokeentitlements, etc. IAM systems could then use a single connector to integrate with every application. Alter-nately, IAM systems could expose a SPML service, which proxies operations on systems and applicationsintegrated via proprietary mechanisms. This allows organizations to migrate from one IAM system to an-other, using the old one as an integration proxy until the new one can be configured with all the requiredintegrations.

Unfortunately, very few applications adopted SPML at all and SPML services in IAM systems are not easilycompatible. As a result, SPML remains a great idea, but of limited real-world utility.


https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language


SPML is described at:https://en.wikipedia.org/wiki/Service_Provisioning_Markup_Language

21.3 System for Cross-domain Identity Management (SCIM)

SCIM was developed in recognition of the same need that SPML attempts to address, and with a desireto solve the IAM-to-application interoperability at least for SaaS applications such as Google Apps andSalesforce.com. SCIM is a different XML protocol that serves much the same need as SPML, but is actuallysupported by a small number of widely deployed SaaS applications.

IAM systems should include a SCIM connector to more easily integrate with SCIM-compatible applications.

SCIM is described at:http://www.simplecloud.info/


https://en.wikipedia.org/wiki/Service_Provisioning_Markup_Language

http://www.simplecloud.info/


22 Integration to social platforms and OAuth

OAuth is another standard that relates to IAM systems, but mainly for consumer-facing portals and theirsupporting IAM systems, rather than for corporate deployments.

OAuth allows one web site to externalize user identification and authentication to another web site. It issupported by major consumer-facing sites such as Facebook.com, Google.com, Live.com (Microsoft) andYahoo.com all of which can act as OAuth-federated IdPs. In consumer-facing IAM systems, OAuth is usedto:

1. Simplify enrollment, i.e. "use Facebook," "use Google" and similar icons on the profile creation page.If a user clicks on one of these icons, they are prompted by the relevant service to approve the actionand then a profile is created with minimal effort.

2. Externalize authentication, i.e. "Sign in using Facebook" and similar icons, instead of having to createa separate password on the site in question.

Consumer-facing IAM systems should strongly consider OAuth, at least to augment and ideally to replacecredentials local to the application that the IAM system supports.

OAuth is described at http://oauth.net/.


http://oauth.net/


23 Access from on-premise PC, VPN and mobile/BYOD

Users are increasingly mobile. They may wish to do work at any time, using any device, from any location:

User locations Types of devices

• On-premise, wired.• On-premise, via WiFi.• Anywhere, via VPN.• No VPN activated or available.

• Corporate PC, typically running Windows anddomain member.

• Corporate iOS or Android device, managed viaMDM, typically no VPN.

• Personal iOS or Android device.• Personal PC - MacOS, Windows, Linux.

IAMaaS aside (as it is not yet widely deployed), most IAM systems are deployed on-premise, where it iseasiest to integrate with and manage on-premise systems and applications. This creates a problem, asmany of the location/device combinations above are outside the corporate network and do not have a VPN.However, it is desirable to access the on-premise IAM system:

1. Users should be able to approve change requests using their BYOD, without physical or virtual con-nection to the corporate network.

2. Users should be able to reset forgotten passwords, including locally cached passwords on their cor-porate laptops, even when they are off-site and cannot sign into their PC, never mind establish aVPN.

3. Users should be able to look up each-others’ profiles and add contacts to their phones.

These are core scenarios, not exotic edge cases and the IAM system should be configured to support them:

1. Password reset software should be deployed on corporate PCs, integrated with the corporate VPN tosupport off-site, pre-login password reset.

2. Mobile apps should be deployed to user phones and tablets, integrated with cloud-hosted proxies toenable interaction with on-premise IAM systems.

www.Hitachi-ID.com

500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: [email protected]

Date: 2015-09-01 File: / pub/ wp/ documents/ bestpractice/ hiim/ iam-bp-7.tex


Documents

Best Practices - IAM Solutions · · 2016-10-04Best Practices for Identity and Access Management 1 Introduction This document lays out best practices for identity and access management