ENTERPRISE IDENTITY &

ACCESS MANAGEMENT
(IAM)
TRAINING MODULE
This material is meant for IBM Academic Initiative use only. NOT FOR RESALE.
Enterprise IAM Training Module

July 2019
NOTICES

This information was developed for products and services offered in the USA.
IBM may not offer the products, services, or features discussed in this document
in other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user’s responsibility to evaluate and verify the
operation non-IBM product, program, or service. IBM may have patents or
pending patent applications covering subject matter described in this document.
The furnishings of this document do not grant you any license to these patents.
You can send license inquiries, in writing, to:
IBM Director of Licensing IBM Corporation North Castle Drive, MD-NC119
Armonk, NY 10504-1785 United States of America

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES
THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied warranties in certain
transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in the new editions on the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described
in this publication at any time without notice.

Any inference in this information to non-IBM websites are provided for

convenience only and do not in any manner serve as an endorsement of these
websites. The materials at those websites are not part of the materials for this IBM
product, and use of those websites is at your own risk.
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you. Information
concerning non-IBM products was obtained from the suppliers of those products,
their published announcements, or other publicly available sources. IBM has not
tested those products and cannot confirm the accuracy of performance,
compatibility, or any other claims related to the non-IBM products. Questions on

© 2019 IBM Corporation 2

Enterprise IAM Training Module

the capabilities of non-IBM products should be addressed to the suppliers of those

products.
This information contains examples of data reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
TRADEMARKS

IBM, the IBM logo and ibm.com are trademarks or registered trademarks of the
International Business Machines Corp., registered in many jurisdictions
worldwide. Other product and service names might be trademarks of IBM or
other companies. A current list of IBM trademarks in available on the web at
“Copyright and trademark information” at www.ibm.com/legal/copytrade.html.
Adobe, and the Adobe logo are either registered trademarks or trademarks of
Adobe Systems Incorporated in the United States, and/or other countries.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.

© Copyright International Business Machines Corporation 2019.

This document may not be reproduced in whole or in part without prior
permission of IBM.

US Government Users Restricted Rights – Use, duplication, or disclosure

restricted by GSA ADP Schedule Contract with IBM Corp.

© 2019 IBM Corporation 3

Enterprise IAM Training Module

Table Of Contents

UNIT 1: INTRODUCTION TO IAM .............................................12

CHAPTER 1: INTRODUCTION ........................................................................ 14
Identity Management (IdM) ....................................................................... 14
Access Management (AM) ......................................................................... 15
Five Elements of Security ........................................................................... 15
Authentication ...................................................................................... 15
Authorization........................................................................................ 16
AAA Services ........................................................................................ 16
Auditing ................................................................................................ 17
Accountability ...................................................................................... 18
Key concepts of Identity and Access Management .................................... 18
What IAM terms should I know? ................................................................ 19
Uniting Identity and Access Management ................................................. 21
Need of IAM ............................................................................................... 22
CHAPTER 2: IAM FOR AN ENTERPRISE........................................ 24
Business Challenges ................................................................................... 24
IAM Strategy Framework........................................................................... 26
Identity Management Drivers .................................................................... 28
Cost of IAM Over Time .............................................................................. 28
Business Drivers of IAM ............................................................................ 29
IAM vendors ............................................................................................... 31
UNIT 2: LDAP BASICS ...................................................................33
CHAPTER 3: INTRODUCTION TO LDAP ........................................ 34
Directories.................................................................................................. 35
Directory versus Database .................................................................. 35
LDAP: Protocol or Directory .................................................................... 38
Directory Clients and Servers.............................................................. 39
Distributed Directories ........................................................................ 39
Advantages of using a Directory ................................................................ 41
LDAP History and Standards .................................................................... 42
OSI and the Internet ............................................................................. 43
X.500 The Directory Server Standard ................................................. 43
Lightweight Access to X.500 ................................................................ 44
Beyond LDAPv3 ................................................................................... 45
Directory Components ............................................................................... 46
LDAP Standards ........................................................................................ 47
Test Your Knowledge ................................................................................. 48

© 2019 IBM Corporation 4

Enterprise IAM Training Module

CHAPTER 4: LDAP CONCEPTS & ARCHITECTURE ................... 49

Overview of LDAP Architecture ................................................................ 49
The Informational Model ........................................................................... 51
LDIF ..................................................................................................... 54
LDAP Schema ...................................................................................... 55
THE NAMING MODEL ............................................................................. 61
LDAP Distinguished Name Syntax (DNS) ........................................... 62
String Form .......................................................................................... 64
URL Form ............................................................................................ 65
Functional Model ....................................................................................... 66
Query.................................................................................................... 66
Referrals and Continuation References ............................................... 68
Search Filter Syntax............................................................................. 68
Compare ............................................................................................... 70
Update Operations ............................................................................... 70
Authentication Operations ................................................................... 70
Controls and extended operations ....................................................... 71
Security model ............................................................................................ 72
Directory security ...................................................................................... 72
No authentication ................................................................................. 73
Basic authentication ............................................................................ 73
SASL ..................................................................................................... 74
SSL and TLS ......................................................................................... 74
Test Your knowledge .................................................................................. 76
CHAPTER 5: LDAP REPLICATION................................................... 77
Overview of Replication ............................................................................. 77
Simple Replication ............................................................................... 78
Cascading Replication ......................................................................... 79
Peer-to-Peer Replication ..................................................................... 79
Gateway Replication ............................................................................ 80
Test your Knowledge .................................................................................. 81
UNIT 3: SINGLE SIGN-ON (SSO) CONCEPTS ..........................82
CHAPTER 6: SINGLE SIGN-ON TECHNIQUES .............................. 83
Introduction ................................................................................................ 83
Types of Single Sign-On ............................................................................. 84
Where they are Deployed: ................................................................... 85
i. Intranet or Enterprise SSO (ESSO) ........................................................... 85
ii. Extranet or Multi-Domain SSO .............................................................. 85
iii. Internet of Web-SSO ............................................................................... 85
b) Complex SSO Architecture ........................................................................... 87
Single sign-on Protocols ............................................................................ 89
Kerberos authentication Protocol ................................................. 89

© 2019 IBM Corporation 5

Enterprise IAM Training Module

b) Security Assertion Markup Language ........................................... 89

c) OpenID .......................................................................................... 90
BrowserID ..................................................................................... 91
e) OAuth2 ........................................................................................... 91
f) LDAP ............................................................................................. 92
g) CAS ................................................................................................ 93
CHAPTER 7: ACCESS CONTROL ..................................................... 95
Discretionary Access Control (DAC) ........................................................ 95
Mandatory Access Control (MAC) ............................................................ 95
Role Based Access Control (RBAC) .......................................................... 96
Attribute-based access control (ABAC) ..................................................... 98
Benefits of RBAC.................................................................................. 98
RBAC Framework model components ................................................. 99
Static Separation of Duty (SSoD)............................................................. 102
Dynamic Separation of Duty (DSoD) ...................................................... 103
Fine grained and coarse-grained access control .................................... 105
Coarse grained................................................................................... 105
Fine grained authorization ................................................................ 106
Overview of Context Based Access .......................................................... 107
Risk Management Overview .............................................................. 107
Business Scenarios ............................................................................. 108
UNIT 4: PASSWORD MANAGEMENT .....................................110
CHAPTER 8: PASSWORD MANAGEMENT................................................... 111
The Challenges of Password Management .............................................. 111
The Security Threats to Passwords .......................................................... 111
Single Password v/s Multiple Passwords ................................................ 112
Considerations for Using Different Passwords For Different Applications
113
General Systems ................................................................................. 113
Critical Systems and Resources ............................................................ 113
Internal and External Applications ....................................................... 113
Systems with the Same Security Requirements .................................. 114
Good Password Management Policies & User ....................................... 114
System Security Features ......................................................................... 114
UNIT 5: INTRODUCTION TO SINGLE SIGNON METHODS ..... 116
CHAPTER 9: DIFFERENT SSO METHODS.................................................. 117
Forms Single Sign-On .............................................................................. 117
Kerberos and SPNEGO ........................................................................... 117
Kerberos ................................................................................................ 117
SPNEGO ............................................................................................ 118
Certificate Based ...................................................................................... 119
Steps for Configuring Certificate-based Authentication ................... 120

© 2019 IBM Corporation 6

Enterprise IAM Training Module

Certificates and Certificate Authorities (CA) .................................... 121

UNIT 6: INTRODUCTION TO FEDERATION .........................122
CHAPTER 10: FEDERATION OVERVIEW.................................................... 123
By Definition ......................................................................................... 124
Federated Identity Management Architecture ...................................... 125
Architecture Overview ....................................................................... 126
Roles ................................................................................................... 130
Identity provider - IdP ....................................................................... 130
Service provider – SP ........................................................................ 131
CHAPTER 11: FEDERATION PROTOCOLS .................................................. 132
Security Assertion Markup Language (SAML) ..................................... 132
Assertions .............................................................................................. 133
SAML 2.0 overview ............................................................................ 133
SAML 2.0 profiles .............................................................................. 134
SAML 2.0 endpoints and URLs .......................................................... 136
SAML 2.0 bindings ............................................................................. 137
SAML 2.0 name identifier formats ..................................................... 138
SAML 2.0 Service Provider Worksheet.............................................. 139
Liberty ................................................................................................... 143
WS-Federation ...................................................................................... 144
OAuth 2.0 concepts ............................................................................... 145
OAuth 2.0 endpoints .......................................................................... 147
OAuth 2.0 workflow ........................................................................... 148
OpenID Connect federations ................................................................ 155
OpenID Connect endpoints ................................................................ 157
Selecting Federation standards ............................................................ 159
Functional Comparison of federation protocols .................................. 159
UNIT 7: MULTI FACTOR AUTHENTICATION (MFA) ........164
CHAPTER 12: ORIGIN OF MFA ................................................................ 165
Introduction ........................................................................................... 166
Multi-factor authentication versus multi-step authentication .............. 167
Multi-factor authentication methods..................................................... 169
U2F security keys ............................................................................... 169
Physical one-time PIN tokens ............................................................ 169
Biometrics .......................................................................................... 170
Smartcards ......................................................................................... 170
Mobile apps ........................................................................................ 171
SMS messages, emails or voice calls ................................................. 171
Software certificates .......................................................................... 172
Time-based one-time password (TOTP) ............................................... 173
One-time password (OTP) .................................................................... 173
Benefits of a one-time password ........................................................ 176
HOTP vs TOTP: What's the Difference? .............................................. 176

© 2019 IBM Corporation 7

Enterprise IAM Training Module

HOTP: Event-based One-Time Password ......................................... 176

Several techniques that use OTP ....................................................... 176
TOTP: Time-based One-Time Password ........................................... 177
Comparison ........................................................................................ 177
Choice .............................................................................................. 178
UNIT 8: INTRODUCTION TO AUDITING & REPORTING .179
CHAPTER 13: AUDITING & REPORTING ................................................... 180
Auditing ................................................................................................. 180
Auditing to Assess Effectiveness ........................................................ 181
Inspection Audits ................................................................................ 182
Access Review Audits ......................................................................... 182
User Entitlement Audits ..................................................................... 183
The Role of Internal Auditors ............................................................... 183
Reporting Audit Results ........................................................................ 184
Protecting Audit Results ....................................................................... 184
Distributing Audit Reports .................................................................... 185
Using External Auditors ....................................................................... 185
UNIT 9: IDENTITY MANAGEMENT AND USER
PROVISONING ..............................................................................186
CHAPTER 13: INTRODUCTION TO IDENTITY MANAGER........................... 187
Business Challenges.............................................................................. 187
Solution ................................................................................................. 187
Identity Manager ................................................................................... 188
Centralized User Management ............................................................. 191
a) Capabilities of an identity management as centralized user
management ................................................................................................ 192
i. Adapters to access controlled systems .................................................. 192
ii. Password management ......................................................................... 194
iii. Access rights accountability ................................................................. 195
iv. Access request approval and process automation ................................ 196
v. Access request audit trails ................................................................. 198
vi. Distributed administration .................................................................... 199
vii. User administration policy automation ................................................ 200
viii. Self-regulating user administration across organizations.................... 201
Benefits of Centralized User Management ........................................ 202
i. Single Interface ........................................................................................ 202
ii. Security Policy Enforcement ................................................................. 203
iii. Central Password Management ............................................................ 203
iv. Delegation of Administration ................................................................ 204
v. User Self-Care....................................................................................... 204
vi. Multiple Repository Support ................................................................. 204
vii. Workflow ............................................................................................... 205
viii. Centralized Auditing and Reporting .................................................. 206

© 2019 IBM Corporation 8

Enterprise IAM Training Module

Simplify User Management ................................................................... 206

a) Automation of Business Processes ..................................................... 206
Automated Default and Validation Policies ...................................... 207
Single Access Control Models ........................................................... 207
Ubiquitous Management Interfaces ................................................... 207
Integration of other Management Architectures ............................... 208
Lifecycle Management .......................................................................... 208
a) The Creation Cycle ............................................................................ 210
The provisioning cycle ..................................................................... 210
The modification cycle ....................................................................... 210
The termination cycle......................................................................... 211
Reconciliation .................................................................................... 211
Access Control Models of Identity Manager ........................................ 212
a) Role-Based Access Control [RBAC] Model ...................................... 212
Discretionary Access Control [DAC] Model ................................... 214
Mandatory Access Control [MAC] Model ........................................ 214
Corporate Regulatory Compliance Using Identity Management ......... 215
a) Provisioning and the approval workflow process ............................. 216
Audit trail tracking............................................................................. 217
Enhanced compliance status ............................................................ 218
Password policy and password compliance .................................... 218
Account and access provisioning authorization and enforcement ... 219
Recertification policy and process ................................................... 219
Reports .............................................................................................. 220
Test your Knowledge............................................................................. 221
UNIT 10: IDENTITY MANAGER STRUCTURE &
COMPONENTS ..............................................................................222
CHAPTER 14: IDENTITY MANAGER STRUCTURE & COMPONENTS .......... 223
Identity Manager Entities .................................................................. 223
Users, Accounts, And Attributes ........................................................ 223
Identity feed ........................................................................................ 224
Passwords .......................................................................................... 225
Managed systems and applications ................................................... 225
Role .................................................................................................... 226
Policy ................................................................................................. 228
Identity Policy .................................................................................... 228
Password Policy................................................................................. 229
Adoption Policy .................................................................................. 229
Provisioning Policy............................................................................ 230
Separation of Duty Policy .................................................................. 230
Recertification Policy ........................................................................ 231
Logical Component Architecture of Identity Manager ...................... 231
Test your Knowledge ......................................................................... 233

© 2019 IBM Corporation 9

Enterprise IAM Training Module

UNIT 11: IAM GOVERNANCE ...................................................234

CHAPTER 15: IDENTITY & ACCESS MANAGEMENT GOVERNANCE.......... 235
Introduction........................................................................................ 235
The Approach: Integrated IAM Governance with Intelligence and
Accountability ....................................................................................................... 236
Access and Role Certification ............................................................ 238
Access request and fulfillment ........................................................... 240
Access Enforcement ........................................................................... 241
Detecting and Fixing Anamoly and Noncompliance ......................... 242
Role and Entitlement Mining and Modeling ...................................... 242
Role and User Lifecycle Management ............................................... 244
Delegated Administration .................................................................. 245
Actionable Reporting, Auditing and Monitoring ............................... 245
Analytics and Intelligence ..................................................................... 247
IAM Governance for Cloud, Mobile and Social Media Resources ...... 247
Test your Knowledge ......................................................................... 247
UNIT 12: PRIVLEGED IDENTITY MANAGER ......................248
CHAPTER 16: PRIVILEGED IDENTITY MANAGER ...................................... 249
What is Privileged Identity ................................................................ 249
Privileged IDs and why they are a problem ...................................... 249
What is Privileged Identity Manager ................................................. 254
UNIT 13: IAM ON CLOUD ...........................................................255
CHAPTER 17: CLOUD IAM ........................................................................ 256
Introduction........................................................................................ 256
Evolution of IAM over the Years........................................................ 256
Diving into IAM ................................................................................. 257
Defining the Cloud Paradigm ............................................................ 258
Cloud Deployment Models................................................................. 259
Introducing IDaaS ............................................................................. 259
Understanding IDaaS Advantages..................................................... 260
Planning Your IDaaS Strategy .......................................................... 262
Hybrid environments.......................................................................... 263
Planning Your Success with IDaaS ................................................... 263
APPENDIX ......................................................................................265

© 2019 IBM Corporation 10

Enterprise IAM Training Module

© 2019 IBM Corporation 11

Enterprise IAM Training Module

UNIT 1: INTRODUCTION TO IAM

© 2019 IBM Corporation 12

Enterprise IAM Training Module

IAM is a complex process consisting of various policies, procedures, activities,

and technologies that require the coordination of many companywide groups such
as human resources and IT. Fundamentally, IAM attempts to address three
important questions:

1. Who has access to what information?

A robust identity and access management system will help a company not only
to manage digital identities, but to manage the access to resources, applications,
and information these identities require as well.

2. Is the access appropriate for the job being performed?

This element takes on two facets. First, is this access correct and defined
appropriately to support a specific job function? Second, does access to a specific
resource conflict with other access rights, thus posing a potential segregation of
duties problem?

3. Is the access and activity monitored, logged, and reported

appropriately?
In addition to benefiting the user through efficiency gains, IAM processes should
be designed in a manner that supports regulatory compliance. One of the larger
regulatory realities under Sarbanes-Oxley and other regulations is that access
rights must be defined, documented, monitored, logged, and reported
appropriately.

© 2019 IBM Corporation 13

Enterprise IAM Training Module

CHAPTER 1: Introduction
Identity Management (IdM)
The term refers to the entire set of processes and technologies for maintaining
and updating digital identities. Identity lifecycle management includes identity
synchronization, provisioning, de-provisioning, and the ongoing management of
user attributes, credentials and entitlements. It manages identity’s lifecycle
through a combination of processes, organizational structure, and enabling
technologies.

© 2019 IBM Corporation 14

Enterprise IAM Training Module

Access Management (AM)

Access management refers to the processes and technologies used to control
and monitor network access. Access management features, such as
authentication, authorization, trust and security auditing, are part and parcel
of the top ID management systems for both on-premises and cloud-based
systems. It primarily focuses on as Authentication and Authorization.

Authentication Authorization
Any combination of the 2 primary forms of Authorization:
following 3 factors will  Coarse-Grain
be considered as Strong  High-level and overarching
authentication: entitlements
 What you know  Create, Read, Update, Modify
 Password  Fine-Grain
 Passphrase  Detailed and explicit
 What you are entitlements
 Iris  Based on factors such as time,
 Fingerprint dept, role and location
 What you have
 Token
 Smartcard

Five Elements of Security

 Authentication

The process of verifying or testing that the claimed identity is valid is

authentication. Authentication requires from the subject additional information
that must exactly correspond to the identity indicated. The most common form of
authentication is using a password (this includes the password variations of PINs
and passphrases). Authentication verifies the identity of the subject by comparing
one or more factors against the database of valid identities (that is, user accounts).

The capability of the subject and system to maintain the secrecy of the
authentication factors for identities directly reflects the level of security of that
system. If the process of illegitimately obtaining and using the authentication
factor of a target user is relatively easy, then the authentication system is insecure.
If that process is relatively difficult, then the authentication system is reasonably
secure.

© 2019 IBM Corporation 15

Enterprise IAM Training Module

Identification and authentication are always used together as a single two-step

process. Providing an identity is the first step and providing the authentication
factor(s) is the second step. Without both, a subject cannot gain access to a
system—neither element alone is useful in terms of security.

A subject can provide several types of authentication (for example, something

you know, something you have, and so on). Each authentication technique or
factor has its unique benefits and drawbacks. Thus, it is important to evaluate
each mechanism in light of the environment in which it will be deployed to
determine viability.

 Authorization

Once a subject is authenticated, access must be authorized. The process of

authorization ensures that the requested activity or access to an object is
possible given the rights and privileges assigned to the authenticated identity. In
most cases, the system evaluates an access control matrix that compares the
subject, the object, and the intended activity. If the specific action is allowed,
the subject is authorized. If the specific action is not allowed, the subject is not
authorized.

Keep in mind that just because a subject has been identified and authenticated
does not mean they have been authorized to perform any function or access all
resources within the controlled environment. It is possible for a subject to be
logged onto a network (that is, identified and authenticated) but to be blocked
from accessing a file or printing to a printer (that is, by not being authorized to
perform that activity). Most network users are authorized to perform only a
limited number of activities on a specific collection of resources. Identification
and authentication are all-or-nothing aspects of access control.

Authorization has a wide range of variations between all or nothing for each
object within the environment. A user may be able to read a file but not delete
it, print a document but not alter the print queue, or log on to a system but not
access any resources. Authorization is usually defined using one of the concepts
of access control, such as discretionary access control (DAC), mandatory access
control (MAC), or role-based access control (RBAC).

 AAA Services

You may have heard of the concept of AAA services. The three As in this
acronym refer to authentication, authorization, and accounting (or sometimes

© 2019 IBM Corporation 16

Enterprise IAM Training Module

auditing). However, what is not as clear is that although there are three letters in
the acronym, it refers to five elements: identification, authentication,
authorization, auditing, and accounting. Thus, the first and the third/last A
actually represent two concepts instead of just one.

These five elements represent the following processes of security:

 Identification claiming an identity when attempting to access a secured

area or system.

 Authentication proving that you are that identity.

 Authorization defining the allows and denials of resource and object

access for a specific identity.

 Auditing recording a log of the events and activities related to the system
and subjects.

 Accounting (aka accountability) reviewing log files to check for

compliance and violations in order to hold subjects accountable for their
actions Although AAA is often referenced in relation to authentication
systems, it is in fact a foundational concept of all forms of security. As
without any one of these five elements, a security mechanism would be
incomplete.

 Auditing

Auditing, or monitoring, is the programmatic means by which a subject’s actions

are tracked and recorded for holding the subject accountable for their actions
while authenticated on a system. It is also the process by which unauthorized or
abnormal activities are detected on a system.
Auditing is recording activities of a subject and its objects as well as recording
the activities of core system functions that maintain the operating environment
and the security mechanisms.

The audit trails created by recording system events to logs can be used to evaluate
the health and performance of a system. System crashes may indicate faulty
programs, corrupt drivers, or intrusion attempts. The event logs leading up to a
crash can often be used to discover the reason a system failed. Log files provide
an audit trail for re-creating the history of an event, intrusion, or system failure.
Auditing is needed to detect malicious actions by subjects, attempted intrusions,

© 2019 IBM Corporation 17

Enterprise IAM Training Module

and system failures and to reconstruct events, provide evidence for prosecution,
and produce problem reports and analysis.

 Accountability

An organization’s security policy can be properly enforced only if accountability

is maintained. In other words, you can maintain security only if subjects are held
accountable for their actions. Effective accountability relies on the capability to
prove a subject’s identity and track their activities.

Accountability is established by linking a human to the activities of an online

identity through the security services and mechanisms of auditing, authorization,
authentication, and identification. Thus, human accountability is ultimately
dependent on the strength of the authentication process. Without a strong
authentication process, there is doubt that the human associated with a specific
user account was the actual entity controlling that user account when the
undesired action took place.

To have viable accountability, you must be able to support your security in a court
of law. If you are unable to legally support your security efforts, then you will be
unlikely to be able to hold a human accountable for actions linked to a user
account. With only a password as authentication, there is significant room for
doubt. Passwords are the least secure form of authentication, with dozens of
different methods available to compromise them.

Key concepts of Identity and Access

Management
To create a secure environment, you need to account for the following
components of Identity and Access management Solution:

 User identity, authentication, and authorization service: Enables

applications deployed to the cloud to externalize the authentication of users
to a range of different identity providers.

 Multifactor authentication: Combats identity theft by adding an additional

level of authentication for application users.

 Directory services: Hosts the user profiles and associated credentials that
are used to access applications.

© 2019 IBM Corporation 18

Enterprise IAM Training Module

 Reporting: Provides a user-centric view of access to resources or a resource-

centric view of access by users.

 Audit and compliance: Validate implemented controls against an

organization's security policy, industry compliance, and risk policies and to
report deviations.

 User access management: Enables cloud providers to manage user

identities in cloud-based platforms, applications, and services.

What IAM terms should I know?

Few key terms in the identity management space are worth knowing:

 Active Directory (AD): Microsoft developed AD as a user-identity directory

service for Windows domain networks. Though proprietary, AD is included
in the Windows Server operating system and is thus widely deployed.

 Biometric authentication: A security process for authenticating users that

relies upon the user’s unique characteristics. Biometric authentication
technologies include fingerprint sensors, iris and retina scanning, and facial
recognition.

 Context-aware network access control: Context-aware network access

control is a policy-based method of granting access to network resources
according to the current context of the user seeking access. For example, a
user attempting to authenticate from an IP address that hasn’t been
whitelisted would be blocked.

 Credential: An identifier employed by the user to gain access to a network

such as the user’s password, public key infrastructure (PKI) certificate, or
biometric information (fingerprint, iris scan).

 De-provisioning: The process of removing an identity from an ID repository

and terminating access privileges.

 Digital identity: The ID itself, including the description of the user and
his/her/its access privileges. (“Its” because an endpoint, such as a laptop or
smartphone, can have its own digital identity.)

© 2019 IBM Corporation 19

Enterprise IAM Training Module

 Entitlement: The set of attributes that specify the access rights and
privileges of an authenticated security principal.

 Identity as a Service (IDaaS): Cloud-based IDaaS offers identity and

access management functionality to an organization’s systems that reside on-
premises and/or in the cloud.

 Identity lifecycle management: Identity synchronization: The process of

ensuring that multiple identity stores—say, the result of an acquisition—
contain consistent data for a given digital ID.

 Lightweight Directory Access Protocol (LDAP): LDAP is open standards-

based protocol for managing and accessing a distributed directory service,
such as Microsoft’s AD

 Multi-factor authentication (MFA): MFA is when more than just a single

factor, such as a user name and password, is required for authentication to a
network or system. At least one additional step is also required, such as
receiving a code sent via SMS to a smartphone, inserting a smart card or
USB stick, or satisfying a biometric authentication requirement, such as a
fingerprint scan.

 Password reset: In this context, it’s a feature of an ID management system

that allows users to re-establish their own passwords, relieving the
administrators of the job and cutting support calls. The reset application is
often accessed by the user through a browser. The application asks for a
secret word or a set of questions to verify the user’s identity.

 Privileged account management: This term refers to managing and

auditing accounts and data access based on the privileges of the user. In
general terms, because of his or her job or function, a privileged user has
been granted administrative access to systems. A privileged user, for
example, would be able set up and delete user accounts and roles.

 Provisioning: The process of creating identities, defining their access

privileges and adding them to an ID repository.

 Risk-based authentication (RBA): Risk-based authentication dynamically

adjusts authentication requirements based on the user’s situation at the
moment authentication is attempted. For example, when users attempt to
authenticate from a geographic location or IP address not previously

© 2019 IBM Corporation 20

Enterprise IAM Training Module

associated with them, those users may face additional authentication

requirements.

 Security principal: A digital identity with one or more credentials that can
be authenticated and authorized to interact with the network.

 Single sign-on (SSO): A type of access control for multiple related but
separate systems. With a single username and password, a user can access a
system or systems without using different credentials.

 User behaviour analytics (UBA): UBA technologies examine patterns of

user behaviour and automatically apply algorithms and analysis to detect
important anomalies that may indicate potential security threats. UBA differs
from other security technologies, which focus on tracking devices or security
events. UBA is also sometimes grouped with entity behaviour analytics and
known as UEBA.

Uniting Identity and Access Management

Identity and access management (IAM) is the process of managing who has
access to what information over time. This cross-functional activity involves the
creation of distinct identities for individuals and systems, as well as the
association of system and application-level accounts to these identities. IAM
processes are used to initiate, capture, record, and manage the user identities and
related access permissions to the organization’s proprietary information. These
users may extend beyond corporate employees.
For instance, users could include vendors, customers, floor machines, generic
administrator accounts, and electronic physical access badges. The means used
by the organization to facilitate the administration of user accounts and to
implement proper controls around data security form the foundation of IAM.

© 2019 IBM Corporation 21

Enterprise IAM Training Module

Need of IAM

Secure user access plays a key role in the exchange of data and information. In
addition, electronic data is becoming ever more valuable for most companies.
Access protection must therefore meet increasingly strict requirements – an
issue that is often solved by introducing strong authentication. Modern IAM
solutions allow administering users and their access rights flexibly and
effectively, enabling multiple ways of cooperation.

Also, IAM is a prerequisite for the use of cloud services, as such services may
involve outsourcing of data, which in turn means that data handling and access
has to be clearly defined and monitored. At the same time, companies are facing
the challenge of having to work with various forms of IAM data provided by
historically grown systems. To be able to meet current security requirements and
react quickly if required, they need to identify and consolidate such data sources
and define a data lifecycle. The governance level defines the regulatory
framework and the compliance and review procedures. The management level
allows administration of identities, rights and authorization tokens. The execution

© 2019 IBM Corporation 22

Enterprise IAM Training Module

level ensures information review as well as synchronization at runtime. It can be

difficult to get funding for IAM projects because they don’t directly increase
either profitability or functionality.

However, a lack of effective identity and access management poses significant

risks not only to compliance but also an organization’s overall security. These
mismanagement issues increase the risk of greater damages from both external
and inside threats. Keeping the required flow of business data going while
simultaneously managing its access has always required administrative attention.
The business IT environment is ever evolving, and the difficulties have only
become greater with recent disruptive trends like bring-your-own-device
(BYOD), cloud computing, mobile apps and an increasingly mobile workforce.
A common problem is that privileges are granted as needed when employee duties
change but the access level escalation is not revoked when it is no longer required.
This situation and request like having access like another employee rather than
specific access needs leads to an accumulation of privileges known as privilege
creep. Privilege creep creates security risk in two different ways. An employee
with privileges beyond what is warranted may access applications and data in an
unauthorized and potentially unsafe manner.

Furthermore, if an intruder gains access to the account of a user with excessive

privileges, he may automatically be able to do more harm. Data loss or theft can
result from either scenario. Typically, this accumulation of privilege is of little
real use to the employee or the organization. At best, it might be a convenience
in situations when the employee is asked to do unexpected tasks.

On the other hand, it might make things much easier for an attacker who manages
to compromise an over-privileged employee identity. Poor identity access
management also often leads to individuals retaining privileges after they are no
longer employees.

© 2019 IBM Corporation 23

Enterprise IAM Training Module

CHAPTER 2: IAM For an Enterprise

Business Challenges
Today’s enterprise IT departments face the increasingly complex challenge of
providing granular access to information resources, using contextual information
about users and requests, while successfully restricting unauthorized access to
sensitive corporate data.

1. An increasingly distributed workforce

Organizations can recruit and retain the best talent is to remove the constraints of
geographic location and offer a flexible work environment. A remote workforce
allows businesses to boost productivity while keeping expenses in check as well
as untethering employees from a traditional office setting. However, with
employees scattered all over a country or even the world, enterprise IT teams face
a much more daunting challenge: maintaining a consistent experience for
employees connecting to corporate resources without sacrificing security. The
growth of mobile computing means that IT teams have less visibility into and
control over employees’ work practices. Solution is, a comprehensive, centrally
managed IAM solution returns the visibility and control needed for a distributed
workforce to an enterprise IT team.

2. Distributed applications

With the growth of cloud-based and Software as a Service (SaaS) applications,

users now have the power to log in to critical business apps like Salesforce,
Office365, Concur, and more anytime, from any place, using any device.
However, with the increase of distributed applications comes an increase in the
complexity of managing user identities for those applications. Without a seamless
way to access these applications, users struggle with password management while
IT is faced with rising support costs from frustrated users. Solution is a holistic
IAM solution can help administrators consolidate, control, and simplify access
privileges, whether the critical applications are hosted in traditional data centers,
private clouds, public clouds, or a hybrid combination of all these spaces.

© 2019 IBM Corporation 24

Enterprise IAM Training Module

3. Productive provisioning

Without a centralized IAM system, IT staff must provision access manually. The
longer it takes for a user to gain access to crucial business applications, the less
productive that user will be. On the flip side, failing to revoke the access rights
of employees who have left the organization or transferred to different
departments can have serious security consequences. To close this window of
exposure and risk, IT staff must de-provision access to corporate data as quickly
as possible.

Especially for large organizations, it is not an efficient or sustainable way to

manage user identities and access. Solution is the a robust IAM solution can fully
automate the provisioning and de-provisioning process, giving IT full power over
the access rights of employees, partners, contractors, vendors, and guests.
Automated provisioning and de provisioning speed the enforcement of strong
security policies while helping to eliminate human error.

4. Bring your own device (BYOD)

To manage or not to manage—there really is no choice between the two for

today’s enterprises. Employees, contractors, partners, and others are bringing in
personal devices and connecting to the corporate network for professional and
personal reasons. The challenge with BYOD is not whether outside devices are
brought into the enterprise network, but whether IT can react quickly enough to
protect the organization’s business assets—without disrupting employee
productivity and while offering freedom of choice. Nearly every company has
some sort of BYOD policy that allows users to access secure resources from their
own devices. However, accessing internal and SaaS applications on a mobile
device can be more cumbersome than doing so from a networked laptop or
desktop workstation.

In addition, IT staff may struggle to manage who has access privileges to

corporate data and which devices they’re using to access it. Solution is enterprises
must develop a strategy that makes it quick, easy, and secure to grant—and
revoke—access to corporate applications on employee- and corporate-owned
mobile devices based on corporate guidelines or regulatory compliance.

5. Password problems

The growth of cloud-based applications means that employees must remember

an increasing number of passwords for applications that may cross domains and

© 2019 IBM Corporation 25

Enterprise IAM Training Module

use numerous different authentication and attribute-sharing standards and

protocols. User frustration can mount when an employee spends more and more
time managing the resulting lists of passwords which, for some applications,
may require changing every 30 days. Plus, when employees have trouble with
their passwords, they most often contact IT staff for help, which can quickly and
repeatedly drain important resources.

Solution is Enterprises can readily make password issues a thing of the past by
federating user identity and extending secure single sign-on (SSO) capabilities
to SaaS, cloud based, web-based, and virtual applications. SSO can integrate
password management across multiple domains and various authentication and
attribute-sharing standards and protocols.

6. Regulatory compliance

Compliance and corporate governance concerns continue to be major drivers of

IAM spending. For example, much of the onus to provide the corporate
governance data required by Sarbanes- Oxley regulations fall on the IT
department. Ensuring support for processes such as determining access privileges
for specific employees, tracking management approvals for expanded access, and
documenting who has accessed what data and when they did it can go a long way
to easing the burden of regulatory compliance and ensuring a smooth audit
process.

Solution is a strong IAM solution can support compliance with regulatory

standards such as Sarbanes-Oxley, HIPAA, and the payment card industry data
security standards (PCI DSS). In particular, a solution that automates audit
reporting can simplify the processes for regulatory conformance and can also help
generate the comprehensive reports needed to prove that compliance.

IAM Strategy Framework

When developing an IAM strategy, we need to consider below matters-

• The risks associated with IAM and how they are addressed.
• The needs of the organization.
• How to start looking at IAM within the organization and what an effective
IAM process looks like.

© 2019 IBM Corporation 26

Enterprise IAM Training Module

• The process for identifying users and the number of users present within the
organization.
• The process for authenticating users.
• The access permissions that are granted to users.
• Whether users are inappropriately accessing IT resources.
• The process for tracking and recording user activity.
• The risks associated with IAM and how they are addressed.

 Inventory: gather information about users, access requirements,

applications and data
 Create: future state roadmap, associating user groups with access
controls, and designing operational support and workflow processes.

© 2019 IBM Corporation 27

Enterprise IAM Training Module

 Deploy: begin assigning access to systems and data using new processes
and workflows.
 Optimize: deploy automated and delegated processes only after steady
state has been achieved.
 Report: leverage investment to satisfy reporting requirements for
legislation and internal controls.

Identity Management Drivers

 Regulatory Compliance
 SOX
 GLBA
 HIPAA
 Efficiencies
 Productivity Loss
 Excessive Administration points
 Cost Savings
 Password resets
 Centralized reporting/attestation
 Security
 Rogue users (de-provision accounts)

Cost of IAM Over Time

 Higher initial cost of implementing and deploying an I&AM solution
compared to maintaining existing processes and tools.
 However, over a period of time:
o Maintaining existing tools for managing identities will increase in
costs.
o The deployment of I&AM will reduce costs.

© 2019 IBM Corporation 28

Enterprise IAM Training Module

Business Drivers of IAM

We can help organizations enable their business for growth and bring digital
identities and access rights under control by deploying an IAM solution. With
this surge, it is important to examine the many reasons why organizations
embark on IAM projects. These include:

 Improved Regulatory Compliance

Without overstating the effects of the regulations mentioned in the previous
paragraph, it is important to note that Sarbanes- Oxley, HIPAA, GLBA, Basel
II, and other regulations have significantly impacted organizations worldwide.
However, while IAM initiatives have helped fill the gaps related to system
access controls, they may not have gone far enough. Many companywide IAM
initiatives are merely stopgaps to regulatory compliance. Although this
approach to dealing with IAM may pass an audit, it may hinder the organization
in the future as the IAM program becomes overly complex, inoperable, and
costly. Organizations also must be aware that IAM programs frequently collect
personal information about system users.

 Reduced Information Security Risk

A key driver to successful IAM implementation is the improved risk posture
that comes from the implementation of better identity and access controls. By
knowing who has access to what, and how access is directly relevant to a
particular job or function, IAM improves the strength of the organization’s

© 2019 IBM Corporation 29

Enterprise IAM Training Module

overall control environment. In many organizations, the removal of user access

rights or access rights for a digital identity can take up to three to four months.
This may present an unacceptable risk to the organization, especially if an
individual is able to continue accessing company systems and resources during
the access removal period.

 Reduced IT Operating and Development Costs

Ironically, the proliferation of automated systems can negatively impact worker
efficiency due to the different sign-on mechanisms used. As a result, workers
must remember or carry a variety of credentials that change frequently. For
example, a typical employee may have a username and password for their
desktop, a different username and password to gain access to other systems,
several more usernames and passwords for different desktop and browser
applications, and a personal identification number (i.e., PIN) with a one-time
use password for remote access.
For example, many organizations are faced with the following circumstances:
• A lack of defined and automated approval workflows, resulting in a best guess
by an administrative assistant when initiating the provisioning process and
handling access requests.
• An increased number of help desk calls, many of which are related to identity
and access support, such as password-reset requests.
• Having new employees wait a week or longer to obtain baseline access to IT
systems, such as e-mail and network resources.
• Not documenting access requirements by role, so users have to make several
follow-up calls to get the access they need.

 Improved Operating Efficiencies and Transparency

Having a well-defined process for managing access to information can greatly
enhance a company’s operating efficiency. Many times, organizations struggle
with getting users the access they require to perform their job functions. For
instance, requests are forwarded to various members of the IT or administration
team who may not know what access or information a user is requesting or has a
business need to obtain. Additionally, without a defined process, requests may go
unfulfilled or be performed incorrectly, resulting in additional work on the part
of the IT or administration team.
Therefore, implementing a defined IAM process can greatly enhance the process’
efficiency. In large organizations, the appropriate use of enabling IAM
technologies can ensure a request is routed to the correct person for approval or
to the appropriate system configuration or automated provisioning system.

© 2019 IBM Corporation 30

Enterprise IAM Training Module

 Improved User Satisfaction

Besides the operating efficiencies mentioned earlier, implementing an effective
IAM process can enable users to identify the access they need, submit the
request to the appropriate approver, and quickly gain access to work
information. This, in turn, helps to reduce user frustration, which is particularly
important as new employees are hired (e.g., when new team members are
provided timely access to perform their job functions, they are productive
sooner).

 Increased Effectiveness of Key Business Initiatives

Often, certain business initiatives require access rights to be changed. These
typically include joint ventures, outsourcing partnerships, divestitures, mergers,
and acquisitions. For companies that are involved in these activities, the ability to
quickly provide access to the appropriate levels of information can enhance the
activity’s success significantly.
Conversely, without a well-defined process it may be difficult to determine
whether the correct level of access was granted or removed. For example,
during a joint venture or merger, timely access to appropriate information and
timely termination of access to certain company resources are critical.

IAM vendors
The identity and access management vendor landscape is a crowded one,
consisting of both pureplay providers such as Okta and OneLogin and large
vendors such as IBM, Microsoft and Oracle. Below is a list of leading players
based on Gartner’s Magic Quadrant for Access Management, Worldwide, which
was published in June 2017.

 Atos (Evidan)
 CA Technologies
 Centrify
 Covisint
 ForgeRock
 IBM Security Identity and Access Assurance
 I-Spring Innovations
 Micro Focus
 Microsoft Azure Active Directory
 Okta
 OneLogin
 Optimal idM

© 2019 IBM Corporation 31

Enterprise IAM Training Module

 Oracle Identity Cloud Service

 Ping
 SecureAuth

© 2019 IBM Corporation 32

Enterprise IAM Training Module

UNIT 2: LDAP BASICS

© 2019 IBM Corporation 33

Enterprise IAM Training Module

CHAPTER 3: Introduction To LDAP

Today people and businesses rely on networked computer systems to support

distributed applications. These distributed applications might interact with
computers on the same local area network, within a corporate intranet, within
extranets linking up partners and suppliers, or anywhere on the worldwide
Internet. To improve functionality and ease-of-use, and to enable cost-effective
administration of distributed applications, information about the services,
resources, users, and other objects accessible from the applications needs to be
organized in a clear and consistent manner. Much of this information can be
shared among many applications, but it must also be protected in order to prevent
unauthorized modification or the disclosure of private information.

Information describing the various users, applications, files, printers, and other
resources accessible from a network is often collected into a special database that
is sometimes called a directory. As the number of different networks and
applications has grown, the number of specialized directories of information has
also grown, resulting in islands of information that are difficult to share and
manage. If all of this information could be maintained and accessed in a consistent
and controlled manner, it would provide a focal point for integrating a distributed
environment into a consistent and seamless system.

The Lightweight Directory Access Protocol (LDAP) is an open industry standard

that has evolved to meet these needs. LDAP defines a standard method for
accessing and updating information in a directory. LDAP has gained wide
acceptance as the directory access method of the Internet and is therefore also
becoming strategic within corporate intranets. It is being supported by a growing
number of software vendors and is being incorporated into a growing number of
applications. For example, the two most popular Web browsers, Netscape
Navigator/Communicator and Microsoft Internet Explorer, as well as application
middleware, such as the IBM WebSphere Application Server or the IBM HTTP
server, support LDAP functionality as a base feature.

© 2019 IBM Corporation 34

Enterprise IAM Training Module

Directories
A directory is a listing of information about objects arranged in some order that
gives details about each object. Common examples are a city telephone
directory and a library card catalog. For a telephone directory, the objects listed
are people; the names are arranged alphabetically, and the details given about
each person are address and telephone number. Books in a library card catalog
are ordered by author or by title, and information such as the ISBN number of
the book and other publication information is given.

In computer terms, a directory is a specialized database, also called a data

repository, that stores typed and ordered information about objects. A particular
directory might list information about printers (the objects) consisting of typed
information such as location (a formatted character string), speed in pages per
minute (numeric), print streams supported (for example PostScript or ASCII),
and so on.

Directories allow users or applications to find resources that have the

characteristics needed for a particular task. For example, a directory of users can
be used to look up a person's e-mail address or fax number. A directory could be
searched to find a nearby PostScript color printer. Or a directory of application
servers could be searched to find a server that can access customer billing
information.

The terms white pages and yellow pages are sometimes used to describe how a
directory is used. If the name of an object (person, printer) is known, its
characteristics (phone number, pages per minute) can be retrieved. This is like
looking up a name in the white pages of a telephone directory. If the name of an
individual object is not known, the directory can be searched for a list of objects
that meet a certain requirement. This is like looking up a listing of hairdressers
in the yellow pages of a telephone directory. However, directories stored on a
computer are much more flexible than the yellow pages of a telephone directory
because they can usually be searched by specific criteria, not just by a
predefined set of categories.

 Directory versus Database

A directory is often described as a database, but it is a specialized database that

has characteristics that set it apart from general-purpose relational databases.
One special characteristic of directories is that they are accessed (read or
searched) much more often than they are updated (written). Hundreds of people

© 2019 IBM Corporation 35

Enterprise IAM Training Module

might look up an individual's phone number, or thousands of print clients might

look up the characteristics of a particular printer, but the phone number or
printer characteristics rarely change.
Because directories must be able to support high volumes of read requests, they
are typically optimized for read access. Write access might be limited to system
administrators or to the owner of each piece of information. A general-purpose
relational database, on the other hand, needs to support applications, such as
airline reservations and banking applications, with relatively high-update
volumes.

Because directories are meant to store relatively static information and are
optimized for that purpose, they are not appropriate for storing information that
changes rapidly. For example, the number of jobs currently in a print queue
probably should not be stored in the directory entry for a printer because that
information would have to be updated frequently to be accurate. Instead, the
directory entry for the printer can contain the network address of a print server.
The print server can be queried to get the current queue length if desired. The
information in the directory (the print server address) is static, whereas the
number of jobs in the print queue is dynamic.

Another difference between directories and general-purpose relational databases

is that most directory implementations still do not support transactions. However,
transactions are supported in LDAP and are limited to transactions within the
LDAP directory, and do not include other transactions (for example, database
operations). Transactions are all-or-nothing operations that must be completed in
total or not at all. For example, when transferring money from one bank account
to another, the money must be debited from one account and credited to the other
account in a single transaction. If only half of this transaction completes, or
someone accesses the accounts while the money is in transit, the accounts will
not balance. General-purpose relational databases usually support such
transactions, which complicates their implementation.
Because general-purpose relational databases must support arbitrary applications
such as banking and inventory control, they allow arbitrary collections of data to
be stored. Directories may be limited in the type of data they allow to be stored
(although the architecture does not impose such a limitation).

For example, a directory specialized for customer contact information might be

limited to storing only personal information such as names, addresses, and phone
numbers. If a directory is extensible, it can be configured to store a variety of
types of information making it more useful to a variety of programs.
Another important difference between a directory and a general-purpose
relational database is in the way information can be accessed. Most databases

© 2019 IBM Corporation 36

Enterprise IAM Training Module

support a standardized, very powerful access method called Structured Query

Language (SQL). SQL allows complex update and query functions at the cost of
program size and application complexity. Directories, such as an LDAP directory,
on the other hand, use a simplified and optimized access protocol that can be used
in slim and relatively simple applications.

Because directories are not intended to provide as many functions as general-

purpose relational databases, they can be optimized to economically provide
more applications with rapid access to directory data in large distributed
environments. If your intended use of the directory is to be read, mostly in a
non-transactional environment, both the directory client and directory server can
be simplified and optimized.

A request is typically performed by the directory client, and the process that
looks up information in the directory is called the directory server. In general,
servers provide a specific service to clients. Sometimes a server might become
the client of other servers in order to gather the information necessary to process
a request.

A directory service is only one type of service that might be available in a

client/server environment. Other common examples of services are file services,
mail services, print services, Web page services, and so on. The client and
server processes may or may not be on the same machine. A server is capable of
serving many clients. Some servers can process client requests in parallel. Other
servers queue incoming client requests for serial processing if they are currently
busy processing another client's request.

An API defines the programming interface a programming language uses to

access a service. The format and contents of the messages exchanged between
client and server must adhere to an agreed-upon protocol.

© 2019 IBM Corporation 37

Enterprise IAM Training Module

LDAP: Protocol or Directory

The Lightweight Directory Access Protocol (LDAP) defines a message protocol

used by directory clients and directory servers. The LDAP protocol uses
different messages. For example, a bindRequest may be sent from the client to
the LDAP server at the beginning of a connection. A searchRequest is used to
search for a specific entry in the directory.

There are also associated LDAP APIs for the C language and ways to access
LDAP from within a Java™ application. Additionally, within the Microsoft
development environment, you can access LDAP directories through its Active
Directory Service Interface (ADSI) In general with LDAP, the client is not
dependent upon a particular implementation of the server, and the server can
implement the directory however it chooses.

LDAP is an open industry standard that defines a standard method for accessing
and updating information in a directory. LDAP has gained wide acceptance as
the directory access method of the Internet and is therefore also becoming
strategic within corporate intranets. It is being supported by a growing number
of software vendors and is being incorporated into a growing number of
applications.

LDAP defines a communication protocol. That is, it defines the transport and
format of messages used by a client to access data in an X.500-like directory.
LDAP does not define the directory service itself. When people talk about the
LDAP directory, that is the information that is stored and can be retrieved by the
LDAP protocol.

All modern LDAP directory servers are based on LDAP Version 3. You can use
a Version 2 client with a Version 3 server. However, you cannot use a Version 3
client with a Version 2 server unless you bind as a Version 2 client and use only
Version 2 APIs.

All LDAP servers share many basic characteristics since they are based on the
industry standard Request for Comments (RFCs). However, due to
implementation differences, they are not all completely compatible with each
other when there is not a standard defined.

© 2019 IBM Corporation 38

Enterprise IAM Training Module

 Directory Clients and Servers

Directories are usually accessed using the client/server model of communication.

An application that wants to read or write information in a directory does not
access the directory directly. Instead, it calls a function or application
programming interface (API) that causes a message to be sent to another process.
This second process accesses the information in the directory on behalf of the
requesting application via TCP/IP. The default TCP/IP ports are 636 for secure
communications and 389 for unencrypted communications. The results of the
read or write action are then returned to the requesting application.

The request is performed by the directory client, and the process that maintains
and looks up information in the directory is called the directory server. In
general, servers provide a specific service to clients. Sometimes, a server might
become the client of other servers in order to gather the information necessary
to process a request.

The client and server processes may or may not be on the same machine. A server
is capable of serving many clients. Some servers can process client requests in
parallel. Other servers queue incoming client requests for serial processing if they
are currently busy processing another client’s request.

An API defines the programming interface that a particular programming

language uses to access a service. The format and contents of the messages
exchanged between client and server must adhere to an agreed-upon protocol.
LDAP defines a message protocol used by directory clients and directory servers.
There are also associated LDAP APIs for C and Java languages, and ways to
access the directory from a Java application using Java Naming and Directory
Interface (JNDI). The client is not dependent on a particular implementation of
the server, and the server can implement the directory however it chooses.

 Distributed Directories

The terms local, global, centralized, and distributed are often used to describe a
directory. These terms mean different things in different contexts. In this section,
we explain how these terms apply to directories.
In general, local means nearby, and global means that something is spread across
the universe of interest. The universe of interest might be a company, a country,
or the Earth. Local and global are two ends of a continuum. That is, something
may be more or less global or local than something else. Centralized means that
something is in one place, and distributed means that something is in more than

© 2019 IBM Corporation 39

Enterprise IAM Training Module

one place. As with local and global, something can be distributed to a greater or
lesser-extent.

The information stored in a directory can be simultaneously local and global in

scope. For example, a directory that stores local information might consist of the
names, e-mail addresses and so on of members of a department or workgroup. A
directory that stores global information might store information for an entire
company. Here, the universe of interest is the company.

The clients that access information in the directory can be local or remote. Local
clients may all be located in the same building or on the same LAN. Remote
clients might be distributed across the continent or planet. The directory itself can
be centralized or distributed. If a directory is centralized, there may be one
directory server at one location or a directory server that hosts data from
distributed systems. If the directory is distributed, there are multiple servers,
usually geographically dispersed, that provide access to the directory. When a
directory is distributed, the information stored in the directory can be partitioned
or replicated. When information is partitioned, each directory server stores a
unique and non-overlapping subset of the information. That is, each directory
entry is stored by one and only one server. One of the techniques to partition the
directory is to use LDAP referrals. LDAP referrals enable users to refer LDAP
requests to a different server. When information is replicated, the same directory
entry is stored by more than one server. In a distributed directory, some
information may be partitioned while some may be replicated.

The three dimensions of a directory (scope of information, location of clients, and

distribution of servers) are independent of each other. For example, clients
scattered across the globe can access a directory containing only information
about a single department, and that directory can be replicated at many directory
servers. Or, clients in a single location can access a directory containing
information about everybody in the world that is stored by a single directory
server.

The scope of information to be stored in a directory is often given as an

application requirement. The distribution of directory servers and the way in
which data is partitioned or replicated often can be controlled to affect the
performance and availability of the directory.

© 2019 IBM Corporation 40

Enterprise IAM Training Module

Advantages of using a Directory

An application specific directory stores only the information needed by a
particular application and is not accessible by other applications. Because a full-
function directory service is complex to build, application-specific directories are
typically very limited. They probably store only a specific type of information,
do not have general search capabilities, do not support replication and
partitioning, and probably do not have a full set of administration tools. An
application-specific directory could be as simple as a set of editable text files, or
it could be stored and accessed in an undocumented, proprietary manner.

In such an environment, each application creates and manages its own

application-specific directory, which quickly becomes an administrative
nightmare. The same e-mail address stored by the calendar application might also
be stored by a mail application and by an application that notifies system
operators of equipment problems. Keeping multiple copies of information up-to-
date and synchronized is difficult, especially when different user interfaces and
even different system administrators are involved.

What is needed is a common, application-independent directory. If application

developers could be assured of the existence of a directory service, then
application-specific directories would not be necessary. However, a common
directory must address the problems mentioned above. It must be based on an
open standard that is supported by many vendors on many platforms. It must be
accessible through a standard API. It must be extensible so that it can hold the
types of data needed by arbitrary applications, and it must provide full
functionality without requiring excessive resources on smaller systems. Since
more users and applications will access and depend on the common directory, it
must also be robust, secure, and scalable.

When such a directory infrastructure is in place, application developers can

devote their time to developing applications instead of application specific
directories. In the same way that developers rely on the communications
infrastructure of TCP/IP and remote procedure call (RPC) to free them from low-
level communication issues, they will be able to rely on powerful, full-function
directory services. LDAP is the protocol to be used to access this common
directory infrastructure. Like HTTP (hypertext transfer protocol) and FTP (file
transfer protocol), LDAP has become an indispensable part of the Internet's
protocol suite.

When applications access a standard common directory that is designed in a

proper way, rather than using application-specific directories, redundant and

© 2019 IBM Corporation 41

Enterprise IAM Training Module

costly administration can be eliminated, and security risks are more controllable.
For example, the telephone directory, mail, and Web application as shown in
figure can all access the same directory to retrieve an e-mail address or other
information stored in a single directory entry. The advantage is that the data is
kept and maintained in one place. Various applications can use individual
attributes of an entry for different purposes permitting that the they have the
correct authority. New uses for directory information will be realized, and a
synergy will develop as more applications take advantage of the common
directory.

LDAP History and Standards

In the 1970s, the integration of communications and computing technologies led
to the development of new communication technologies. Many of the
proprietary systems that were developed were incompatible with other systems.
It became apparent that standards were needed to allow equipment and systems
from different vendors to interoperate. Two independent major standardizations
efforts developed to define such standards.

© 2019 IBM Corporation 42

Enterprise IAM Training Module

 OSI and the Internet

One standards drive was led by the CCITT (International Consultative Committee
on Telephony and Telegraphy), and the ISO (International Standards
Organization). The CCITT has since become the ITU-T (International
Telecommunications Union - Telecommunication Standardization Sector). This
effort resulted in the OSI (Open Systems Interconnect) Reference Model (ISO
7498), which defined a seven-layer model of data communication with physical
transport at the lower layer and application protocols at the upper layers.

The other standards drive grew up around the Internet and developed from
research sponsored by DARPA (the Défense Advanced Research Projects
Agency) in the United States. The Internet Architecture Board (IAB) and its
subsidiary, the Internet Engineering Task Force (IETF), develop standards for the
Internet in the form of documents called Request for Comments (RFCs), which
after being approved, implemented, and used for a period of time, eventually
become standards (STDs). Before a proposal becomes an RFC, it is called an
Internet Draft.

The two standards process approach standardization from two different

perspectives. The OSI approach started from a clean slate and defined standards
using a formal committee process without requiring implementations. The
Internet uses a less formal engineering approach, where anybody can propose and
comment on RFCs, and implementations are required to verify feasibility.

The OSI protocols developed slowly, and because running the full protocol stack,
is resource intensive, they have not been widely deployed, especially in the
desktop and small computer market. In the meantime, TCP/IP and the Internet
were developing rapidly and being put into use. Also, some network vendors
developed proprietary network protocols and products.
 X.500 The Directory Server Standard

However, the OSI protocols did address issues important in large distributed
systems that were developing in an ad hoc manner in the desktop and Internet
marketplace. One such important area was directory services. The CCITT created
the X.500 standard in 1988, which became ISO 9594, Data Communications
Network Directory, Recommendations X.500-X.521 in 1990, though it is still
commonly referred to as X.500.
X.500 organizes directory entries in a hierarchal name space capable of
supporting large amounts of information. It also defines powerful search
capabilities to make retrieving information easier. Because of its functionality and

© 2019 IBM Corporation 43

Enterprise IAM Training Module

scalability, X.500 is often used together with add-on modules for interoperation
between incompatible directory services.

X.500 specifies that communication between the directory client and the directory
server uses the directory access protocol (DAP). However, as an application layer
protocol, the DAP requires the entire OSI protocol stack to operate. Supporting
the OSI protocol stack requires more resources than are available in many small
environments. Therefore, an interface to an X.500 directory server using a less
resource-intensive or lightweight protocol was desired.

 Lightweight Access to X.500

LDAP was developed as a lightweight alternative to DAP. LDAP requires the

lighter weight and more popular TCP/IP protocol stack rather than the OSI
protocol stack. LDAP also simplifies some X.500 operations and omits some
esoteric features.

Two precursors to LDAP appeared as RFCs issued by the IETF, Directory

Assistance Service (RFC 1202) and DIXIE Protocol Specification (RFC 1249).
These were both informational RFCs which were not proposed as standards.
The directory assistance service (DAS) defined a method by which a directory
client could communicate to a proxy on a OSI-capable host which issued X.500
requests on the client’s behalf. DIXIE is similar to DAS, but provides a more
direct translation of the DAP.

The first version of LDAP was defined in X.500 Lightweight Access Protocol
(RFC 1487), which was replaced by Lightweight Directory Access Protocol
(RFC 1777). LDAP further refines the ideas and protocols of DAS and DIXIE.
It is more implementation neutral and reduces the complexity of clients to
encourage the deployment of directory-enabled applications. Much of the work
on DIXIE and LDAP was carried out at the University of Michigan, which
provides reference implementations of LDAP and maintains LDAP-related Web
pages and mailing lists.

RFC 1777 defines the LDAP protocol itself. RFC 1777, along with:
 The String Representation of Standard Attribute Syntaxes (RFC 1778)
 A String Representation of Distinguished Names (RFC 1779)
 An LDAP URL Format (RFC 1959)
 A String Representation of LDAP Search Filters (RFC 1960)

© 2019 IBM Corporation 44

Enterprise IAM Training Module

Define the original LDAPv2 version of the language.

LDAP Version 2 has reached the status of draft standard in the IETF
standardization process, one step from being a standard. All of today’s directory
server implementations are based on the LDAPv3 specification.

LDAP Version 3 is defined by Lightweight Directory Access Protocol (v3)

(RFC 2251). Related RFCs that are new or updated for LDAP Version 3 are:
 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
(RFC 2252)
 Lightweight Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names (RFC 2253)
 The String Representation of LDAP Search Filters (RFC 2254)
 The LDAP URL Format (RFC 2255)
 A Summary of the X.500(96) User Schema for use with LDAPv3 (RFC
2256)
 Authentication Methods for LDAP (RFC 2829)
 LDAPv3: Extension for Transport Layer Security (RFC 2830)
 Lightweight Directory Access Protocol (v3): Technical Specification
(RFC 3377)

RFC 2251 is a proposed standard, one step below a draft standard. LDAP V3
extended LDAP V2 in the following areas:
 Referrals: A server that does not store the requested data can refer the
client to another server.
 Security: Extensible authentication using Simple Authentication and
Security Layer (SASL) mechanism.
 Internationalization: UTF-8 support for international characters.
 Extensibility: New object types and operations can be dynamically
defined, and schema published in a standard manner.

 Beyond LDAPv3

Recently, the push for encapsulating LDAP operations within XML for use
within Web Services has spawned a new language called the Directory Services
Markup Language (DSML). The most recent of the specification is
DSMLv2.DSML is an XML schema for representing directory information, it's a
generic import / export format for directory information. Directory information
in DSML can be shared between DSML-aware applications without
exposing the LDAP Protocol.

© 2019 IBM Corporation 45

Enterprise IAM Training Module

XML provides an effective way to present and transfer data; Directory services
allow you to share and manage data, and are thus a necessary prerequisite for
conducting online business; DSML is designed to make directory service more
dynamic by employing XML. DSML is an XML schema for working with
directories, it is defined using a Document Content Description (DCD). Thus,
DSML allows XML programmers to access LDAP-enabled directories without
having to write to the LDAP interface or use proprietary directory-access
APIs,and provides one consistent way to work with multiple dissimilar
directories.

Directory Components
A directory contains a collection of objects organized in a tree structure. The
LDAP naming model defines how entries are identified and organized. Entries
are organized in a tree-like structure called the Directory Information Tree (DIT).
Entries are arranged within the DIT based on their distinguished name (DN). A
DN is a unique name that unambiguously identifies a single entry. DNs are made
up of a sequence of relative distinguished names (RDNs). Each RDN™ in a DN
corresponds to a branch in the DIT leading from the root of the DIT to the
directory entry. A DN is composed of a sequence of RDNs separated by commas,
such as cn=thomas,ou=IT,o=company.

You can organize entries, for example, after organizations and within a single
organization you can further split the tree into organizational units, and so forth.
You can define your DIT based on your organizational needs as shown in
figure.

© 2019 IBM Corporation 46

Enterprise IAM Training Module

For example, one company with different divisions, you may want to start
with your company name under the root as the organization (o) and then
branch into organizational units (ou) for the individual divisions. In case
you store data for multiple organizations within a country, you may want
to start with a country (c) and then branch into organizations.

LDAP Standards

Several standards in the form of IETF RFCs exist for LDAP. The following is a
brief list of RFCs that apply for LDAP Version 2 and Version 3:

 RFC 1274 The COSINE and Internet X.500 Schema

 RFC 1777 Lightweight Directory Access Protocol (V2)
 RFC 1778 String Representation of Standard Attribute Syntaxes
 RFC 1779 String Representation of Distinguished Names
 RFC 1823 LDAP Application Program Interface (V2)
 RFC 2052 A DNS RR for Specifying the Location of Services (DNS
SRV)
 RFC 2219 Use of DNS Aliases for Network Services
 RFC 2222 Simple Authentication and Security Layer (SASL)

© 2019 IBM Corporation 47

Enterprise IAM Training Module

 RFC 2247 Using Domains in LDAP/X.500 Distinguished Names

 RFC 2251 Lightweight Directory Access Protocol (V3)
 RFC 2252 Lightweight Directory Access Protocol (V3): Attribute Syntax
Definitions
 RFC 2253 Lightweight Directory Access Protocol (V3): UTF-8 String
Representation of Distinguished Names
 RFC 2254 The String Representation of LDAP Search Filters
 RFC 2255 The LDAP URL Format
 RFC 2256 A Summary of the X.500(96) User Schema for use with
LDAPv3
 RFC 2596 Use of Language code in LDAP
 RFC 2696 LDAP Control Extension for Simple Paged Results
Manipulation
 RFC 2829 Authentication Methods for LDAP
 RFC 2849 The LDAP Data Interchange Format (LDIF) – Technical
Specification
 RFC 2891 LDAP Control Extension for Server-Side Sorting of Search
Results
 The Open Group schema for liPerson and liOrganization (NAC/LIPS)
 Oasis Directory Services Markup Language (DSML) 2.

Test Your Knowledge

1. What is LDAP?
2. What is difference between Database and Directory Server?

© 2019 IBM Corporation 48

Enterprise IAM Training Module

CHAPTER 4: LDAP Concepts & Architecture

Overview of LDAP Architecture

LDAP defines the content of messages exchanged between an LDAP client and
an LDAP server. The messages specify the operations requested by the client
(that is, search, modify, and delete), the responses from the server, and the
format of data carried in the messages. LDAP messages are carried over
TCP/IP, a connection-oriented protocol, so there are also operations to establish
and disconnect a session between the client and server.

However, for the designer of an LDAP directory, it is not so much the structure
of the messages being sent and received over the wire that is of interest. What is
important is the logical model that is defined by these messages and data types,
how the directory is organized, what operations are possible, how information is
protected, and so forth.

 The general interaction between an LDAP client and an LDAP server

takes the following form:
 The client establishes a session with an LDAP server. This is known as
binding to the server. The client specifies the host name or IP address and
TCP/IP port number where the LDAP serveries listening.
 The client can provide a user name and a password to properly
authenticate with the server, or the client can establish an anonymous
session with default access rights. The client and server can also establish
a session that uses stronger security methods such as encryption of data.
 The client then performs operations on directory data. LDAP offers both
read and update capabilities. This allows directory information to be
managed as well as queried. LDAP also supports searching the directory
for data meeting arbitrary user-specified criteria. Searching is a very
common operation in LDAP. A user can specify what part of the
directory to search and what information to return. A search filter that
uses Boolean conditions specifies what directory data matches the search.
 When the client is finished making requests, it closes the session with the
server. This is also known as unbinding.

The philosophy of the LDAP API is to keep simple things simple. This means
that adding directory support to existing applications can be done with low
overhead. Because LDAP was originally intended as a lightweight alternative to
DAP for accessing X.500 directories, it follows a X.500 model. The directory

© 2019 IBM Corporation 49

Enterprise IAM Training Module

stores and organizes data structures known as entries. A directory entry usually
describes an object such as a person, device, a location, and so on. Each entry
has a name called a distinguished name (DN) that uniquely identifies it. The DN
consists of a sequence of parts called relative distinguished names (RDNs),
much like a file name consists of a path of directory names in many operating
systems such as UNIX® and Windows. The entries can be arranged into a
hierarchical tree-like structure based on their distinguished names. This tree of
directory entries is called the Directory Information Tree (DIT).

Each entry contains one or more attributes that describe the entry. Each attribute
has a type and a value. For example, the directory entry for a person might have
an attribute called telephoneNumber. The syntax of the telephoneNumber
attribute would specify that a telephone number must be a string of numbers that
can contain spaces and hyphens. The value of the attribute would be the
person’s telephone number, such as 512-555-1212.

A directory entry describes some object. An object class is a general

description, sometimes called a template, of an object, as opposed to the
description of a particular object. For instance, the object class person has a
surname attribute, whereas the object describing John Smith has a surname
attribute with the value Smith. The object classes that a directory server can
store and the attributes they contain are described by schema. Schema define
what object classes are allowed where in the directory, what attributes they must
contain, what attributes are optional, and the syntax of each attribute. For
example, a schema could define a person object class. The person schema might
require that a person have a surname attribute that is a character string, specify
that a person entry can optionally have a telephoneNumber attribute that is a
string of numbers with spaces and hyphens, and so on.

LDAP defines operations for accessing and modifying directory entries such as:
 Binding and unbinding
 Searching for entries meeting user-specified criteria
 Adding an entry
 Deleting an entry
 Modifying an entry
 Modifying the distinguished name or relative distinguished name of an
entry (move)
 Comparing an entry

© 2019 IBM Corporation 50

Enterprise IAM Training Module

The Informational Model

The basic unit of information stored in the directory is called an entry. Entries
represent objects of interest in the real world such as people, servers,
organizations, and so on. Entries are composed of a collection of attributes that
contain information about the object. Every attribute has a type and one or more
values. The type of the attribute is associated with a syntax. The syntax specifies
what kind of values can be stored. For example, an entry might have a attribute.
The syntax associated with this type of attribute would specify that the values are
telephone numbers represented as printable strings optionally followed by
keywords describing paper size and resolution characteristics. It is possible that
the directory entry for an organization would contain multiple values in this
attribute—that is, that an organization or person represented by the entity would
have multiple fax numbers. The relationship between a directory entry and its
attributes and their values is shown in Figure 2-1.

In addition to defining what data can be stored as the value of an attribute, an

attribute syntax also defines how those values behave during searches and other
directory operations. The attribute telephoneNumber, for example, has a syntax
that specifies:
 Lexicographic ordering.
 Case, spaces and dashes are ignored during the comparisons.
 Values must be character strings.

For example, using the correct definitions, the telephone numbers 512-838-
6008, 512838-6008, and 5128386008 are considered the same. A few of the
syntaxes that have been defined for LDAP are listed in Table 2-1.

© 2019 IBM Corporation 51

Enterprise IAM Training Module

Table 2-2 lists some common attributes. Some attributes have alias names that
can be used wherever the full attribute name is used. For example, cn can be
used when referring to the attribute commonName.

Constraints can be associated with attribute types to limit the number of values
that can be stored in the attribute or to limit the total size of a value. For
example, an attribute that contains a photo could be limited to a size of 10 KB to
prevent the use of unreasonable amounts of storage space. Or an attribute used
to store a social security number could be limited to holding a single value.

© 2019 IBM Corporation 52

Enterprise IAM Training Module

Schemas define the type of objects that can be stored in the directory. Schemas
also list the attributes of each object type and whether these attributes are
required or optional. For example, in the person schema, the attribute surname
(sn) is required, but the attribute description is optional. Schema-checking
ensures that all required attributes for an entry are present before an entry is
stored. Schema-checking also ensures that attributes not in the schema are not
stored in the entry. Optional attributes can be filled in at any time. Schema also
define the inheritance and subclassing of objects and where in the DIT structure
(hierarchy) objects may appear.

Table 2-3 lists a few of the common schema (object classes and their required
attributes). In many cases, an entry can consist of more than one object class.

Though each server can define its own schema, for interoperability it is expected
that many common schema will be standardized (refer to RFC 2252, Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions, and RFC 2256, A
Summary of the X.500(96) User Schema for use with LDAPv3).

There are times when new schema will be needed at a particular server or within
an organization. In LDAP Version 3, a server is required to return information
about itself, including the schema that it uses. A program can therefore query a
server to determine the contents of the schema. This server information is stored
at the special zero-length DN. Objects can be derived from other objects. This is
known as sub classing. For example, suppose an object called person was defined
that included an attribute surname and so on. An object class organizational
Person could be defined as a subclass of the person object class. The
organizationPerson object class would have the same attributes as the person
object class and could add other attributes such as title and officenumber. The
person object class would be called the superior of the organizationPerson object
class. One special object class, called top, has no superiors. The top object class
includes the mandatory objectClass attribute. Attributes in top appear in all
directory entries as specified (required or optional).

© 2019 IBM Corporation 53

Enterprise IAM Training Module

Each directory entry has a special attribute called objectClass. The value of the
objectClass attribute is a list of two or more schema names. These schema define
what type of object(s) the entry represents. One of the values must be either top
or alias. Alias is used if the entry is an alias for another entry, otherwise top is
used. The objectClass attribute determines what attributes the entry must and may
have.

The special object class extensibleObject allows any attribute to be stored in the
entry. This can be more convenient than defining a new object class to add a
special attribute to a few entries, but also opens up that object to be able to contain
anything (which might not be a good thing in a structured system).

 LDIF
When an LDAP directory is loaded for the first time or when many entries have
to be changed at once, it is not very convenient to change every single entry on
a one-by-one basis. For this purpose, LDAP supports the LDAP Data
Interchange Format (LDIF) that can be seen as a convenient, yet necessary, data
management mechanism. It enables easy manipulation of mass amounts of data.
See Example 2-1 for the basic form of an LDIF entry.

Example 2-1 Basic form of an LDIF entry

dn: <distinguished name>
<attrtype> : <attrvalue>
<attrtype> : <attrvalue>
...

A line can be continued by starting the next line with a single space or tab
character, for example:
dn: cn=John E Doe, o=University of Higher
Learning, c=US

Multiple attribute values are specified on separate lines, for example:

cn: John E Doe
cn: John Doe

If an attribute value contains a non-US-ASCII character, or begins with a space

or a colon (:), the attribute type is followed by a double colon and the value is
encoded in base-64 notation. For example, the value "begins with a space"
would be encoded like this:
cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=

© 2019 IBM Corporation 54

Enterprise IAM Training Module

Multiple entries within the same LDIF file are separated by a blank line.
Multiple blank lines are considered a logical end-of-file.

Example 2-2 shows a simple LDIF file which contains an organizational unit,
People, located beneath the organization ibm.com in the DIT. The entry of John
Smith is the only data entry for People. Further on, there is an organizational unit
called marketing. Note that John Smith is a member of the marketing department
due to the attribute value pair ou: marketing.

Example 2-2 Example LDIF File with organizational and person entries
dn: o=ibm.com
objectclass: top
objectclass: organization
o: ibm.com
dn: ou=People, o=ibm.com
objectclass: organizationalUnit
ou: people
dn: ou=marketing, o=ibm.com
objectclass: organizationalUnit
ou: marketing
dn: cn=John Smith, ou=people, o=ibm.com
objectclass: top
objectclass: organizationalPerson
cn: John Smith
sn: Smith
givenname: John
uid: jsmith
ou: marketing
ou: people
telephonenumber: 838-6004

 LDAP Schema

In this section we discuss LDAP schema.

Objectclasses
An object class is an LDAP term that denotes the type of object being represented
by a directory entry or record. Some typical object types are person, organization,
organizational unit, domain component and groupOfNames. There are also object
classes that define an object's relationship to other objects, such as object class
top denotes that the object may have subordinate objects under it in a hierarchical
tree structure. Note that some LDAP object classes may be combined, for

© 2019 IBM Corporation 55

Enterprise IAM Training Module

example, an object class of organizational unit will most often also be

simultaneously defined as a top object class because it will have entries beneath
it.

An object class is declared as abstract, structural, or auxiliary. An abstract object

class is used as a template for creating other object classes. A directory entry
cannot be instantiated from an abstract object class. Directory entries are
instantiated from structural object classes. An auxiliary object class cannot be
instantiated by itself as a directory entry; it can be attached to directory entries
that are instantiated from structural object classes. Auxiliary object classes
provide a method for extending structural object classes without having to change
the schema definition of a structural class.
LDAP object classes defined sets of standard attributes that are listed as must
contain (mandatory attributes) and may contain (optional attributes). Different
object classes may prescribe some attributes that overlap, or are redundant with
other object classes. And it is common practice in LDAP directories to use
multiple object classes to define a single directory entry. Most object classes are
defined in a hierarchical order, where one object class is said to "inherit" from
another superior object class. Consider an LDAP object that is defined with the
object classes, as shown in Example 2-3.

Example 2-3 LDAP object definition

objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: eDominoAccount

The order shown for the object classes above indicates a hierarchical relationship
between these object classes, but not necessarily. The top objectclass is of course
at the top of the hierarchy. Most other objectclasses that are not intended to be
subordinate to another class should have top as its superior. Not all LDAP
directories expect a user record to have the top object class assigned to it, while
others require it for using Access Control Lists (ACLs) on the object. The person
class is subordinate to the top class and requires that the cn (Common Name) and
sn (Surname) attributes be populated and allows several other optional attributes.
The organizationalPerson class inherits from the person class. The inetOrgPerson
class inherits from the organizationalPerson class. Now here is the tricky part:
The eDominoAccount object class is subordinate to the top class and requires that
the sn and userid attributes be populated. Notice that this overlaps with the person
object class requirement for the sn attribute. Does this mean that we need to store
the sn attribute twice? No, because it is a standard attribute. We will talk more

© 2019 IBM Corporation 56

Enterprise IAM Training Module

about attributes a little later in this section. It illustrates that you cannot
necessarily tell the hierarchical relationship of object classes by the order they
appear in a list. So then, how do we tell? We tell (or in reality, your
LDAPdirectory interface shows you) by looking at the object class definitions
themselves. The methods for defining object classes for LDAP V3 are described
in RFC-2251 and RFC-2252. Example 2-4 shows object class definitions taken
from ITDS.

Example 2-4 Some ITDS object class definitions

objectclass: top
objectclasses=( 2.5.6.0 NAME 'top' DESC 'Standard ObjectClass' ABSTRACT
MUST (
objectClass ) )
objectclass: person
objectclasses=( 2.5.6.6 NAME 'person' DESC 'Defines entries that generically
represent people.' SUP 'top' STRUCTURAL MUST ( cn $ sn ) MAY (
userPassword $
telephoneNumber $ seeAlso $ description ) )
objectclass: organizationalPerson
objectclasses=( 2.5.6.7 NAME 'organizationalPerson' DESC 'Defines entries for
people employed by or associated with an organization.' SUP 'person'
STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
internationalISDNNumber $ facsimileTelephoneNumber $ street $
postalAddress $
postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ ou $ st $ l ) )
objectclass: inetOrgPerson
objectclasses=( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'Defines
entries representing people in an organizations enterprise network.' SUP
'organizationalPerson' STRUCTURAL MAY ( audio $ businessCategory $
carLicense $
departmentNumber $ employeeNumber $ employeeType $ givenName $
homePhone $
homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $
mobile
$ pager $ photo $ preferredLanguage $ roomNumber $ secretary $ uid $
userCertificate $ userSMIMECertificate $ x500UniqueIdentifier $ displayName
$o
$ userPKCS12 ) )

© 2019 IBM Corporation 57

Enterprise IAM Training Module

Note that each object class begins with a string of numbers delimited by
decimals. This number is referred to as the OID (object identifier). After the
OID is the object class name (NAME) followed by a description (DESC). If it is
subordinate to another object class, the superior (SUP) object class is listed.
Finally, the object class definition specifies what attributes are mandatory
(MUST) and which are optional (MAY).

The OID is a numeric string that is used to uniquely identify an object. OIDs are
a managed hierarchy administered by the International Organization for
Standardization (ISO - Web site http://www.iso.ch/) and the International
Telecommunication Union (ITU - Web site http://www.itu.ch/). ISO and ITU
delegate OID management to organizations by assigning them OID numbers.
Organizations can then assign OIDs to objects or further delegate to other
organizations. OIDs are associated with objects in protocols and data structures
defined using Abstract Syntax Notation (ASN.1).

OIDs are intended to be globally unique. They are formed by taking a unique
numeric string (for example, 1.3.4.7.4.17) and adding additional digits in a unique
fashion (such as 1.3.4.7.4.17.1, 1.3.4.7.4.17.2, 1.3.4.7.4.17.3, etc.) An
organization may acquire a "branch" from some root or vertex in the OID tree.
Such a branch is more commonly referred to as an arc (in the previous example
it was 1.3.4.7.4.17). The organization may then extend the arc (called subarcs) as
shown above to create additional OIDs and arcs. We have no idea why the
terminology for the OID tree uses the words "vertex" and "arc" instead of "root"
and "branch" as is more commonly used in LDAP and its X.500 heritage. If you
have an LDAP directory that is a derivative of the original University of Michigan
LDAP code (many open source and commercial LDAP directory servers are),
your object class definitions are contained in files ending with ".oc".

As you may have guessed, the "dot notation" as first used by the IETF for IP
addresses was adopted to OIDs to keep things simple. However, unlike IP
addresses, there is no limit to the length of an OID.

If your organization must define your own attributes for use within your internal
directories, you should consider obtaining your own private enterprise number
arc to identify these attributes. We do not recommend that you "make up" your
own numbers, as you will probably not be able to interoperate with other
organizations (or some vendor's LDAP products). This is not to say obtaining
your own OID arc from ISO, IANA or some other authority to define your own
object classes and attributes will guarantee interoperability. But it will prevent
you rom using OIDs that have already been assigned to or by someone else. OIDs
are only used for "equality-matching". That is, two objects (for example, directory

© 2019 IBM Corporation 58

Enterprise IAM Training Module

attributes or certificate policies) are considered to be the same if they have exactly
the same OID. There are no implied navigational or hierarchical capabilities with
OIDs (unlike IP addresses, for example); given an OID one can not readily find
out who owns the OID, related OIDs, etc. OIDs exist to provide a unique
identifier. There is nothing to stop two organizations from picking thesame
identical names for objects that they manage, however, the OIDs will be unique
assuming they were assigned from legitimate arc numbers.

Let us look at the following example: Top is an abstract class that contains the
objectClass attribute. Person is a structural class that instantiates the directory
entry for a given person where the objectClass attribute is also part of that
Person entry. So far, this example has used only attributes and object classes
defined in a standard. So, now, you may want to tailor the people entries to
include information that your company requires and that is not defined in the
standard Person object definition. There are two ways to do this:
 Subclass the Person object to create a new structural class that includes
those additional attributes defined by your company and instantiate the
Person directory entry based on that new class.
 Define that collection of company attributes needed for your company’s
Person definition as an auxiliary class and attach it to the directory entry
instantiated from the Person class.
Either method is recommended. The downside to auxiliary classes is that
if the auxiliary class includes an attribute that is also included in the
structural class definition, when that attribute is included in the
instantiated directory entry and that attribute contains multiple values and
you want to delete the attribute, you cannot tell whether the attribute
(when added to the entry) was added when the structural class was
instantiated or when the auxiliary class was instantiated. This may be
important to the implementor or administrator.

Special entries exist in the namespace, called aliases. Aliases represent links to
other entries or partitions of the namespace. When the distinguished name of an
alias is used, the entry accessed is the entry to which the alias refers (unless
specified otherwise through the programming interface). The collection of
directory entries forms the Directory Information Tree (DIT). The method of
storage for the DIT of the LDAP directory is implementation-dependent and
hidden from the user of that LDAP directory. For example, the ITDS uses IBM
DB2 as its data store, but no DB2 constructs are externalized to LDAP.

© 2019 IBM Corporation 59

Enterprise IAM Training Module

Attributes
All the object class does is define the attributes, or types of data items contained
in that type of object. Some examples of typical attributes are cn (common
name), sn (surname), givenName, mail, uid, and userPassword. Just as the
object classes are defined with unique OIDs, each attribute also has a unique
OID number assigned to it. LDAP V3 attributes follow a notation similar
(ASN.1) to object classes. Example 2-6 shows some attribute definitions.

Example 2-6 Attribute definitions

attribute: name
attributetypes=(2.5.4.41 NAME 'name' DESC 'The name attribute type is the
attribute supertype from which string attribute types typically used for naming
may be formed. It is unlikely that values of this type itself will occur in an
entry.' EQUALITY 1.3.6.1.4.1.1466.109.114.2 SUBSTR 2.5.13.4 SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications)

attribute: sn
attributetypes=(2.5.4.4 NAME ('sn' 'surName') DESC 'This is the X.500
surname attribute, which contains the family name of a person.' SUP 2.5.4.41
EQUALITY 2.5.13.2 ORDERING 2.5.13.3 SUBSTR 2.5.13.4 USAGE
userApplications)

attribute: mail
attributetypes=(0.9.2342.19200300.100.1.3 NAME ('mail' 'rfc822mailbox')
DESC 'Identifies a users primary email address (the email address retrieved and
displayed by white-pages lookup applications).' EQUALITY 2.5.13.2 SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplication)

Notice in Example 2-6 on page 41 that the superior (SUP) of sn is the attribute
2.5.4.41, which happens to be the name attribute. But then the name attribute
description says unlikely that values of this type itself will occur....
This illustrates just one of the many peculiarities of the way the attributes have
been defined. It merely provides a shorthand way to defining name-like attributes
such as surname. We did not need to define the syntax for sn because it inherits
this from name.
The attribute mail also has an alias of rfc822mailbox. As you may have guessed,
the "EQUALITY" and "SYNTAX" are yet more ASN.1 definitions.

© 2019 IBM Corporation 60

Enterprise IAM Training Module

THE NAMING MODEL

The LDAP naming model defines how entries are identified and organized.
Entries are organized in a tree-like structure called the Directory Information
Tree (DIT). Entries are arranged within the DIT based on their distinguished
name (DN). A DN is a unique name that unambiguously identifies a single
entry. DNs are made up of a sequence of relative distinguished names (RDNs).

Each RDN in a DN corresponds to a branch in the DIT leading from the root of
the DIT to the directory entry. Each RDN is derived from the attributes of the
directory entry. In the simple and common case, an RDN has the form
<attribute name> = <value>. A DN is composed of a sequence of RDNs
separated by commas.

An example of a DIT is shown in below figure.

The example is very simple but can be used to illustrate some basic concepts.
Each box represents a directory entry. The root directory entry is conceptual but
does not actually exist.

The organization of the entries in the DIT is restricted by their corresponding

object class definitions. Entries are named according to their position in the
DIT. The directory entry at the bottom of the figure has the DN of cn=John
Smith,ou=people,o=ibm,c=us. The organizational group people has the DN of
ou=people,o=ibm,c=us.

© 2019 IBM Corporation 61

Enterprise IAM Training Module

 LDAP Distinguished Name Syntax (DNS)

Entries in an LDAP directory are identified by their names. The characteristics

of these names are:
 They have two forms: A string representation and a URL.
 They have a uniform syntax.
 Namespace boundaries are not apparent in them.
A component of a name is called a relative distinguished name (RDN). An RDN
represents a point within the namespace hierarchy. RDNs are separated by and
concatenated using a comma (,). Each RDN is typed. RDNs have the form
type=value for single valued RDNs. The plus sign (+) is used to form multi-
valued RDNs: type=value+type=value.

The type is case-insensitive and the value is defined to have a particular syntax.
The order of RDNs in an LDAP name is the most specific RDN first followed by
the less specific RDNs moving up the DIT hierarchy. A concatenated series of
RDNs equates to a distinguished name. The DN is used to represent an object and
the path to the object in the hierarchical namespace. A URL format for LDAP has
been defined that includes a DN as a component of the URL. These forms are
explained in the sections that follow.

Every entry in the directory has a DN. The DN is the name that uniquely
identifies an entry in the directory. A DN is made up of attribute=value pairs,
separated by commas, for example:
cn=Roger Smith,ou=sales,o=ib,c=US
cn=Sandy Brown,ou=marketing,o=ibm,c=US
cn=Leslie Jones,ou=development,o=ibm,c=US

Any of the attributes defined in the directory schema may be used to make up a
DN. The order of the component attribute value pairs is important. The DN
contains one component for each level of the directory hierarchy from the root
down to the level where the entry resides. LDAP DNs begin with the most
specific attribute (usually some sort of name), and continue with progressively
broader attributes, often ending with a country attribute. The first component of
the DN is referred to as the Relative Distinguished Name (RDN). It identifies an
entry distinctly from any other entries that have the same parent. In the examples
above, the RDN cn=Roger Smith separates the first entry from the second entry,
(with RDN cn=Sandy Brown). These two example DNs are otherwise equivalent.
The attribute:value pair making up the RDN for an entry must also be present in
the entry. (This is not true of the other components of the DN.)

© 2019 IBM Corporation 62

Enterprise IAM Training Module

The Distinguished Name (DN) syntax supported by this server is based on RFC
2253. The Backus-Naur Form (BNF) syntax is shown in Example.

Example DN syntax
<name> ::= <name-component> ( <spaced-separator> )
| <name-component> <spaced-separator> <name>
<spaced-separator> ::= <optional-space>
<separator>
<optional-space>
<separator> ::= "," | ";"
<optional-space> ::= ( <CR> ) *( " " )
<name-component> ::= <attribute>
| <attribute> <optional-space> "+"
<optional-space> <name-component>
<attribute> ::= <string>
| <key> <optional-space> "=" <optional-space> <string>
<key> ::= 1*( <keychar> ) | "OID." <oid> | "oid." <oid>
<keychar> ::= letters, numbers, and space
<oid> ::= <digitstring> | <digitstring> "." <oid>
<digitstring> ::= 1*<digit>
<digit> ::= digits 0-9
<string> ::= *( <stringchar> | <pair> )
| '"' *( <stringchar> | <special> | <pair> ) '"'
| "#" <hex>
<special> ::= "," | "=" | <CR> | "+" | "<" | ">"
| "#" | ";"
<pair> ::= "\" ( <special> | "\" | '"')
<stringchar> ::= any character except <special> or "\" or '"'
<hex> ::= 2*<hexchar>

© 2019 IBM Corporation 63

Enterprise IAM Training Module

<hexchar> ::= 0-9, a-f, A-F

A semicolon (;) character can be used to separate RDNs in a distinguished

name, although the comma (,) character is the typical notation.
White-space characters (spaces) might be present on either side of the comma or
semicolon. The white-space characters are ignored, and the semicolon is
replaced with a comma.

In addition, space (' ' ASCII 32) characters may be present either before or after
a '+' or '='. These space characters are ignored when parsing.

A value may be surrounded by double quotation ('"' ACSII 34) characters,

which are not part of the value. Inside the quoted value, the following characters
can occur without being interpreted as escape characters:

A space or "#" character occurring at the beginning of the string A space

character occurring at the end of the string One of the characters "'", "=", "+",
"\", "<", ">", or ";" Alternatively, a single character to be escaped may be
prefixed by a backslash ('\' ASCII 92). This method can be used to escape any of
the characters listed previously and the double quotation marks ('"' ASCII 34)
character.

This notation is designed to be convenient for common forms of names. The

following example is a distinguished name written using this notation. First is a
name containing three components. The first of the components is a multi valued
RDN. A multivalued RDN contains more than one attribute:value pair and can be
used to distinctly identify a specific entry in cases where a simple CN value might
be ambiguous:

OU=Sales+CN=J. Smith,O=Widget Inc.,C=US

 String Form

The exact syntax for names is defined in RFC 2253. Rather than duplicating the
RFC text, the following are examples of valid distinguished names written in
string form:

cn=Leslie Smith, ou=Austin, o=IBM

This is a name containing three relative distinguished names (RDNs).
ou=deptUVZS + cn=Leslie Smith, ou=Austin, o=IBM

© 2019 IBM Corporation 64

Enterprise IAM Training Module

This a name containing three RDNs in which the first RDN is multi-valued.
cn=L. Eagle, o=Sue\, Grabbit and Runn, c=GB
This example shows the method of quoting a comma (using a backslash as the
escape character) in an organization name.
cn=Before\0DAfter,o=Test,c=GB
This is an example name in which a value contains a carriage return character
(0DH).
sn=Lu\C4\8Di\C4\87
This last example represents an RDN surname value consisting of five letters
(including non-standard ASCII characters) that is written in printable ASCII
characters. The below table explains the quoted character codes.

 URL Form

The LDAP URL format has the general form ldap://<host>:<port>/<path>, where
<path> has the form <dn>[?<attributes>[?<scope>?<filter>]]. The <dn> is an
LDAP distinguished name using a string representation. The <attributes> indicate
which attributes should be returned from the entry or entries. If omitted, all
attributes are returned. The <scope> specifies the scope of the search to be
performed. Scopes may be current entry, one-level (current entry’s children), or
the whole subtree. The <filter> specifies the search filter to apply to entries within
the specified scope during the search. The URL format allows Internet clients, for
example, Web browsers, to have direct access to the LDAP protocol and thus
LDAP directories.

Examples of LDAP URLs are:

© 2019 IBM Corporation 65

Enterprise IAM Training Module

 ldap://austin.ibm.com/ou=Austin,o=IBM

This URL corresponds to a base object search of the <ou=Austin, o=IBM>

entry using a filter <of objectClass=*> requesting all attributes (if a filter is
omitted, a filter of <objectClass=*> is assumed by definition).
ldap://austin.ibm.com/o=IBM?postalAddress
This is an LDAP URL referring to only the postalAddress attribute of the IBM
entry.

 ldap:///ou=Austin,o=IBM??sub?(cn=Joe Q. Public)

This is an LDAP URL referring to the set of entries found by querying any
capable LDAP server (no hostname was given) and doing a subtree search of the
IBM Austin subtree for any entry with a common name of Joe Q. Public retrieving
all attributes. The LDAP URL format is defined in RFC 2255.

Functional Model
The LDAP functional model is comprised of three categories of operations that
can be performed against a LDAPv3 directory service:
 Authentication: Bind, Unbind, and Abandon operations used to connect
and disconnect to and from an LDAP server, establish access rights and
protect information.
 Query: Search for and Compare entries for entries meeting user-specified
criteria.
 Update: Add an entry, Delete an entry, Modify an entry, and modify the
distinguished name (ModifyRDN) or relative distinguished name of an
entry.

 Query

The most common operation is search. The search operation is very flexible and
has some of the most complex options.

The search operation allows a client to request that an LDAP server search
through some portion of the DIT for information meeting user-specified criteria
in order to read and list the result(s). There are no separate operations for read
and list; they are incorporated in the search function. The search can be very
general or very specific. The search operation allows one to specify the starting
point within the DIT, how deep within the DIT to search, what attributes an entry

© 2019 IBM Corporation 66

Enterprise IAM Training Module

must have to be considered a match, and what attributes to return for matched
entries.

Some example searches expressed informally in English are:

 Find the postal address for cn=John Smith,o=IBM,c=DE.

 Find all the entries that are children of the entry ou=ITSO,o=IBM,c=US.
 Find the e-mail address and phone number of anyone in IBM whose last
name contains the characters “miller” and who also has a fax number.

To perform a search, the following parameters must be specified:

 Base A DN that defines the starting point, called the base object, of the
search. The base object is a node within the DIT.

 Scope Specifies how deep within the DIT to search from the base object.
There are three choices: base Object, single Level, and whole Subtree. If
base Object is specified, only the base object is examined. If single Level
is specified, only the immediate children of the base object are examined;
the base object itself is not examined. If whole Subtree is specified, the
base object and all its descendants are examined.

 Search Filter Specifies the criteria an entry must match to be returned

from a search. The search filter is a Boolean combination of attribute value
assertions. An attribute value assertion tests the value of an attribute for
equality, less than or equal to, and so on. For example, a search filter might
specify entries with a common name containing “wolf” or belonging to
the organization ITSO.

 Attributes to Return Specifies which attributes to retrieve from entries

that match the search criteria. Since an entry may have many attributes, this
allows the user to only see the attributes they are interested in. Normally,
the user is interested in the value of the attributes. However, it is possible
to return only the attribute types and not their values. This could be useful
if a large value like a JPEG photograph was not needed for every entry
returned from the search, but some of the photographs would be retrieved
later as needed.

 Alias Dereferencing Specifies if aliases are dereferenced—that is, if the

alias entry itself or the entry it points to is used. Aliases can be
dereferenced or not when locating the base object and/or when searching

© 2019 IBM Corporation 67

Enterprise IAM Training Module

under the base object. If aliases are dereferenced, then they are alternate
names for objects of interest in the directory. Not dereferencing aliases
allows the alias entries themselves to be examined.

 Limits Searches can be very general, examining large subtrees and causing
many entries to be returned. The user can specify time and size limits to
prevent wayward searching from consuming too many resources. The size
limit restricts the number of entries returned from the search. The time limit
limits the total time of the search. Servers are free to impose stricter limits
than requested by the client.

 Referrals and Continuation References

If the server does not contain the base object, it will return a referral to a server
that does, if possible. Once the base object is found singleLevel and wholeSubtree
searches may encounter other referrals. These referrals are returned in the search
result along with other matching entries. These referrals are called continuation
references because they indicate where a search could be continued. For example,
when searching a subtree for anybody named Smith, a continuation reference to
another server might be returned, possibly along with everal other matching
entries. It is not guaranteed that an entry for somebody named Smith actually
exists at that server, only that the continuation reference points to a subtree that
could contain such an entry. It is up to the client to follow continuation references
if desired. Since only LDAP Version 3 specifies referrals, continuation references
are not supported in earlier versions.

 Search Filter Syntax

The search filter defines criteria that an entry must match to be returned from a
search. The basic component of a search filter is an attribute value assertion of
the form: attribute operator value For example, to search for a person named
John Smith the search filter would be cn=John Smith. In this case, cn is the
attribute, = is the operator, and John Smith is the value. This search filter
matches entries with the common name John Smith. The below table shows the
search filter options.

© 2019 IBM Corporation 68

Enterprise IAM Training Module

The * character matches any substring and can be used with the = operator. For
example, cn=J*Smi* would match John Smith and Jan Smitty.

Search filters can be combined with Boolean operators to form more complex
search filters. The syntax for combining search filters is: ( "&" or "|" (filter1)
(filter2) (filter3) ...) ("!" (filter)) The Boolean operators are listed in below table

For example, (|(sn=Smith)(sn=Miller)) matches entries with the surname Smith

or the surname Miller. The Boolean operators can also be nested as in
(|(sn=Smith) (&(ou=Austin)(sn=Miller))), which matches any entry with the
surname Smith or with the surname Miller that also has the organizational unit
attribute Austin.

© 2019 IBM Corporation 69

Enterprise IAM Training Module

 Compare

The compare operation compares an entry for an attribute value. If the entry has
that value, compare returns TRUE. Otherwise, compare returns FALSE.
Although compare is simpler than a search, it is almost the same as a base scope
search with a search filter of attribute=value. The difference is that if the entry
does not have the attribute at all (the attribute is not present), the search will return
not found. This is indistinguishable from the case where the entry itself does not
exist. On the other hand, compare will return FALSE. This indicates that the entry
does exist, but does not have an attribute matching the value specified.

 Update Operations

Update operations modify the contents of the directory. The below table
summarizes the update operations.

Operation Description
Add Inserts new entries into the directory.
delete Deletes existing entries from the
directory. Only leaf nodes can be
deleted. Aliases are not resolved
when deleting.
modify Changes the attributes and values
contained within an existing entry.
Allows new attributes to be added
and existing attributes to be deleted
or modified.
modify DN Changes the least significant (left
most) component of a DN or moves a
subtree of entries to a new location in
the DIT. Entries cannot be moved
across server boundaries.

 Authentication Operations

Authentication operations are used to establish and end a session between an

LDAP client and an LDAP server. The session may be secured at various levels
ranging from an insecure anonymous session, an authenticated session in which
the client identifies itself by providing a password, to a secure, encrypted session
using SASL mechanisms. SASL was added in LDAP Version 3 to overcome the

© 2019 IBM Corporation 70

Enterprise IAM Training Module

weak authentication in LDAP Version 2. The below table summarizes the

authentication operations.

 Controls and extended operations

Controls and extended operations allow the LDAP protocol to be extended

without changing the protocol itself. Controls modify the behavior of an
operation, and extended operations add new operations to the LDAP protocol.
The list of controls and extensions supported by an LDAP server can be obtained
by examining the root DSE of that server. Controls can be defined to extend any
operation.

Controls are added to the end of the operation’s protocol message. They are
supplied as parameters to functions in the API.
A control has a dotted decimal string object ID used to identify the control, an
arbitrary control value that holds parameters for the control, and a criticality level.
If the criticality level is TRUE, the server must honor the control; or if the server
does not support the control, reject the entire operation. If the criticality level is
FALSE, a server that does not support the control must perform the operation as
if there was no control specified. For example, a control might extend the delete
operation by causing an audit record of the deletion to be logged to a file specified
by the control value information.

An extended operation allows an entirely new operation to be defined. The

extended operation protocol message consists of a dotted decimal string object
ID used to identify the extended operation and an arbitrary string of operation-
specific data.

© 2019 IBM Corporation 71

Enterprise IAM Training Module

Security model

The security model is based on the bind operation. There are several different
bind operations possible, and thus the security mechanism applied is different as
well. One possibility is when a client requesting access supplies a DN identifying
itself along with a simple clear-text password. If no DN and password is declared,
an anonymous session is assumed by the LDAP server. The use of clear text
passwords is strongly discouraged when the underlying transport service cannot
guarantee confidentiality and may therefore result in disclosure of the password
to unauthorized parties.

LDAP V3 comes along with a bind command supporting the Simple

Authentication and Security Layer (SASL) mechanism. This is a general
authentication framework, where several different authentication methods are
available for authenticating the client to the server; one of them is Kerberos.

Furthermore, extended protocol operations are available in LDAP V3. An

extension related to security is the Extension for Transport Layer Security (TLS)
for LDAPv3. This allow operations too use TLS as a means to encrypt an LDAP
session and protect against spoofing. TLS has a mechanism which enables it to
communicate to an SSL server so that it is backwards compatible. The basic
principles of SSL and TLS are the same.

Directory security
Security is of great importance in the networked world of computers, and this is
true for LDAP as well. When sending data over insecure networks, internally or
externally, sensitive information may need to be protected during transportation.
There is also a need to know who is requesting the information and who is sending
it. This is especially important when it comes to the update operations on a
directory. The term security, as used in the context of this book, generally covers
the following four aspects:

 Authentication: Assurance that the opposite party (machine or person)

really is who he/she/it claims to be.
 Integrity: Assurance that the information that arrives is really the same as
what was sent.
 Confidentiality: Protection of information disclosure by means of data
encryption to those who are not intended to receive it.

© 2019 IBM Corporation 72

Enterprise IAM Training Module

 Authorization: Assurance that a party is really allowed to do what

he/she/it is requesting to do. This is basically achieved by assigning
access controls, like read, write, or delete, to user IDs or common names.

The following sections focus on the first three aspects (since authorization is not
yet contained in the LDAP Version 3 standard): Authentication, integrity and
confidentiality. There are several methods that can be used for this purpose; the
most important ones are discussed here. These are:

 No authentication.
 Basic authentication.
 Simple Authentication and Security Layer (SASL). This includes
DIGEST-MD5. When a client uses Digest-MD5, the password is not
transmitted in clear text and the protocol prevents replay attacks.

 No authentication

This is the simplest authentication method, one that obviously does not need to
be explained in much detail. This method should only be used when data security
is not an issue and when no special access control permissions are involved. This
could be the case, for example, when your directory is an address book browsable
by anybody. No authentication is assumed when you leave the password and DN
fields empty in an ldap operation. The LDAP server then automatically assumes
an anonymous user session and grants access with the appropriate access controls
defined for this kind of access (not to be confused with the SASL anonymous
user).

 Basic authentication

The security mechanism in LDAP is negotiated when the connection between the
client and the server is established. This is the approach specified in the LDAP
application program interface (API). Besides the option of using no
authentication at all, the most simple security mechanism in LDAP is called basic
authentication, which is also used in several other Web-related protocols, such as
in HTTP. When using basic authentication with LDAP, the client identifies itself
to the server by means of a DN and a password which are sent in the clear over
the network (some implementations may use Base64 encoding instead). The
server considers the client authenticated if the DN and password sent by the client
match the password for that DN stored in the directory. Base64 encoding is
defined in the Multipurpose Internet Mail Extensions (MIME) LDAP standard

© 2019 IBM Corporation 73

Enterprise IAM Training Module

(RFC 1521). It is a relatively simple encryption, and therefore it is not hard to

break once one has captured the data on the network.

 SASL

SASL is a framework for adding additional authentication mechanisms to

connection-oriented protocols. It has been added to LDAP Version 3 to overcome
the authentication shortcomings of Version 2. SASL was originally devised to
add stronger authentication to the IMAP protocol. SASL has since evolved into a
more general system for mediating between protocols and authentication systems.
It is a proposed Internet standard defined in RFC 2222.

In SASL, connection protocols, like LDAP, IMAP, and so on, are represented by
profiles; each profile is considered a protocol extension that allows the protocol
and SASL to work together. A complete list of SASL profiles can be obtained
from the Information Sciences Institute (ISI). Each protocol that intends to use
SASL needs to be extended with a command to identify an authentication
mechanism and to carry out an authentication exchange. Optionally, a security
layer can be negotiated to encrypt the data after authentication and so ensure
confidentiality. LDAP Version 3 includes a command (ldap_sasl_bind()) to
encrypt the data after authentication.
 SSL and TLS
The Secure Socket Layer (SSL) protocol was devised to provide both
authentication and data security. It encapsulates the TCP/IP socket so that
basically every TCP/IP application can use it to secure its communication.
SSL/TLS supports server authentication (client authenticates server), client
authentication (server authenticates client), or mutual authentication. In addition,
it provides for privacy by encrypting data sent over the network.

SSL/TLS uses a public key method to secure the communication and to

authenticate the counterparts of the session. This is achieved with a public/private
key pair. They operate as reverse functions to each other, which means data
encrypted with the private key can be decrypted with the public key and vice
versa. The assumption for the following considerations is that the server has its
key pair already generated. This is usually done when setting up the LDAP server.

The simplified interchange between a client and a server negotiating an SSL/TLS

connection is explained in the following steps:

© 2019 IBM Corporation 74

Enterprise IAM Training Module

 As a first step, the client asks the server for an SSL/TLS session.
The client also includes the SSL/TLS options it supports in the
request.
 The server sends back its SSL/TLS options and a certificate
which includes, among other things, the server’s public key, the
identity for whom the certificate was issued (as a distinguished
name), the certifier’s name and the validity time. A certificate can
be thought of as the electronic equivalent of a passport. It has to
be issued by a general, trusted Certificate Authority (CA) which
vouches that the public key really belongs to the entity mentioned
in the certificate. The certificate is signed by the certifier which
can be verified with the certifier’s freely available public key.
 The client then requests the server to prove its identity. This is to
make sure that the certificate was not sent by someone else who
intercepted it on a former occasion.
 The server sends back a message including a message digest
(similar to a check sum) which is encrypted with its private key.
A message digest that is computed from the message content
using a hash function has two features. It is extremely difficult to
reverse, and it is nearly impossible to find a message that would
produce the same digest. The client can decrypt the digest with
the server’s public key and then compare it with the digest it
computes from the message. If both are equal, the server’s
identity is proved, and the authentication process is finished.
 Next, server and client have to agree upon a secret (symmetric)
key used for data encryption. Data encryption is done with a
symmetric key algorithm because it is more efficient than the
computing-intensive public key method. The client therefore
generates a symmetric key, encrypts it with the server’s public
key, and sends it to the server. Only the server with its private
key can decrypt the secret key.
 The server decrypts the secret key and sends back a test message
encrypted with the secret key to prove that the key has safely
arrived. They can now start communicating using the symmetric
key to encrypt the data.

As outlined above, SSL/TLS is used to authenticate a server to a

client using its certificate and its private key and to negotiate a
secret key later on used for data encryption.

© 2019 IBM Corporation 75

Enterprise IAM Training Module

Test Your knowledge

1. What is LDIF?
2. What is Directory Information Tree?

© 2019 IBM Corporation 76

Enterprise IAM Training Module

CHAPTER 5: LDAP Replication

Replication is a technique used by directory servers to improve performance,

availability, and reliability. The replication process keeps the data in multiple
directory servers synchronized. You can know more about replication benefits
through the information provided here.

Replication provides three main benefits:

 Redundancy of information - Replicas back up the content of their

supplier servers.
 Faster searches - Search requests can be spread among several different
servers, instead of a single server. This improves the response time for the
request completion.
 Security and content filtering - Replicas can contain subsets of the data in
a supplier server.

The following sections are examples of setting up replication using either the
Web Administration Tool or the command line utilities, and an LDIF file. The
scenarios are of increasing complexity:

 One master and one replica

 One master, one forwarder, and one replica
 Two peer/masters, two forwarders, and four replicas.
 Gateway replication.

Overview of Replication
This section presents a high-level description of the various types of replication
topologies.

 Simple replication: The basic relationship in replication is that of a master

server and its replica server. The master server can contain a directory or a
subtree of a directory. You can use the information and example provided
here to know more about it.

 Cascading replication: Cascading replication is a topology that has

multiple tiers of servers. You can use the information and example
provided here to know more about it.

© 2019 IBM Corporation 77

Enterprise IAM Training Module

 Peer-to-peer replication: There can be several servers acting as masters

for directory information, with each master responsible for updating other
master servers and replica servers. This is referred to as peer replication.
You can use the information and example provided here to know more
about it.

 Gateway replication: Gateway replication is a more complex adaptation

of peer-to-peer replication that extends replication capabilities across
networks. You can use the information and example provided here to know
more about it.

 Simple Replication
The basic relationship in replication is that of a master server and its replica
server. The master server can contain a directory or a subtree of a directory. You
can use the information and example provided here to know more about it.

The master is writable, which means it can receive updates from clients for a
given subtree. The replica server contains a copy of the directory or a copy of part
of the directory of the master server. The replica is read only; it cannot be directly
updated by clients. Instead it refers client requests to the master server, which
performs the updates and then replicates them to the replica server.

A master server can have several replicas. Each replica can contain a copy of the
master's entire directory, or a subtree of the directory. In the following example
Replica 2 contains a copy of the complete directory of the Master Server, Replica
1 and Replica 3 each contain a copy of a subtree of the Master Server's directory.

Master-replica replication

The relationship between two servers can also be described in terms of roles,
either supplier or consumer. In the previous example the Master Server is a

© 2019 IBM Corporation 78

Enterprise IAM Training Module

supplier to each of the replicas. Each replica in turn is a consumer of the Master
Server.

 Cascading Replication
Cascading replication is a topology that has multiple tiers of servers. You can use
the information and example provided here to know more about it.

A master server replicates to a set of read-only (forwarding) servers that in turn

replicate to other servers. Such a topology off-loads replication work from the
master server. In the example of this type of topology, the master server is a
supplier to the two forwarding servers. The forwarding servers serve two roles.
They are consumers of the master server and suppliers to the replica servers
associated with them. The replica servers are consumers of their respective
forwarding servers. For example:

Cascading replication

 Peer-to-Peer Replication

There can be several servers acting as masters for directory information, with
each master responsible for updating other master servers and replica servers.

This is referred to as peer replication. You can use the information and example
provided here to know more about it.
Peer replication can improve performance, availability, and reliability.
Performance is improved by providing a local server to handle updates in a widely
distributed network. Availability and reliability are improved by providing a
backup master server ready to take over immediately if the primary master fails.

© 2019 IBM Corporation 79

Enterprise IAM Training Module

Peer master servers replicate all client updates to the replicas and to the other peer
masters, but do not replicate updates received from other master servers.

In a Peer-to-peer replication setup with one replica server for each peer-master,
if the primary master fails, the proxy server directs the requests to the backup
master server. However, the proxy server will not fall back to the primary
master until the backup master server fails.
The following figure shows an example of peer-to-peer replication:

Peer-to-peer Replication

 Gateway Replication

Gateway replication is a more complex adaptation of peer-to-peer replication that

extends replication capabilities across networks. You can use the information and
example provided here to know more about it.

The most notable difference is that a gateway server does replicate changes
received from other peer servers through the gateway.

A gateway server must be a master server, that is, writable. It acts as a peer server
within its own replication site. That is, it can receive and replicate client updates
and receive updates from the other peer-master servers within the replication site.
It does not replicate the updates received from the other peer-masters to any
servers within its own site.

Within the gateway network, the gateway server acts as a two-way forwarding
server. In one instance, the peers in its replication site act as the suppliers to the
gateway server and the other gateway servers are its consumers. In the other
instance the situation is reversed. The other gateway servers act as suppliers to
the gateway server and the other servers within its own replication site are the
consumers.

© 2019 IBM Corporation 80

Enterprise IAM Training Module

Gateway replication uses gateway servers to collect and distribute replication

information effectively across a replicating network. The primary benefit of
gateway replication is the reduction of network traffic. For example:

Gateway replication

Test your Knowledge

1. What is master to master replication?

© 2019 IBM Corporation 81

Enterprise IAM Training Module

UNIT 3: Single Sign-On (SSO) Concepts

© 2019 IBM Corporation 82

Enterprise IAM Training Module

CHAPTER 6: Single Sign-On Techniques

Introduction

In present digital world, users have to access multiple systems for carrying out
their day-to-day business activities. As the number of systems increase, the
number of credentials for each user increases and thereby possibility of losing or
forgetting them also increases.

Single sign-on (SSO) is a centralized access control technique that allows a

subject to be authenticated only once on a system and to access multiple resources
without authenticating again. It can be used to solve many problems related to
multiple credentials for different applications. Single Sign on access to the main
authentication centre enables users to get access to all other resources available.
SSO helps to improve user and developer productivity by avoiding the user to
remember multiple passwords and also reduce the amount of time the user spends
on typing various passwords to login. SSO also simplifies the administration by
managing single credentials instead of multiple credentials. It makes easy to
manage the rights of a user arriving, changing function in or leaving the company,
to quickly integrate added applications, delegate access rights during holidays
without increasing the helpdesk's workload.
Figure shows the context diagram. This diagram provides a simple overview of
what a SSO protocol could look like. This protocol defines multiple users that use
computers, tablets, mobile phones etc. (which we call clients). These users want
access to a service which can be data, an application, or a part of an application.
Using SSO the client retrieves a proof of identity and access, which is used to
access the services.

© 2019 IBM Corporation 83

Enterprise IAM Training Module

Types of Single Sign-On

The various types of SSO shown in Figure, fall under different categories, based
on: -
- where they are deployed (Intranet, Extranet, Internet);
- how they are deployed (architecture – Simple, Complex);
- the credentials they use (token, certificate.) and the protocols they use
(Kerberos, SAML, OpenID.)

© 2019 IBM Corporation 84

Enterprise IAM Training Module

Following picture shows the types of SSO and their classification: -

 Where they are Deployed:

i. Intranet or Enterprise SSO (ESSO)

Enterprise Single sign on (ESSO) allows connecting to multiple systems within

the same enterprise. ESSO is designed to minimize the number of times that a
user must type their ID and password to sign into multiple applications. It
automatically logs users in and acts as a password filler where automatic login is
not possible. Each desktop/laptop is given a token that handles the authentication.
ii. Extranet or Multi-Domain SSO
Multi-Domain SSO allows connecting to multiple systems within the same
enterprise and all the business partners applications. The user can login into one
enterprise and access resources of the other , the users need not login again using
different credentials.

iii. Internet of Web-SSO

Web SSO is a browser-based mechanism , providing access with single login to
applications deployed on web servers.

© 2019 IBM Corporation 85

Enterprise IAM Training Module

Enterprise SSO vs Web SSO

Enterprise SSO is designed to provide Single Sign-On to almost all the
applications a user needs, including, Windows executables, Java applications,
terminal-emulator applications and in some cases web applications.
Typically, enterprise SSO is implemented as a desktop client that manages user
credentials on behalf of a single user . It captures the user-ID and password for
the application when the user logs in. The next time the application is launched,
the solution will detect this and automatically enter the credentials on the user?s
behalf . It can also be programmed to handle password changes for example,
password expiration.

For Enterprise SSO, an executable is installed on the user’s desktop and profiles
are created to recognize the login/password change screens so that the agent can
respond to them. An example of such an SSO solution is a password manager that
automatically logs a user in when a certain website is visited. Since no changes
have to be made to the applications, setting up this kind of SSO is in most cases
a relatively easy way to provide SSO .

Web SSO focuses on web-based applications . An authorization server is used to

determine who can have access to which service. An IdP will authenticate the
user and checks the access rules in the AS to see if the request should be passed
on to the web server. This provides a more integrated approach, as access control
is added in addition to SSO. This SSO type is useful when many web applications
are involved. In Web SSO, the user has only one password to authenticate. Once
the user has a session with the Web SSO product, they can access multiple sites
without having to authenticate again.

3.6.2.2 How they are Deployed:

SSO architectures are divided based on their deployment as Simple SSO or
Complex SSO as follows:

3.6.2.2.1 Simple SSO Architecture

Simple SSO makes use of single authentication authority, single set of credentials
for each user. This architecture could be easily implemented in homogenous LAN
and intranet environment.

© 2019 IBM Corporation 86

Enterprise IAM Training Module

3.6.2.2.2 Complex SSO Architecture

Complex SSO uses multiple authentication authorities with single or multiple sets
of crdentials for each user.

3.6.2.3 Types of Credentials Used:

Complex SSO can further be classified as two basic schemes, Complex SSO with
a single set of credentials and Complex SSO with multiple sets of credentials.
A.) Complex SSO with a single set of credentials:
Complex SSO using single set of credentials can be accomplished in two ways
i.e. Token-based and Public Key-based as follows:

 Token-based SSO system:

In this SSO system, a user submits the credentials to the token-based
authentication authority, in which the credentials have been checked with its
credential database. If the user credentials match, then the user is returned with a
token. When the user wants to access an application server which is governed
by second authentication authority, the same token is delivered to get a ticket to
access the application server. Success of this process relies on the trust the
authentication authorities have among themselves.

 Token-based SSO in HTTP environment:

The Token-based SSO could be implemented by using cookies in HTTP
environment. A cookie is a set of information given to the web browser by the
web server and is stored in the client machine. Cookies used for authentication
can be encrypted to keep them secret. The server could then retrieve the cookie
and provide customized service to the client. Kerberos system provides basis for
constructing secure SSO in network environment, however, it needs client-side
infrastructure and configuration. In HTTP-enabled environment, cookies could
be used to construct SSO system and no extra installation or configuration is
necessary. The biggest difference between Kerberos system and Cookies-enabled
SSO system is that the former uses Remote Procedure Calls to transport
authentication tickets, while the latter uses cookies to play the role of tokens.

© 2019 IBM Corporation 87

Enterprise IAM Training Module

 PKI-based SSO system:

In PKI based SSO, the servers/resources and users authenticate each other by
using their respective key pairs. Users can authenticate the servers by challenging
the servers to decrypt any message they send which is encrypted by the public
key of the server. Same way, servers can authenticate the user by challenging him
to decrypt the message they send which is encrypted by the
public key of the user. As the real owner of the private key only can decrypt, the
mutual authentication i.e. server authenticating the user and vice-versa happens.

B.) Complex SSO with multiple set of credentials:

 Credential Synchronization:
The multiple sets of credentials needed to access multiple systems are masked by
a single set of credentials to give an illusion that users need to remember only the
single set. The synchronization software relieves the user from changing the
credentials in all systems as and when the policy forces, by automatically
forwarding the change request to all concerned authentication servers. eg: Pass
Go.

 Client-side credential caching:

It allows users to store sensitive credentials like log on information (ex: user IDs
and passwords) required for the websites or resources they access in a network.
These credentials are stored in special folder called vaults. With this stored
information, user’s system can automatically log on securely to the websites and
the computers on their network automatically without requiring them to
remember the credentials all the time. Vaults can store all sorts of credentials like
passwords, certificates, tokens etc. (eg: Windows Credential Manager).

 Server-side credential caching:

The Server-Side Credential Caching mechanism is same as Client-side Credential
Caching architecture, with only difference being the credentials stored in a server
instead of the client. It uses a central server to take on the task of administering
all the different passwords and providing the needed information directly to the
application asking for them. Eg: (CA Etrust SSO)

© 2019 IBM Corporation 88

Enterprise IAM Training Module

Single sign-on Protocols

In this section we will discuss different protocols that are used on simple and
complex SSO architectures.

Kerberos authentication Protocol

Kerberos is a classical implementation of Token-based distributed authentication
protocol. The whole process is divided into three parts among four entities. The
four entities are :-
1) Client – the one who want to access resources
2) Authentication Server (AS) – the one who can authenticate the clients
and resources
3) Ticket Granting Server (TGS) – the one who gives tickets to access resources
4) Application Server (S) – a resource to whom the access is requested.

The three processes are :-

1)Authentication Request and Response: in which the client using its
credentials gets authenticated with AS and gets a key to securely communicate
with TGS
2) Ticket Granting Request and Response: in which the client using the
previously secured key from AS, requests TGS to get a ticket to access S and
3) Application Request and Response: in which the client uses the ticket it got
from TGS to securely communicate with S. The first process where the
credentials are required is completed by client only once and there after the 2nd
and 3rd processes keep repeated as and when the client has to access other
resources.

Security Assertion Markup Language

Security Assertion Markup Language (SAML) is an XML-based open standard

for exchanging authentication and authorization data between security domains,
i.e., an identity provider and a service provider. Using SAML, an online service
provider contacts an online identity provider which authenticates users who are
trying to access secure content. SAML doesn’t specify how to authenticate a
user; rather it defines a way how to exchange the authentication and authorization
data once the user is authenticated. SAML is nothing more than a series of XML-

© 2019 IBM Corporation 89

Enterprise IAM Training Module

based messages called Assertions that detail whether users are authenticated
(Authentication Assertion), what kind of rights, roles and access
(Attribute Assertion) they have and how they can use data and resources
(Authorisation Assertion) based on those rights and roles. It uses HTTP, SMTP,
FTP and SOAP, among other protocols and technologies to transmit these
assertions.

OpenID
Open ID is a decentralized authentication protocol. It consists of three main
entities:-
1) The OpenID Identifier: A String of text or an e-mail address that uniquely
identifies the user;
2) The OpenID Relying Party (RP): A Web application or service provider that
wants proof that the end user owns the said Identifier
3) The OpenID Provider (OP): A central server that issues, stores and manages
the OpenID identifiers of users. Relying Parties rely on this provider for an
assertion that the end user owns the said Identifier.

There are mainly four methods used in OpenID Protocol:-

1. Discovery:
End user initiates authentication by presenting a User-Supplied Identifier to the
Relying Party via their browser. RP performs discovery (Discovery) on it and
establishes the OP Endpoint URL which is used by user for authentication.
2. Authentication:
RP redirects the end user's browser to the OP with an OpenID Authentication
request. OP establishes whether the end user is authorized. OP redirects the end
user's browser back to the RP with either an assertion that authentication is
approved or a message that authentication failed.
3. Association:
RP and OP establish an association with a shared secret established using Diffie-
Hellman Key Exchange. OP uses this association to sign subsequent messages
and RP to verify those messages; this removes the need for subsequent direct
requests to verify the signature after each authentication
request/response.
4. Verification:
RP verifies the information received from OP including checking the Return
URL, verifying the discovered information, checking the nonce, and verifying the
signature by using either the shared key established during the association or by
sending a direct request to the OP.

© 2019 IBM Corporation 90

Enterprise IAM Training Module

BrowserID
BrowserID is a decentralized identity system through which users can prove the
claim of their email addresses allowing user’s login into any website on the
Internet using single password. It avoids site-specific usernames and passwords,
an alternative for ad-hoc application level authentication. It implements Verified
Email Protocol built by Mozilla, which offers streamlined experience.

BrowserID consists of three main concepts:

Primary Identity Authorities (Primary): A Service which provides the user
with an identity in the form of an email address. It is an email provider like
Yahoo! mail or gmail, builds BrowserID support.
Relying Parties (RPs): Sites that use BrowserID for authentication.
The Implementation Provider (IP): This is the user's web browser with
native support for BrowserID, or else browserid.org serves web resources that
implement the client portion of the system. It implements key management,
required algorithms and serves as a Secondary Identity Authority.

BrowserID can be implemented by the following 3 steps:

1. Certificate Provisioning: Certificate Provisioning is the process in which a
Primary verifies the user’s email addresses and issues a signed certificate that
proves user’s ownership of that email
2. Assertion Generation: Assertion Generation is the process in which a user's
browser produces an assertion that proves that a user owns given emails
address.
3. Assertion Verification: Assertion Verification is the process in which a
Relying Party can verify that an assertion of a user's ownership of a certain
email is valid.

OAuth2
Some sources say that OAuth2 is not an SSO protocol, as it does not provide
authentication. One can disagree with this statement, however, as OAuth2
handles authorization and authentication is required for authorization. Since the
access token can be used by all services, authentication to these services can be
automated because an access token implies that the user is authenticated. The
main difference between an ID token and an access token is that an access token
should only contain access information and does not contain any identifying
information .

© 2019 IBM Corporation 91

Enterprise IAM Training Module

In OAuth2, authorization is delegated over several entities. A client asks for the
AS a message, saying, in effect, "this client has access to this source". The client
gives this message to server S, which trusts the AS and will grant access. So the
AS can deliver temporary access tokens to the client without giving the client too
much power.

This system can be thought of as a hotel. The Hotel has a key master (OAuth2
server) named AS. He gives all cleaners (clients) keys that open the door of the
rooms they have to clean. They can only open the doors assigned to them and no
others. All of these keys self-destruct after a few hours, after which time the
cleaners cannot open any door.

LDAP
The Lightweight Directory Access Protocol (LDAP) is a protocol for accessing
distributed directory services, which can be used for authentication and
authorization . LDAP is often used in combination with an active directory.
LDAP is based on DAP which is a protocol defined by the X.500 computer
network standards. The two lightweight protocols for desktop computers were
called: Directory Assistance Service (DAS) and Directory Interface to X.500
Implemented Efficiently (DIXIE).

The LDAP protocol consist of LDAP clients and an LDAP server. The clients
create an LDAP message that contains a certain request and sends it to the server.
The server processes this request and sends the results back to the client as one
or more LDAP messages.
For example, when an LDAP client searches for a specific entry, then it sends an
LDAP search request message to the server. Each message contains a unique
message-ID generated by the client. The server receives a message from its
directory and sends it to the client followed by a separate message that contains
the result code. All of the communication between the server and the client is
identified by the message-ID provided in the request of the client.

We can divide its functionality into three categories:

• Interrogation operations: search, compare.
These two operations allow you to ask questions to the directory server.
• Update operations: add, delete, modify, modify DN (rename).
These operations allow you to update information in the directory.
• Authentication and control operations: bind, unbind, abandon.
The bind operation allows a client to identify itself to the directory by providing
identity and authentication credentials; the unbind operation allows the client to

© 2019 IBM Corporation 92

Enterprise IAM Training Module

terminate a session; and the abandon operation allows a client to indicate that it
is no longer interested in the results of an operation it had previously submitted.

CAS
Central Authentication Server (CAS) 1.0 was developed by Yale University as
an easy-touse Single Sign-On solution for the web. It consisted of servlets and
web pages. The goal was to make CAS a flexible and extendible protocol able
to meet the varying requirements of other institutions.
CAS is an authentication SSO solution, as its name, "Central Authentication
Server", already suggests. CAS is an open protocol that consists of a Java server
component that communicates with clients written in:
• Java
• .Net
• PHP
• Perl
• Apache
• uPortal

The CAS protocol consist of two parts: the CAS server and the CAS Client.
CAS server: A CAS server is a single machine used for authentication.
CAS clients: A CAS client is any service provider that is CAS-enabled and can
communicate with the server.

Implementing SSO requires the following worth noting security considerations:

1. As one single authentication controls access to all resources, it is important

that the authentication process is secure enough to protect those resources. This
protection should satisfy the requirements of the most critical application. The
single authentication process should not be weaker than the original
authentication method used by the various applications, otherwise, the result is a
downgrade in security level.

2. A second factor of authentication, such as a security token and smart card,

can be used to strengthen the authentication process.

3. Relevant password restrictions, such as the minimum password length, the

password complexity, the maximum number of trial attempts and the minimum
time for renewal, and so on, should be imposed.

© 2019 IBM Corporation 93

Enterprise IAM Training Module

4. As the authentication server may become an attractive target for attack, it

should be well protected so that intruders cannot access authentication
information which could then be used for unauthorised access to all the systems.

5. Auditing and logging functions should be used to facilitate the detection and
tracing of suspicious unsuccessful login attempts.

6. Encryption should be used to protect against authentication credentials

transmitted across the network.

© 2019 IBM Corporation 94

Enterprise IAM Training Module

CHAPTER 7: Access Control

Most identity and access management (IAM) products provide a variety of

methods for implementing the policies to control access to organizational
resources, with varying terminology being used to describe these methods.
However, all forms of access control can ultimately be mapped back to one of
four classic models:
• Discretionary Access Control (DAC)
• Mandatory Access Control (MAC)
• Role-based Access Control (RBAC)
• Attribute-based Access Control (ABAC).

Discretionary Access Control (DAC)

The data owner places discretionary access controls on data. The owner
determines who has access to the data and what privileges they have. DACs are
widely used to allow users manage their own data and the security of that
information

Mandatory Access Control (MAC)

Mandatory access controls are based on organization policy and determined by
the system. MAC requires the system itself to manage access controls in
accordance with the organization’s governance. Typically, MACs are used for
highly sensitive systems. MAC is based on interaction between the system and
the information owner. The system decides and controls the access and the owner
provides the need-to-know control. Only those who have a need to know and who
clear the system’s access control will be provided the information.

Access permissions apply to an object based on the level of authority given to a

subject. Access capabilities and access permissions can be as mentioned in Table
1 and Table 2. Users can be assigned to different groups, and access capabilities
can be assigned to these groups differently. When combining these two tables and
adding users to it we get access control list (ACL).

© 2019 IBM Corporation 95

Enterprise IAM Training Module

TABLE 1. Access capabilities

No access No access permission

Read (R) Permission to read but not to make any changes
Write (W) Permission to write to file, includes also the
capability to change.
Execute (X) Permission to execute a program
Delete (D) Permission to delete a file
Change (C) Permission to read, write, execute and delete a file
but not to change file permission.

List (L) List the files in a directory

Full Control (FC) All abilities, including changing access control
permissions

TABLE 2. Access permissions

Public R- L
Group R- X
Owner R-W-X-D
Admins FC
System FC

Mandatory access control was developed for the US Army. Creating a complete
deployment using MAC in practice has turned out to be tricky. However, MAC
is a significant theoretical model for access control

Role Based Access Control (RBAC)

A role-based access control RBAC is based on the roles or functions the user is
assigned within the organization. Access control decisions are based on work
roles and organizational roles. Each role has its own access capabilities. There are
no restrictions how many roles can be assigned to a user, or which permissions
can be assigned to a role. This is described in below Figure.

© 2019 IBM Corporation 96

Enterprise IAM Training Module

Objects associated with a role inherit privileges assigned to that role. As seen in
below Figure, there are many approaches to RBAC.

© 2019 IBM Corporation 97

Enterprise IAM Training Module

A non-RBAC means granting access to an application by traditional mapping,

using e.g. ACLs. There are no roles used. A limited RBAC means that users are
mapped to system roles but there is no organization-wide role structure. Users
can also be mapped to applications that do not have a role-based access at all. In
a hybrid RBAC there are organization-wide roles used, but it does not exclude
the use of applications that use system roles. A full RBAC means that information
systems and applications are controlled by roles that have been defined by the
organization’s governance and policies. There are no users mapped to single
applications. Possible system roles are defined according to the organizational
roles.

IAM systems support the RBAC model. To develop the maturity level of the
organization, role mining to target systems is needed to find out the system roles
and their suitability to the organizational and work role structure.

Attribute-based access control (ABAC)

An attribute-based access control (ABAC) is an extension of RBAC. ABAC was
developed due to the vast amount of effort for engineering roles in the RBAC
model. With ABAC the access control can be based on any attribute of user,
service, operation or system. The attribute can also be a name of a role. However,
in that case it is not possible for the ABAC to contain roles and their permissions.
With ABAC the engineering roles is not needed if role names are not used as
attributes. Changing attributes e.g. the time of day and organization unit
dynamically gives more room for variety. It can also make things more difficult
with too many options. To provide an access control, labelled objects and user
attributes are used in ABAC instead of permissions.

With ABAC auditing becomes a laborious task. Instead of only reviewing users
and their roles, the auditor has to enumerate user’s attributes and then the
corresponding attributes of the available protected objects. Also because the
attributes can change dynamically, it requires rules with all possible attribute
values while the user is active.

a)Benefits of RBAC

There are several benefits to using RBAC to restrict unnecessary network access
based on people's roles within an organization, including:

 Improving operational efficiency. With RBAC, companies can decrease

the need for paperwork and password changes when they hire new
employees or switch the roles of existing employees. RBAC lets

© 2019 IBM Corporation 98

Enterprise IAM Training Module

organizations quickly add and change roles, as well as implement them

across platforms, operating systems (OSes) and applications. It also cuts
down on the potential for error when user permissions are being assigned.
Additionally, with RBAC, companies can more easily integrate third-party
users into their networks by giving them predefined roles.
 Enhancing compliance. Every organization must comply with local, state
and federal regulations. Companies generally prefer to implement RBAC
systems to meet the regulatory and statutory requirements for
confidentiality and privacy because executives and IT departments can
more effectively manage how the data is accessed and used. This is
particularly important for financial institutions and healthcare companies
that manage sensitive data.
 Giving administrators increased visibility. RBAC gives network
administrators and managers more visibility and oversight into the
business, while also guaranteeing that authorized users and guests on the
system are only given access to what they need to do their jobs.
 Reducing costs. By not allowing user access to certain processes and
applications, companies may conserve or more cost-effectively use
resources, such as network bandwidth, memory and storage.
 Decreasing risk of breaches and data leakage. Implementing RBAC
means restricting access to sensitive information, thus reducing the
potential for data breaches or data leakage.

 RBAC Framework model components

1. Core RBAC
 introduces the concept of role activation as part of a user’s
session within a computer system.
 required in any RBAC system, but the other components
are independent of each other and may be implemented
separately.

2. Hierarchical RBAC

 relations for supporting role hierarchies (inheritance

among roles)

3. Static Separation of Duty Relations

• adds exclusivity relations among roles with respect to user
assignments

© 2019 IBM Corporation 99

Enterprise IAM Training Module

• potential for inconsistencies with respect to static

separation of duty relations and inheritance relations of a
role hierarchy
• defines relations in both the presence and absence of role
hierarchies.
4. Dynamic Separation of Duty Relations

 Dynamic separation of duty (DSD) relations, like SSD

relations, limit the permissions that are available to a
user. However, DSD relations differ from SSD relations
by the context in which these limitations are imposed.

 DSD requirements limit the availability of the

permissions by placing constraints on the roles that can
be activated within or across a user’s sessions.

 Role Based Access Control

 Many-to-many relationship among individual users and privileges

© 2019 IBM Corporation 100

Enterprise IAM Training Module

 Session is a mapping between a user and an activated subset of

assigned roles
 User/role relations can be defined independent of role/privilege
relations
 Privileges are system/application dependent

Accommodates traditional but robust group-based access control.

 Hierarchy Role Based Access Control

Role hierarchies
a. General role hierarchies
i. Include the concept of multiple inheritance of permissions
and user membership among roles
b. Limited role hierarchies
i. Impose restrictions
ii. Role may have one or more immediate ascendants but is
restricted to a single immediate descendent.

© 2019 IBM Corporation 101

Enterprise IAM Training Module

Example: Role Hierarchy for Bank

Static Separation of Duty (SSoD)

User cannot be authorized for both roles, e.g., teller and auditor SSoD
policies deter fraud by placing constrains on administrative actions and
thereby restricting combinations of privileges that are made available to
users
SSD with Hierarchical RBAC

© 2019 IBM Corporation 102

Enterprise IAM Training Module

Dynamic Separation of Duty (DSoD)

User cannot act simultaneously in both roles, e.g., teller and account
holder

 Best practices for role-based access control implementations

There are several best practices organizations should follow for implementing
RBAC, including:

 Determine the resources for which they need to control access, if they're
not already listed -- for instance, customer databases, email systems and
contact management systems.
 Analyze the workforce and establish roles that have the same access needs.
However, don't create too many roles because that would defeat the
purpose of role-based access control and create user-based access control
rather than role-based access control. For instance, there could be a basic
user role that includes the access every employee need, such as to email
and the corporate intranet. Another role could be that of a customer service
representative who would have read/write access to the customer database,

© 2019 IBM Corporation 103

Enterprise IAM Training Module

and yet another role could be that of a customer database admin with full
control of the customer database.
 After creating a list of roles and their access rights, align the employees to
those roles, and set their access.
 Evaluate how roles can be changed, as well as how accounts for employees
who are leaving the company can be terminated and how new employees
can be registered.
 Ensure RBAC is integrated across all systems throughout the company.
 Conduct training so that the employees understand the principles of RBAC.
 Periodically conduct audits of the roles, the employees who are assigned
to them and the access that's permitted for each role. If a role is found to
have unnecessary access to a certain system, change the role, and modify
the access level for those individuals who are in that role.

Concepts for implementing Access Control in IAM deployment

While RBAC and ABAC can be very complex subjects, here are four
simple concepts you can refer to not only as you start your IAM
implementation, but on an ongoing basis as your organization and needs
change:

• RBAC is for coarse-grain access control and ABAC is for fine-

grain access controls.

When you can make access control decisions with broad strokes, use
RBAC. For example, giving all teachers access to Google or all contractors
access to email. When you need more granularity than this or need to make
a decision under certain conditions, use ABAC. For example, giving
teachers access to Google if they are at School X and teach Grade Y.

• RBAC before ABAC.

A general rule of thumb is that you should try to use RBAC before ABAC
because at their core, the controls are just searching or filters. The bigger
and more complex the search, the more processing power and time it takes.
And, the more users and applications an organization has, the greater
processing impact the searches/filters will have because of the increase in
search space.

• Less is More.

If you are creating a lot of very complex RBAC and/or ABAC filters, you
are probably doing something wrong. A little bit of planning in advance

© 2019 IBM Corporation 104

Enterprise IAM Training Module

can help you structure your directory data in a way that mitigates the need
to develop complex filters/queries. However, every now and then, you will
definitely have to get creative to establish the right level of access control,
but this should be the exception and not the rule.

• Divide and Conquer.

You can always use RBAC and ABAC together in a hierarchal approach.
For example, using RBAC to control who can see what modules and then
using ABAC to control access to what they see (or can do) inside of a
module. This is similar to a WAN and LAN-based firewalls where the
WAN does the coarse-grain filtering and then LAN-based does the finer-
grain inspections.

Note: Just remember, during your implementation of IAM tools, access

control is a set of policies that ensures users have the correct access to the
correct systems, resources, and applications. So, whether you use RBAC
or ABAC, a good IAM solution should help you define what users can do
with applications by providing multiple mechanisms to ensure the right
people, get the right access, to the right things at the right time.

Fine grained and coarse-grained access

control
Granularity which literally means “level or scale of detail” and hence granularity
in authorization means the level of details used to put on authorization rules for
evaluating a decision to grant or deny the access. That means, if authorization
rule for a resource access as per business need is just based on particular check
(like associated roles) only then it is coarse. However, on contrary if business
needs require more details regarding end user/actor, current environment
conditions (time, date) etc. to grant the access then it is more granular and fine-
grained authorization.

Let’s understand the difference in more details by taking an example where the
permissions for a page and service are defined for both the scenarios.

 Coarse grained

© 2019 IBM Corporation 105

Enterprise IAM Training Module

Assume the following permission sets which defines the access based on role
assigned to the user

 Rule 1: The users having the role “A” can access the page
“/users/login.html”.
 Rule 2: The users with role “B” can access the service “loginservice”.

Now as per above Rule sets the access is governed on the basis of role associated
to the user and not based on any other user specific details or environmental
conditions etc. As per above rules the user with appropriate roles can access the
resource irrespective of any other conditions.

Since normally a user may assign to multiple roles simultaneously there are
different flavors of RBAC (like flat or hierarchical RBAC system etc.) but that
will still rely on the roles and their combinations. The above rule sets here is based
on prominent authorization system called Role Based Access Control system
(RBAC). Here in this case RBAC is quite explicit and hence we can call it a
coarse-grained authorization.

 Fine grained authorization

Now imagine if we want to restrict the access based on other additional conditions
as well for the same scenario and as per below rules:

Rule 1: The service “loginservice1” can be accessed by users

• Having role “B” assigned to them And

• Belonging to region “New York” And
• Between 9 am to 5 pm And
• From a particular range of IPs’.

Rule 2: The page “/users/login.html” can be accesses by users:

• Having role “A” assigned to them And

• Gender is “Female” And
• Age greater than 53 And
• Qualification is “B.Tech” Or “MBA”.

Now in above two rules set we can see that the level of authorization is more
detailed or scaled than the earlier rules set. Here we have more granularity for

© 2019 IBM Corporation 106

Enterprise IAM Training Module

taking decision and governing the access as per business needs and hence we can
call it as fine-grained authorization.

Overview of Context Based Access

Context-based access provides several capabilities to identify potential risk and
limit the ability for an attacker to use stolen credentials.

 Silent device registration where the system does not require any user
interaction.
 Ready-to-use, predefined policy attributes that are specific to context-
based access.
 Scenario-based, predefined risk profiles.
 A risk-scoring engine that calculates a risk score for the current transaction
based on the active risk profile. The risk score is based on configurable
weights that are assigned to context attributes and behavior attributes. If
the risk score is high, further challenges are presented to the user or access
is denied. If the risk score is low, the user is permitted access.

 Risk Management Overview

Context-based access policy decisions can be based on the risk score. The risk
score is calculated based on the active risk profile attributes that are retrieved
from the user.

The system allows for multiple risk profiles to be defined, but only one is active
at run time.

Each attribute included on a risk profile has an assigned weight to be used while
calculating the risk score of a given request. The active risk profile attributes are
evaluated to determine whether a user should be granted access to a protected
resource. A policy author can rely on the risk score to enforce stronger
authentication mechanisms or to perform device registration.

To get started setting up context-based access control for your installation, work
with:

1. Attributes: The product provides a predefined set of attributes that are

ready to use without any customization. Optionally, you can add
attributes that can come from:
o Standard HTTP headers
o HTTP FORM parameters

© 2019 IBM Corporation 107

Enterprise IAM Training Module

o Client-side JavaScript files that are collected into the attribute

collection service
o Custom attributes you define by writing custom JavaScript files
2. Obligations: The product provides a predefined set of obligations that are
ready to use without any customization. Optionally, you can update or
define your own obligations.
3. Risk profiles: The product provides a predefined set of risk profiles that
are ready to use without any customization. Optionally, you can update or
define your own risk profiles to calculate the risk score.

 Business Scenarios

Business transactions that have an increased security risk factor can benefit by
implementing context-based access.

The following examples are some scenarios where you can use context-based
access to provide a higher level of confidence for the transaction:

 A user tries to access sensitive information where a simple user ID and

password authentication is not sufficient. However, the data is not sensitive
enough to use a more complex authentication mechanism, such as token
IDs.
 Users require access from remote locations that are not trusted, and they
use devices such as mobile devices and notebooks. To ensure that mobile
users are authenticated sufficiently, the business requires a second factor
authentication.
 Users need to access an application that provides sensitive business
information. They might access the information outside of their regular
work patterns.
 A user accesses a resource from a device that the user previously used and
maintains typical usage patterns. Context-based access improves the user
experience by limiting secondary authentication mechanisms.

© 2019 IBM Corporation 108

Enterprise IAM Training Module

© 2019 IBM Corporation 109

Enterprise IAM Training Module

UNIT 4: PASSWORD MANAGEMENT

© 2019 IBM Corporation 110

Enterprise IAM Training Module

CHAPTER 8: Password Management

Password is the most common method for users to authenticate themselves when
entering computer systems or websites. It acts as the first line of defence against
unauthorised access, and it is therefore critical to maintain the effectiveness of
this line of defence by rigorously practising a good password management policy.
This training module aims to provide a set of guidelines and best practices for
handling and managing passwords.

The Challenges of Password Management

With the ever-increasing use of information technology in our daily lives, there
are also an ever-increasing number of user accounts and passwords we have to
remember and manage. The choice of passwords used for different information
systems presents a dilemma. On one hand, an intruder could gain access to ALL
the systems if the same password used for accessing these systems is
compromised. On the other hand, when different passwords are used for different
systems, users may have the tendency to choose to easy-to-remember or weak
passwords, or even write them down, which would again jeopardise the security
of the systems concerned. There is also a higher chance of users forgetting their
passwords, increasing the associated user support and operation overheads for
password resets.

The Security Threats to Passwords

A password is a convenient and easy method of authentication for users entering
a computer system. The system simply requires the user to present something he
knows as a proof that he is actually who he claims to be. This is easily
implemented, but at the same time the password approach is subject to a number
of security threats. The following are common security risks where a legitimate
user may lose his or her password:

1. Over the shoulder attack: when a person types in his or her password, someone
might be able to observe what is typed and hence steal the password by looking
over the person’s shoulder, or by indirect monitoring using a camera.

© 2019 IBM Corporation 111

Enterprise IAM Training Module

2. Brute-force attack: because a password has a finite length, usually 8

alphanumeric characters, an attacker can use programs that automatically
generate passwords, trying all possible combinations until a valid password is
found. With recent advances in computing power, the time needed to execute a
successful brute force attack has dropped considerably.

3. Sniffing attack: when a password is sent over a network, it could be captured

by network sniffing tools if the network channel is not properly encrypted. In
addition, certain malicious tools (such as a keylogger) might be able to capture a
user’s password when the password is typed in during the authentication process.

4. Login spoofing attack: this is where an attacker sets up a fake login screen that
is similar in look-and-feel to the real login screen. When a user login to the fake
screen, his password will be recorded or transmitted to the attacker.
All these attacks, if successful, can help unauthorised users harvest the passwords
of legitimate users. Systems using passwords as the only authentication method
will be unable to differentiate whether the holder of the password is a valid user
or not.

Single Password v/s Multiple Passwords

From the user’s perspective, memorising one single password is easier than
managing multiple passwords, even if the single password is a complicated one.
In addition, if only one password is enough to authenticate all systems, there is
higher awareness among users in protecting their passwords. However, using a
single password for all systems might not be technically feasible, on legacy
systems, or across multiple operating system platforms.
For systems that a user accesses only occasionally, it is quite possible for the
user to forget a rarely used password. This generates increased workload for
support staff who must reset passwords. In addition, users tend to find ways to
bypass difficult controls, such as writing down passwords, or selecting a weak
and easy-to-remember password.

For attackers, the single-password approach means that all systems will
automatically be compromised once passwords in a weakly protected system are
successfully hacked. Therefore, when an organisation decides to use the single-
password approach, all systems must be protected at the same level of security.

© 2019 IBM Corporation 112

Enterprise IAM Training Module

Considerations for Using Different Passwords

For Different Applications

 General Systems

Different information systems will have different security requirements,

depending on the functional characteristics and classification of data on each
system. As a general rule, authentication mechanisms should be deployed with
different levels of sophistication, commensurate with the value of information
assets that need to be protected. For instance, an internal application handling
classified information requires tight access control, whereas an Internet
application for general information searching may allow anonymous logins.
Following this line of thinking, different passwords should be used for different
systems with respect to their security requirements and the value of information
and assets that need to be protected. If a single password is used for accessing
multiple systems, all user accounts should be as secure as the systems with the
highest security requirement. If not, intruders may be able to hack into a weakly
protected system and in turn gain multiple access to all the other systems that
need higher security requirements.

 Critical Systems and Resources

For critical systems or applications with classified information, strict access

control should be adequate to prevent unauthorised access. Passwords for
accessing these critical internal systems should be different from each other

with respect to their associated risks.

 Internal and External Applications

For external applications, it is often hard to implement tight access control when
compared to internal applications, because an organisation might not have
complete control over the external environment. For instance, users may access a
company’s web applications from a public machine, home PC or other sites where
there is no control over security. There is therefore a greater risk of exposing
passwords to outsiders. If the same password is used for both internal and external
applications, there will be less security protection for internal systems. Once the

© 2019 IBM Corporation 113

Enterprise IAM Training Module

password for an external application is compromised, intruders may use it as a

stepping stone to breach internal applications. In general, internal and external
applications have different levels of significance and importance, and therefore
security requirements. A multiple password policy should be implemented.
Identical passwords should not be used for accessing both internal and external
applications. In addition, the recommended practice is to separate passwords used
to access critical applications or privileged accounts from passwords used for
general purpose applications. This is a practice that is widely adopted in password
guidelines used by several government bodies and organisations.

 Systems with the Same Security Requirements

To strike a balance between convenience and security, it may be acceptable to

use the same password for applications that have the same security requirements,
provided that the security policy and usage of the account is properly defined. For
instance, you may use the same password to access a timesheet entry system and
a leave application system because they are both human resource related systems,
managed under a common security policy.

Good Password Management Policies & User

It is sometimes difficult to develop a mechanism to enforce the use of different
passwords for different applications if the passwords are not managed under a
centralised database or system. Therefore, standards on using different passwords
for different applications should be clearly stated in security policies. As
password is the first line of defence against unauthorised access, it is critical that
this line of defence is made effective with a good password management policy.
In addition, users should also be educated and aware of the best practices in
choosing and handling passwords. The use of an insecure password may have a
direct impact on the security of the whole system. As such, all users need to be
responsible for taking appropriate steps to select and secure their passwords.

System Security Features

The following are desirable security features available in some operating and
application systems that can assist in enforcing some of the recommended
password selection criteria. It is recommended that such features should be
enabled whenever possible.

© 2019 IBM Corporation 114

Enterprise IAM Training Module

1. Automatically suspend a user account after a pre-defined number of

invalid logon attempts.
2. Restrict a suspended account to only allow reactivation by manual action
controlled by the system/security administrator.
3. Prevent users from using passwords shorter than a pre-defined length or
re-using previously used or old passwords.

While password is the most commonly used method of authenticating users

entering computer systems, passwords are frequently targeted by attackers
wanting to break into systems. It is critical that this first line of defence against
unauthorised access is effective by rigorously practicing good password
management policies.
Different passwords should be used for different systems with respect to the
security requirements and the value of information assets the need to be protected.
Make use of other access control mechanisms to facilitate password management
and reduce the effort required by users in memorising a large number of
passwords.
This should be enforced with good security policies and guidelines, supported by
user awareness training and education on the best practices in choosing and
handling passwords.

© 2019 IBM Corporation 115

Enterprise IAM Training Module

UNIT 5: INTRODUCTION TO SINGLE SIGNON METHODS

© 2019 IBM Corporation 116

Enterprise IAM Training Module

CHAPTER 9: Different SSO Methods

Forms Single Sign-On

Forms single sign-on authentication allows reverse proxy to transparently log an
authenticated Access Manager user in to a back-end application server that
requires authentication using an HTML.

Kerberos and SPNEGO

 Kerberos

It is an authentication protocol, which allows nodes communicating over a non-

secure network to prove their identity to one another in a secure manner. It is
designed to provide strong authentication for client/server applications by using
secret-key cryptography.

Kerberos was developed by the Massachusetts Institute of Technology (MIT) as

a solution to its network security problems. It was named after the Greek
mythological character Kerberos (or Cerberus).

The idea is very simple. If you want a service, you need to have a ticket for that
service. To obtain a ticket, you must contact the Ticket Granting Service (TGS)
to obtain a service ticket. Once the ticket is obtained, you can use it to gain access
to the intent service offered by a Service Server (SS).

© 2019 IBM Corporation 117

Enterprise IAM Training Module

 SPNEGO

It stands for Simple and Protected GSS-API Negotiation Mechanism, which

provides a mechanism for extending a Kerberos based single sign-on
environment to web-applications.

The following diagrams shows how a client application obtains a service from a
web-application through the standard HTTP protocol. Basically,

 When an application (e.g. a browser) on the PC attempts to access a

protected page on the web server, the server responds with an
unauthorized response.
 The application then requests a service ticket from the KDC, e.g. an
Active Directory.
 Once the required ticket is obtained, the application wraps it in a
SPNEGO envelope and sends it over to the web server to request the
same page again.
 The server can then unpack the envelope to retrieve the server ticket and
use it to authenticate the user.

© 2019 IBM Corporation 118

Enterprise IAM Training Module

Certificate Based

Certificate-based authentication is the use of a Digital Certificate to identify a

user, machine, or device before granting access to a resource, network,
application, etc. In the case of user authentication, it is often deployed in
coordination with traditional methods such as username and password.

One differentiator of certificate-based authentication is that unlike some solutions

that only work for users, such as biometrics and one time passwords (OTP), the
same solution can be used for all endpoints – users, machine, devices and even
the growing Internet of Things (IoT).

Below figure shows how certificates and the SSL protocol are used together for
authentication. To authenticate a user to a server, a client digitally signs a
randomly generated piece of data and sends both the certificate and the signed
data across the network. For the purposes of this discussion, the digital signature
associated with some data can be thought of as evidence provided by the client to
the server. The server authenticates the user’s identity on the strength of this
evidence.

Like for password-based authentication illustrated in Figure assumes that the user
has already decided to trust the server and has requested a resource. The server
has requested client authentication in the process of evaluating whether to grant
access to the requested resource.

© 2019 IBM Corporation 119

Enterprise IAM Training Module

Certificate-based authentication is generally considered preferable to password-

based authentication because it is based on what the user has, the private key, as
well as what the user knows, the password that protects the private key. However,
it’s important to note that these two assumptions are true only if unauthorized
personnel have not gained access to the user’s machine or password, the password
for the client software’s private key database has been set, and the software is set
up to request the password at reasonably frequent intervals.

Note –

Neither password-based authentication nor certificate-based authentication

address security issues related to physical access to individual machines or
passwords. Public-key cryptography can only verify that a private key used to
sign some data corresponds to the public key in a certificate. It is the user’s
responsibility to protect a machine’s physical security and to keep the private-key
password secret.

Certificates replace the authentication portion of the interaction between the

client and the server. Instead of requiring a user to send passwords across the
network throughout the day, single sign-on requires the user to enter the private-
key database password just once, without sending it across the network. For the
rest of the session, the client presents the user’s certificate to authenticate the user
to each new server it encounters. Existing authorization mechanisms based on the
authenticated user identity are not affected.

 Steps for Configuring Certificate-based Authentication

1. The client software maintains a database of the private keys that correspond
to the public keys published in any certificates issued for that client. The
client asks for the password to this database the first time the client needs to
access it during a given session for example, the first time the user attempts
to access an SSL-enabled server that requires certificate-based client

© 2019 IBM Corporation 120

Enterprise IAM Training Module

authentication. After entering this password once, the user doesn’t need to
enter it again for the rest of the session, even when accessing other SSL-
enabled servers.

2. The client unlocks the private-key database, retrieves the private key for the
user’s certificate, and uses that private key to digitally sign some data that
has been randomly generated for this purpose on the basis of input from both
the client and the server. This data and the digital signature constitute
“evidence” of the private key’s validity. The digital signature can be created
only with that private key and can be validated with the corresponding public
key against the signed data, which is unique to the SSL session.

3. The client sends both the user’s certificate and the evidence, the randomly
generated piece of data that has been digitally signed, across the network.

4. The server uses the certificate and the evidence to authenticate the user’s
identity.

5. At this point the server may optionally perform other authentication tasks,
such as checking that the certificate presented by the client is stored in the
user’s entry in an LDAP directory. The server then continues to evaluate
whether the identified user is permitted to access the requested resource. This
evaluation process can employ a variety of standard authorization
mechanisms, potentially using additional information in an LDAP directory,
company databases, and so on. If the result of the evaluation is positive, the
server allows the client to access the requested resource.

 Certificates and Certificate Authorities (CA)

A certificate is an electronic document that identifies an individual, a server, a

company, or some other entity. A certificate also associates that identity with a
public key. Like a driver’s license, a passport, or other commonly used personal
IDs, a certificate provides generally recognized proof of someone's or
something's identity.

Certificate authorities, CAs, validate identities and issue certificates. CAs can
be independent third parties or organizations that run their own certificate-issuing
server software. The methods used to validate an identity vary depending on the
policies of a given CA. In general, before issuing a certificate, the CA must use
its published verification procedures for that type of certificate to ensure that an
entity requesting a certificate is in fact who it claims to be.

© 2019 IBM Corporation 121

Enterprise IAM Training Module

UNIT 6: INTRODUCTION TO FEDERATION

© 2019 IBM Corporation 122

Enterprise IAM Training Module

CHAPTER 10: Federation Overview

Federation gives identity and access management a more user-oriented point of
view. The most of the IAM use cases consist of the user working inside the
organization and using only information systems provided by the organization.
However, in real life there are many services the user needs, also outside the
organization. This is described in Figure. In some cases even in health care, it is
reasonable to trust the authentication mechanism of a third party. This is called
federation. Federation provides an integrating access management to internal
directory services and identity management. Managing user rights requires
provisioning user accounts to the federated target systems manually or
automatically using e.g. SAML2.

© 2019 IBM Corporation 123

Enterprise IAM Training Module

By Definition
A federation is a relationship in which the participating entities agree to use the
same technical standard, enabling access to data and resources of one another. It
consists of one or more service providers (SP) and an identity provider (IdP). An
IdP is a partner in a federation that can authenticate the identity of a user. A
service provider is a company or program that provides a business function as a
service.
The Federation Module provides the following functions:
 Federated single sign-on (SSO) for users across multiple applications.
 Support for SAML 2.0 and OpenID Connect protocols for federated
access.
 Pre-integrated federation connectors to popular cloud applications.

Federation Example
There are many examples of federated identity management systems in operation
today. Several of these examples can be seen on the Internet, where large service
providers, such as Facebook and Google act as identity providers, and allow users
to access third party services by means of their Facebook or Google account.
These large service providers offer software development kits (SDK) and
Application Programming Interfaces (API) so that application developers (for
web and mobile apps) can take advantage of existing authentication mechanisms
and attract new users to their services without new registration processes. Figure
illustrates a potential benefit of FIM from a user perspective, through existing
federation solutions.

© 2019 IBM Corporation 124

Enterprise IAM Training Module

Federated Identity Management Architecture

Federated identity management (FIM) functionality enables companies and
business partners to lower their overall identity management costs, improve user
experience reduce the company pain points, and mitigate security risks for
transactions. When discussing identity federation, identity federation splits into a
few different solution areas shown in Figure. The solution areas are:
 Web-based Single Sign-on - Federated Single Sign-on referred to as F-SSO
 Application based Web services security - Secure Web services referred to
as Web services security management
 Identity life cycle - Federated provisioning

© 2019 IBM Corporation 125

Enterprise IAM Training Module

Federation technology is used to:

 Provide a simple mechanism to identify and validate users from business
partner organizations and provide them with seamless access to Web sites
within that trusted Federation.
 Support standards-based end to end trust and security for applications
exposed as Web services between businesses.
 Off load the expensive part of the user management—the cost of user
enrolment, account creation, password management and user care—to one
business partner (an identity provider).
 Standardize the provisioning of users and attributes to support both user
and application-based interactions, extending enterprise identity
management to inter enterprise identity management
 Reduce business partners need to manage large sets of user data, including
the cost of managing authentication credentials for large numbers of users.
The goal of federation is to support a dynamic and seamless integration of
services and resources between businesses within a federation.
 Architecture Overview

Federated relationships can be based on proprietary technologies that allow

business partners to communicate and collaborate. In general, a proprietary
approach is not scalable or maintainable across a large set of partners. For this
reason, standards and specification-based approaches are rapidly gaining in
popularity. Federations facilitate an integrated approach to business.
Federations are entered in to facilitate two major types of functionality:
 Seamless and secure user interaction across federation business partners
(aka, federated single sign-on)
 Seamless and secure business interaction across application platform
integration (aka, Web services security management for Service Oriented
Architectures)
Both functionality types leverage the same basic functionality, namely, both
require a trust infrastructure. The trust infrastructure provides the technical
representation and implementation of the business and legal agreements between
business partners, as shown below. Both federated single sign-on and Web
services security solutions are built on a trust infrastructure.

© 2019 IBM Corporation 126

Enterprise IAM Training Module

Federated identity management often refers to user-driven, browser-based

interaction between organizations. This space is reference to as federated single
sign-on (F-SSO) even though it has largely matured beyond just single sign-on
functionality. Standards and specifications such as the SAML specification and
WS-Federation and Liberty Alliance ID-FF specifications all now include an
aspect of session life cycle management (single sign-on and single sign-off) as
well as single sign-on enablement through account linking. This comprehensive
approach and enablement of a single sign-on environment is designed to ease the
user experience and reduce the cost of management of these users. For example,
previously a user had to establish an account, including user name and password,
at each business partner; the business partner in turn had to assume the cost of
managing this user and the user’s access to their system. Federation solutions ease
this cost by reducing the amount of information that must be managed for each
user and the overall cost of managing this information.

As Web services evolve, currently boosted by the industries drive towards

building service-oriented architectures, the need to expose them to external
businesses will increase rapidly. Web services security targets the secure inter-
operability of applications or programs. Web services provide a flexible and
easily adoptable means of integrating applications. Web services security defines
how to do this in a secure manner. This includes securing the message through
signatures and encryption. It also includes authenticating and authorizing requests
based on the Web services invoker's claimed identity. This identity is represented
with a Web services security token; this process of authenticating a principal's
identity (be it user or application) is a form of reduced-sign-on.

Unlike the federated identity management single sign-on described above,

however, this occurs in what is often referred to as an active client environment.
This means that the applications that are invoking Web services are able to

© 2019 IBM Corporation 127

Enterprise IAM Training Module

assert their claimed identities in a Web services request without having to

negotiate a separate (dedicated) single-sign-on protocol.

To design a solution, the following areas need to be understood, and are covered
in this section:

 The roles of identity and service provider: The definition who is the
authoritative source of the user identity information.

 Digital identity repository: Use a digital identity repository that contains

policies and meta directories to govern access. In addition, an application
privileges system contains information about entitlement to resources,
information, and access. These repositories may reside on various machines
and physical locations. They might be implemented on a variety of hardware
and software solutions and use a number of configurations. The discovery
process is used by the provider to locate relevant authentication and authority
data across distributed domains and systems. Digital identity stores is a term
used by Microsoft to describe a repository of digital identities.

 Authentication and certification process: This process certifies the data—

the recipient of the data has the ability to validate and verify its authenticity.
A claim is an assertion that certain identifying information such as a name or
a credit card truly belongs to a given digital entity. Claims could be an
identifier (such as a user name) or an attribute (such as a user age or gender).

 Identity providers and notary: Often the communicating parties are

unknown to each other and, therefore, cannot trust that the identities are
properly authenticated. This can occur in ad-hoc or peer-to-peer
communications. A third-party trusted vendor could be employed to
authenticate identities and their assertion. This is often referred to as a
federated notary.

 Credentials: A credential is an attestation of qualification, competence, or

authority issued to an individual by a third party with a relevant de jure or de
facto authority or assumed competence to do so. Examples of credentials
include academic diplomas, security clearances, identification documents,
badges, passwords, user names, keys, and powers of attorney.

© 2019 IBM Corporation 128

Enterprise IAM Training Module

Identity syntax and attributes: An Identity profile should contain several user
attributes and credentials. Such attributes might be personal data, habits, and
biometrics. Different standards and implementations use different structures to
describe attributes and credentials. Ideally, those should be interoperable.

Policy control: Policy control governs access to information and determines

how information is used, disclosed, audited, and logged. Rather than
proprietary, application or operating system driven access control, IdMS purport
integrative policies to govern access. Policy controls use policy sets, a collection
of policies, rules, obligations, and a target. The control uses predetermine
algorithms to combine rules. A rule specifies permission (or a denial) to perform
an action on an asset. A target is a set of conditions and actions that must be met
for a policy to apply. Organizations’ security policies are complex and contain
thousands of rules. Often policies that affect a particular digital asset are written
from a variety of views and are difficult to integrate.

Provisioning: Companies enable user’s access to certain digital assets (e.g.,

networks, applications, devices such as a PDA, or credit cards). The process of
rationing assets to employees is termed provisioning. While the term
provisioning is often used in reference to employees, organizations also
provision assets to other stakeholders, such as temporary employees,
consultants, customers, and suppliers. Provisioning mechanism refers to the
automation of the workflow of systems, devices, services, and other resources to
various stakeholders. For example, as a temporary employee logs into a system,
they are provisioned access to certain resources and services depending on their
role and tasks. At the end of their engagement, the system de-provisions these
resources. Similarly, a web service might be provisioned access to a particular
data store for the duration of a request.

Token: As mentioned above, some standards and implementations use the

concept of a token. A token contains claims (or assertions) about the entity
requesting the service (the requestor) and may be codified using a variety of
structures (for example, WS-* uses the concept of token and can seamlessly
interoperate with other tokens regardless of the structure they use). A Security
Token Service (STS) and related protocols are used to request or issue the token
(i.e., WS-Trust), while a related set of policies describe the STS and its
associated claims (i.e., WS-SecurityPolicy).

Account linking: The procedures for managing the account linking, to agree on
some common unique identifier for the user, which can be bounded with the
internal, local user identity at the service provider. This step also involves the

© 2019 IBM Corporation 129

Enterprise IAM Training Module

definition of the account de-linking/de-provisioning procedures.

Trust: The process of ensuring security for connections/transport, messages and

tokens.

 Roles

Within a federation, business partners play one of two roles: Identity provider
or service provider or both. The identity provider (IdP) is the authoritative site
responsible for authenticating an end user and asserting an identity for that
user in a trusted fashion to trusted business partners. Those business partners
who offer services but do not act as identity providers are known as service
providers. The identity provider takes on the bulk of the user's life cycle
management issues. The service provider (SP) relies on the IdP to assert
information about a user, leaving the SP to manage only those user attributes
that are relevant to the SP.

 Identity provider - IdP

The identity provider is responsible for account creation, provisioning,

password
management, and general account management, and also acts as a collection
point or client to trusted identity providers. Having one federation business
partner act as a user's IdP relieves the remaining business partners of the
burden of managing equivalent data for the user. These non-IdP business
partners act as service providers (SPs). These service providers will leverage
their trust relationships with an IdP to accept and trust vouch-for information
provided by an IdP on behalf of a user, without the direct involvement of the
user. This enables businesses (service providers) to off load identity and
access management costs to business partners within the federation.

© 2019 IBM Corporation 130

Enterprise IAM Training Module

To achieve the overall user life cycle management required for a full federated
identity management solution, the identity provider assumes the management
of user account creation, account provisioning, password management, and
identity assertion. The identity provider and service provider cooperate to
provide a rich user experience by leveraging distinct federated identity
management profiles that together provide a seamless federation functionality
for a user.

 Service provider – SP

A service provider may still manage local information for a user, even within
the context of a federation. For example, entering into a federated identity
management relationship may allow a service provider to handle account
management (including password management) to an IdP while the SP
focuses on the management of its user-specific data (for example, SP-side
service-specific attributes and personalization related information). In general,
a service provider will off-load identity management to an identity provider to
minimize its identity management requirements while still enabling full
service provider functionality.

© 2019 IBM Corporation 131

Enterprise IAM Training Module

CHAPTER 11: Federation Protocols

Security Assertion Markup Language (SAML)

Security Assertions Markup Language is a specification designed to provide
cross-vendor single-sign-on interoperability. SAML was developed by a
consortium of vendors (including IBM) under the auspices of OASIS, through
the OASIS SSTC (Security Services Technical Council). SAML has two major
components: It describes SAML assertions used to transfer information within a
single sign-on protocol and SAML bindings and profiles for a single sign-on
protocol.

A SAML assertion is an XML-formatted token that is used to transfer user

identity (and attribute) information from a user's identity provider to trusted
service providers as part of the completion of a single sign-on request. A SAML
assertion provides a vendor-neutral means of transferring information between
federation business partners. As such, SAML assertions have a lot of traction in
the overall federation space.

As a protocol, SAML has three versions: SAML 1.0, 1.1, and SAML 2.0. SAML
1.0 and SAML 1.1 (collectively, SAML 1.x) focus on single sign-on
functionality. SAML 2.0 represents a major functional improvement over SAML
1.x. SAML 2.0 (approved in March 2005) is based on SAML 1.x with significant
input from the Liberty Alliance ID-FF and Shibboleth specifications.

SAML 2.0 is a protocol that you can use to perform federated single sign-on from
identity providers to service providers. In federated single sign-on, users
authenticate at identity provider. Service providers consume the identity
information asserted by identity providers.

SAML 2.0 relies on the use of SOAP, among other technologies, to exchange
XML messages over computer networks. The XML messages are exchanged
through a series of requests and responses.

In this process, one of the federation partners sends a request message to the other
federation partner. Then, that receiving partner immediately sends a response
message to the partner who sent the request.

The SAML specifications include descriptors to establish a federation, initialize,

and manage single sign-on. The following descriptors specify the structure,

© 2019 IBM Corporation 132

Enterprise IAM Training Module

content of the messages, and the way the messages are communicated between
partners and users.

 Assertions

XML-formatted tokens that are used to transfer user identity information, such as
the authentication, attribute, and entitlement information, in the messages.

Protocols
The types of request messages and response messages that are used for obtaining
authentication data and for managing identities.

Bindings
The communication method that is used to transport the messages.

Profiles
Combinations of protocols, assertions, and bindings that are used together to
create a federation and enable federated single sign-on. You and your partner
must use the same SAML specification (2.0) and agree on which protocols,
bindings, and profiles to use.

 SAML 2.0 overview

The Federation Module relies on the SAML 2.0 specification to establish a

federation and to initialize and manage single sign-on.

Assertions
The assertions contain authentication statements. These authentication statements
assert that the principal (that is, the entity that requests access) was authenticated.
Assertions can also carry attributes about the user that the identity provider wants
to make available to the service provider.
Assertions are typically passed from the identity provider to the service provider.

The content of the assertions that are created is controlled by the SAML 2.0
specification. Select these assertions when you establish a federation. You can
also select these assertions by the definitions that are used in the identity mapping
method that you configure.
The identity mapping method can either be a custom mapping module or an XSL
transform file. The identity mapping also specifies how identities are mapped
between federation partners.

© 2019 IBM Corporation 133

Enterprise IAM Training Module

Protocols
SAML 2.0 defines several request-response protocols that correspond to the
action that is being communicated in the message. The SAML 2.0 protocols that
are supported are:
 Authentication request
 Single logout
 Artifact resolution
 Name identifier management

 SAML 2.0 profiles

SAML 2.0 profiles combine protocols, assertions, and bindings to create a

federation and enable federated single sign-on.

The following profiles are supported:

Web browser single sign-on

This profile provides options regarding the initiation of the message flow and the
transport of the messages:

Flow initiation
The message flow can be initiated from the identity provider or the service
provider.

Bindings
The following bindings can be used in the Web browser SSO profile:
 HTTP redirect
 HTTP POST
 HTTP artifact
The choice of binding depends on the type of messages being sent. For example,
an authentication request message can be sent from a service provider to an
identity provider using HTTP redirect, HTTP POST, or HTTP artifact. The
response message can be sent from an identity provider to a service provider by
using either HTTP POST or HTTP artifact. A pair of partners in a federation does
not need to use the same binding.

© 2019 IBM Corporation 134

Enterprise IAM Training Module

Single Logout

The Single Logout profile is used to terminate all the login sessions currently
active for a specified user within the federation. A user who achieves single sign-
on to a federation establishes sessions with more than one participant in the
federation.
The sessions are managed by a session authority, which in many cases is an
identity provider. When the user wants to end sessions with all session
participants, the session authority can use the single logout profile to globally
terminate all active sessions.
This profile provides options regarding the initiation of the message flow and the
transport of the messages:

Flow initiation
The message flow can be initiated from the identity provider or the service
provider.

Bindings
The following bindings can be used in the Single Logout profile:
 HTTP redirect
 HTTP POST
 HTTP artifact
 SOAP
Name Identifier Management

The Name Identifier Management profile manages user identities that are
exchanged between identity providers and service providers.
This profile can be used by identity providers or service providers to inform their
partners when there is a change in user aliases.
This profile can also be used by identity providers or service providers to
terminate user linkages at the partners.
To manage the aliases, the Federation module uses a function that is called the
alias service. The alias service stores and retrieves aliases that are related to a
federated identity. User aliases are stored and retrieved from high-volume
database.
This profile provides options regarding the initiation of the message flow and the
transport of the messages:

Flow initiation
The message flow can be initiated from the identity provider or the service
provider.

© 2019 IBM Corporation 135

Enterprise IAM Training Module

Bindings
The following bindings can be used in the Web browser SSO profile:
 HTTP redirect
 HTTP POST
 HTTP artefact
 SOAP

 SAML 2.0 endpoints and URLs

Communications within a federation take place through endpoints on the servers

of the identity provider and service provider partners.
In a Access Manager environment, endpoints fall into two categories:
 Endpoints that are specified by the federation specification (such as SAML
2.0) and are used for partner-to-partner communication.
 Endpoints that end users can access to initiate a single sign-on activity.
All endpoints can be accessed through URLs. The syntax of the URLs is specific
to the purpose of the access and whether the access is by a partner or by an end
user.

URLs for partner communication

The URLs that are used for partner-to-partner communication, such as the
exchange of requests, in SAML 2.0 federations are referred to collectively as
endpoint URLs. They can also be individually referred to by the name of the
protocol and binding or service that they are related to.

URLs for user access

While the SAML specifications define the endpoints for partner-to-partner
communication, they provide limited or no guidance about the endpoints or
methods that end users must use to initiate single sign-on actions.
In a SAML 2.0 federation, single sign-on actions can be initiated at the identity
provider site or the service provider site. URLs that can be used by users to initiate
a sign-on action are specific to a single sign-on action, such as initiate a federated
sign on, perform a single logout, or end account linkage. They are also specific
to whether the action is being initiated at the identity provider or service provider
site.

Endpoint URL specifications

You must define several endpoints on your point of contact server so that
communications can be exchanged between you and your partner.

© 2019 IBM Corporation 136

Enterprise IAM Training Module

The following types of endpoint URLs initiate single sign-on:

 Single sign-on service
 Assertion consumer service
 Single logout service endpoint
 Artifact resolution service or SOAP
 Name identifier management service

 SAML 2.0 bindings

SAML requestors and responders communicate by exchanging messages. The

mechanism to transport these messages is called a SAML binding.
Access Manager supports the following bindings:

HTTP redirect
HTTP redirect enables SAML protocol messages to be transmitted within URL
parameters. It enables SAML requestors and responders to communicate by using
an HTTP user agent as an intermediary.
The intermediary might be necessary if the communicating entities do not have a
direct path of communication. The intermediary might also be necessary if the
responder requires interaction with a user agent, such as an authentication agent.
HTTP redirect is sometimes called browser redirect in single sign-on operations.
This profile is selected by default.

HTTP POST
HTTP POST enables SAML protocol messages to be transmitted within an
HTML form by using base64-encoded content. It enables SAML requestors and
responders to communicate by using an HTTP user agent as an intermediary. The
agent might be necessary if the communicating entities do not have a direct path
of communication. The intermediary might also be necessary if the responder
requires interaction with a user agent such as an authentication agent.
HTTP POST is sometimes called Browser POST, particularly when used in single
sign-on operations. It uses a self-posting form during the establishment and use
of a trusted session between an identity provider, a service provider, and a client
(browser).

HTTP artifact
HTTP artifact is a binding in which a SAML request or response (or both) is
transmitted by reference by using a unique identifier that is called an artifact.

© 2019 IBM Corporation 137

Enterprise IAM Training Module

A separate binding, such as a SOAP binding, is used to exchange the artifact for
the actual protocol message. It enables SAML requestors and responders to
communicate by using an HTTP user agent as an intermediary.
This setting is used when it is not preferable to expose the message content to the
intermediary.

HTTP artifact is sometimes called browser artifact, particularly when used in

single sign-on operations. The HTTP artifact uses a SOAP back channel.
The SOAP back channel is used to exchange an artifact during the establishment
and use of a trusted session between an identity provider, a service provider, and
a client (browser).

SOAP
SOAP is a binding that uses Simple Object Access Protocol (SOAP) for
communication.
To use SOAP binding, SAML requestors must have a direct communication path
with SAML responders

 SAML 2.0 name identifier formats

SAML 2.0 name identifier formats control how the users at identity providers are
mapped to users at service providers during single sign-on.

Access Manager supports the following name identifier formats:

Email address
Use the email address name identifier format if you want a user to log in at the
service provider as the same user that they use to log in at the identity provider.
For example, if a user is logged in at the identity provider as user1, then they will
also be logged in as user1 at the service provider after single sign-on.

Persistent aliases
Use the persistent name identifier format if you want a user to log in at the identity
provider as one user but log in at the service provider as a different user.

Before you can use this name identifier format, you must link the user at the
identity provider with the user at the service provider. You can choose to have
the user linking done during single sign-on or by using the alias service.

© 2019 IBM Corporation 138

Enterprise IAM Training Module

For example, suppose user1 in the identity provider is linked with user2 in the
service provider. If user1 is logged in at the identity provider, then they will be
logged in as user2 in service provider after single sign-on.

Transient aliases
Use the transient name identifier format if you want a user to log in as a shared
anonymous user, regardless of which user that they use to log in at the identity
provider.

For example, suppose user1 is a shared anonymous user in the service provider.
If the user is logged in as user2 in the identity provider, then they will be logged
in as user1 in the service provider after single sign-on.
Similarly, if the user is logged in as user3 in the identity provider, then they will
be logged in also as user1 in the service provider.

Alias service
To manage the aliases, the Federation module uses an alias service. The alias
service stores and retrieves aliases that are related to a federated identity.
Persistent name identifier format allows you to link a user at the identity provider
with a user at the service provider.

 SAML 2.0 Service Provider Worksheet

© 2019 IBM Corporation 139

Enterprise IAM Training Module

© 2019 IBM Corporation 140

Enterprise IAM Training Module

© 2019 IBM Corporation 141

Enterprise IAM Training Module

© 2019 IBM Corporation 142

Enterprise IAM Training Module

Liberty
The Liberty Alliance Project was formed to deliver and support a federated
network identity solution for the Internet that enables single sign-on for
consumers and business users in an open, federated way.

The Liberty Identify Framework, ID-FF, describes federation functionality that

goes beyond single sign-on. Initially released as Liberty Alliance ID-FF 1.0 in
July 2002, the latest release of the Liberty specification is Version 1.2, released
November 2003.

Liberty ID-FF describes profiles for B2C-based single sign-on and additional
functionality. Liberty ID-FF profiles include: Single sign-on (SSO), single log-
out (SLO), Account Linking (Register Name Identifier, or RNI in ID-FF 1.1),
Account De-Linking (Federation Termination Notification, or FTN in ID-FF 1.1),
and identity provider introduction (IPI). The Liberty-specified common user
identifier (CUID) is referred to as a NameIdentifier. It is an opaque reference to
a user that acts as an alias, meaning that it cannot be used to infer information
about the user, such as her identity. A Liberty NameIdentifier is used to establish

© 2019 IBM Corporation 143

Enterprise IAM Training Module

(and maintain) the account linking between an IdP and an SP. The RNI profile is
used to allow a reset of a user's NameIdentifier, replacing a current value with a
new NameIdentifier value. The FTN process is used to remove all references to a
NameIdentifier, thus achieving account de-linking. Taken together, these profiles
are intended to provide richer user management functionality within a federation
than simple single-sign-on.

In ID-FF 1.2, the RNI and FTN profiles have been collapsed into a single profile,
the Manage Name Identifier (MNI) profile. This profile moves all of the account
linking life cycle into a single profile.

The Liberty approach is based on business affiliates forming circles of trust. The
Liberty circles of trust is defined as “a group of service providers that share linked
identities and have pertinent business agreements in place regarding how to do
business and interact with identities.”

WS-Federation
WS-Federation is a specification defined by IBM, Microsoft, VeriSign, and RSA
within the scope of the IBM-Microsoft Web services security roadmap. WS-
Federation was published on July 8, 2003. WS-Federation interoperability
between IBM and Microsoft has been demonstrated several times, including by
Bill Gates and Steve Mills in New York City in September of 2003. Subsequent
to that, a public interoperability exercise was held on March 29–30, 2004 between
IBM, Microsoft, and other third-party vendors.
WS-Federation describes how to use the existing Web services security building
blocks to provide federation functionality, including trust, single sign-on (and
single sign-off), and attribute management across a federation. WS-Federation is
really a family of three specifications: WS-Federation, WS-Federation Passive
Client, and WS-Federation Active Client.

WS-Federation itself describes how to implement a federation in a Web services

world. In particular, WS-Federation focuses on the relationships between parties,
and the high-level architecture that supports these relationships. The two
individual documents, WS-Federation Active and WS-Federation Passive,
describe how to implement individual federation solutions.

WS-Federation Active describes how to implement federation functionality in the

active client environment. Active clients are those that are Web services enabled,
that is, able to issue Web services requests and react to a Web services response.

© 2019 IBM Corporation 144

Enterprise IAM Training Module

Leveraging the Web services security stack, WS-Federation Active describes

how to implement the advantages of a federation relationship, including single
sign-on, in an active client environment.
WS-Federation Passive describes how to implement federation functionality in a
passive client environment. A passive client is one that is not Web services
enabled. The most commonly encountered example of a passive client is a vanilla
HTTP browser. WS-Fed Passive describes how to leverage the advantages of a
federation relationship such as single- sign-on in a passive client environment.
Because this solution leverages the WS-Security foundation of the infrastructure
support, the same components used to provide a passive client solution may be
leveraged for an active client solution.

The logical architecture described in WS-Federation, together with the

functionality described in the Web services security stack, supports both the
active and passive client scenarios. The complete family of WS-Security
specifications provides companies with a standards-based interoperable secure
digital identity and trust platform for Web services- based architecture.

Furthermore, these specifications promote reusability of existing IT security

investments, enabling companies to work with multiple security token types and
multiple scenarios including vanilla browsers, enhanced browsers, active clients,
and application-to-application connectivity.

OAuth 2.0 concepts

The following concepts are generally used in OAuth 2.0.

Resource owner
An entity capable of authorizing access to a protected resource. When the
resource owner is a person, it is called an user.

OAuth client
A third-party application that wants access to the private resources of the resource
owner. The OAuth client can make protected resource requests on behalf of the
resource owner after the resource owner grants it authorization. OAuth 2.0
introduces two types of clients: confidential and public. Confidential clients are
registered with a client secret, while public clients are not.

© 2019 IBM Corporation 145

Enterprise IAM Training Module

OAuth server
Known as the Authorization server in OAuth 2.0. The server that gives OAuth
clients scoped access to a protected resource on behalf of the resource owner. The
server issues an access token to the OAuth client after it successfully does the
following actions:
 Authenticates the resource owner.
 Validates a request or an authorization grant.
 Obtains resource owner authorization.
 An authorization server can also be the resource server.

Access token
A string that represents authorization granted to the OAuth client by the resource
owner. This string represents specific scopes and durations of access. It is granted
by the resource owner and enforced by the OAuth server.

Protected resource
A restricted resource that can be accessed from the OAuth server using
authenticated requests.

Resource server
The server that hosts the protected resources. It can use access tokens to accept
and respond to protected resource requests. The resource server might be the same
server as the authorization server.

Authorization grant
A grant that represents the resource owner authorization to access its protected
resources. OAuth clients use an authorization grant to obtain an access token.
There are four authorization grant types: authorization code, implicit, resource
owner password credentials, and client credentials.

Authorization code
A code that the Authorization server generates when the resource owner
authorizes a request.

Refresh token
A string that is used to obtain a new access token.
A refresh token is optionally issued by the authorization server to the OAuth
client together with an access token. The OAuth client can use the refresh token
to request another access token that is based on the same authorization, without
involving the resource owner again.

© 2019 IBM Corporation 146

Enterprise IAM Training Module

 OAuth 2.0 endpoints

Endpoints provide OAuth clients the ability to communicate with the OAuth
server or authorization server within a definition.
All endpoints can be accessed through URLs. The syntax of the URLs is specific
to the purpose of the access.
If you are responsible for installing and configuring the appliance, you might find
it helpful to be familiar with these endpoints and URLs.

API protection definitions

The API protection definitions naming follows the standard Advanced Access
Control naming convention. The syntax is:

https://<hostname:port>/<junction>/sps/oauth/oauth20

For example:
https://server.oauth.com/mga/sps/oauth/oauth20

The following table describes the endpoints that are used in an API protection
definition.

Notes:
 There is only a single set of endpoints.
 Not all authorization grant types use all three endpoints in a single OAuth
2.0 flow.

© 2019 IBM Corporation 147

Enterprise IAM Training Module

 OAuth 2.0 workflow

The OAuth 2.0 support in Access Manager provides four different ways for an
OAuth client to obtain access the protected resource.

OAuth 2.0 workflow

Advanced Access Control supports the following OAuth 2.0 workflows.

Authorization code flow

The authorization code grant type is suitable for OAuth clients that can keep their
client credentials confidential when authenticating with the authorization server.

© 2019 IBM Corporation 148

Enterprise IAM Training Module

For example, a client implemented on a secure server. As a redirection-based

flow, the OAuth client must be able to interact with the user agent of the resource
owner. It also must be able to receive incoming requests through redirection from
the authorization server.

The authorization code workflow diagram involves the following steps:

1. The OAuth client initiates the flow when it directs the user agent of the resource
owner to the authorization endpoint. The OAuth client includes its client
identifier, requested scope, local state, and a redirection URI. The authorization
server sends the user agent back to the redirection URI after access is granted or
denied.

2. The authorization server authenticates the resource owner through the user
agent and establishes whether the resource owner grants or denies the access
request.

3. If the resource owner grants access, the OAuth client uses the redirection URI
provided earlier to redirect the user agent back to the OAuth client. The
redirection URI includes an authorization code and any local state previously
provided by the OAuth client.

4. The OAuth client requests an access token from the authorization server
through the token endpoint. The OAuth client authenticates with its client
credentials and includes the authorization code received in the previous step.

© 2019 IBM Corporation 149

Enterprise IAM Training Module

The OAuth client also includes the redirection URI used to obtain the
authorization code for verification.

5. The authorization server validates the client credentials and the authorization
code. The server also ensures that the redirection URI received matches the URI
used to redirect the client in Step 3. If valid, the authorization server responds
back with an access token.
The authorization server can be the same server as the resource server or a
separate entity. A single authorization server can issue access tokens accepted by
multiple resource servers.

Authorization code flow with refresh token

The authorization code workflow with refresh token diagram involves the
following steps:

1. The OAuth client requests an access token by authenticating with the

authorization server with its client credentials and presenting an authorization
grant.

2. The authorization server validates the client credentials and the authorization
grant. If valid, the authorization server issues an access token and a refresh
token.

3. The OAuth client makes a protected resource request to the resource server
by presenting the access token.

© 2019 IBM Corporation 150

Enterprise IAM Training Module

4. The resource server validates the access token. If the access token is valid, the
resource owner serves the request.

5. Repeat steps 3 and 4 until the access token expires. If the OAuth client knows
that the access token has expired, skip to Step 7. Otherwise, the OAuth client
makes another protected resource request.

6. If access token is not valid, the resource server returns an error.

7. The OAuth client requests a new access token by authenticating with the
authorization server with its client credentials and presenting the refresh token.

8. The authorization server validates the client credentials and the refresh token,
and if valid, issues a new access token and a new refresh token.

Implicit grant flow

The implicit grant type is suitable for clients that are not capable of maintaining
their client credentials confidential for authenticating with the authorization
server.An example can be in the form of client applications that are in a user
agent, typically implemented in a browser using a scripting language such as
JavaScript.

As a redirection-based flow, the OAuth client must be able to interact with the
user agent of the resource owner, typically a web browser. The OAuth client
must also be able to receive incoming requests through redirection from the
authorization server.

© 2019 IBM Corporation 151

Enterprise IAM Training Module

The implicit grant workflow diagram involves the following steps:

1. The OAuth client initiates the flow by directing the user agent of the resource
owner to the authorization endpoint. The OAuth client includes its client
identifier, requested scope, local state, and a redirection URI. The authorization
server sends the user agent back to the redirection URI after access is granted or
denied.

2. The authorization server authenticates the resource owner through the user
agent and establishes whether the resource owner grants or denies the access
request.

3. If the resource owner grants access, the authorization server redirects the user
agent back to the client using the redirection URI provided earlier. The
redirection URI includes the access token in the URI fragment.

4. The user agent follows the redirection instructions by making a request to the
web server without the fragment. The user agent retains the fragment
information locally.

© 2019 IBM Corporation 152

Enterprise IAM Training Module

5. The web server returns a web page, which is typically an HTML document
with an embedded script. The web page accesses the full redirection URI
including the fragment retained by the user agent. It can also extract the access
token and other parameters contained in the fragment.

6. The user agent runs the script provided by the web server locally, which
extracts the access token and passes it to the client.

Resource owner password credentials flow

The resource owner password credentials grant type is suitable in cases where the
resource owner has a trust relationship with the client. For example, the resource
owner can be a computer operating system of the OAuth client or a highly
privileged application.

You can only use this grant type when the OAuth client has obtained the
credentials of the resource owner. It is also used to migrate existing clients using
direct authentication schemes by converting the stored credentials to an access
token.

The resource owner password credentials workflow diagram involves the

following steps:

1. The resource owner provides the client with its user name and password.

2. The OAuth client requests an access token from the authorization server
through the token endpoint. The OAuth client authenticates with its client
credentials and includes the credentials received from the resource owner.

3. After the authorization server validates the resource owner credentials and the
client credentials, it issues an access token and optionally a refresh token.

© 2019 IBM Corporation 153

Enterprise IAM Training Module

Client credentials flow

The client credentials flow is used when the OAuth client requests an access token
using only its client credentials. This flow is applicable in one of the following
situations:
 The OAuth client is requesting access to the protected resources under its
control.
 The OAuth client is requesting access to a different protected resource,
where authorization has been previously arranged with the authorization
server.

The client credentials workflow diagram involves the following steps:

1. The OAuth client requests an access token from the token endpoint by
authenticating with its client credentials.

2. After the authorization server validates the client credentials, it issues an

access token.

Client authentication considerations at the OAuth 2.0 token endpoint

The OAuth 2.0 token endpoint is used for direct communications between an
OAuth client and the authorization server. The token endpoint is used to obtain
an OAuth token.

The client type, whether public or confidential, determines the authentication

requirements of the OAuth 2.0 token endpoint. The Advanced Access Control
runtime is responsible for authenticating the client by using the client_id and
client_secret in sending the request.

OAuth 2.0 workflows for confidential clients that require client authentication at
the token endpoint, can be configured in one of the following ways:

1. The Advanced Access Control point of contact requires authentication at the

token endpoint:
 The point of contact is responsible for authenticating the client.
 The Confidential check box from the client instance panel is not relevant.
A client_secret parameter must not be sent in the token endpoint request.

© 2019 IBM Corporation 154

Enterprise IAM Training Module

 If a client_id parameter is sent in the request, it must match the identity of

the client that is authenticated by the point of contact.
2. The Advanced Access Control point of contact permits unauthenticated access
to the token endpoint:
 The client_id parameter in the token endpoint request is used to identify
the client.
 The Confidential check box from the client instance panel determines
whether a client_secret parameter is required in the token endpoint request.
A client secret is required for confidential clients only.
Note: When enforcing client authentication at the token endpoint, the point of
contact must contain the client ID and client secret within its user registry. The
point of contact must be able to map the authenticated user credential to the
client_id parameter sent in the OAuth 2.0 token endpoint request.
Based on this information, the following configurations are supported:

OpenID Connect federations

The Federation Module supports OpenID Connect federations.
OpenID Connect is an extension of the OAuth protocol to better support identity
and authentication.

OpenID Connect concepts

This topic introduces the main concepts of OpenID Connect.

OpenID Connect Provider (OP)

© 2019 IBM Corporation 155

Enterprise IAM Training Module

OAuth 2.0 Authorization Server that is capable of authenticating the end-user and
providing claims to a Relying Party about the authentication event and the end-
user.

Relying Party (RP)

OAuth 2.0 Client application that requires end-user authentication and claims
from an OpenID Connect Provider.

Entity Something that has a separate and distinct existence and that can be
identified in a context. An end-user is one example of an entity.

Claim
Piece of information asserted about an entity that is included in the ID token. An
OpenID Connect Provider should document which claims it includes in its ID
tokens.
The following claims are required claims about the authentication event:
 aud (Audience): Must contain the client identifier of the RP registered at
the issuer.
 iss(Issuer): The issuer identifier of the OP.
 exp (Expiration time): The RP must validate the ID token before this time.
 iat (Issued at): The time at which the ID token was issued.
The following claims are required claims about the user:
 sub (Subject): A locally unique and permanent (never reassigned) identifier
of the end-user at the issuer.
Optional claims about the user can include first_name, last_name, picture,
gender, etc.

Scope A property requested by the Relying Party, which can be consented to by

the end-user, that requests certain claims be included in the ID token.
OpenID Connect requires the openid scope. Common scopes include profile and
email.

Bearer token
Token issued from the token endpoint. This includes an access token, a ID token,
and potentially a refresh token.

ID token
JSON Web Token (JWT) that contains claims about the authentication event and
the user.

© 2019 IBM Corporation 156

Enterprise IAM Training Module

JWTs are Base64 encoded JSON objects comprising three sections: Header,
Claims Set and JSON Web Signature (JWS). These are separated in the JWT by
a period ('.'). The Header must at least contain the algorithm used to sign the JWT
(the alg claim).
The Claims Set includes claims about the authentication event and the user.
The JSON Web Signature (JWS) is used to verify the signing of the JWT.

Refresh token
A string that is used to obtain a new access token.
A refresh token is optionally issued by the OpenID Connect Provider to the
OpenID Connect Partner together with an access token. The OpenID Connect
Partner can use the refresh token to request another access token that is based on
the same authorization, without involving the resource owner again.

Issuer Entity that issues a set of claims.

Issuer identifier
Verifiable identifier for an issuer. An issuer identifier is a case sensitive URL
using the HTTPS scheme that contains scheme, host, and optionally, port number
and path components and no query or fragment components.

Authorization endpoint
The endpoint used to initiate an OpenID Connect flow. This endpoint is requested
in some bespoke manner.

Token endpoint
The endpoint used to exchange an authorization code for a bearer token.
This is also used to exchange a refresh token for a new access token. Access to
the token endpoint is secured and requires client credentials to be provided on
requests.

JWK endpoint
The endpoint used to advertise an OpenID Connect provider's public certificate
for use in asymmetric signing algorithms.

 OpenID Connect endpoints

OpenID Connect endpoints define interfaces through which applications may

communicate with an OpenID Connect Provider (OP) or Relying Party (RP)
instance running on an appliance.
All URLs use the following base path:

© 2019 IBM Corporation 157

Enterprise IAM Training Module

https://<ReverseProxy Hostname>:<Port>/<Connection to Application Server>/

URLs for each of the endpoints of an OP or an RP will change depending on the

identifier for the federation the OP or RP is a partner to, and a partner identifier.
After configuring an OP federation, a url_base_path property will be advertised
in the configuration data for that federation. This path is the URL path preceding
the “/authorize”, “/token”, and “/introspect” pages. Using the URL base path to
build the URL would include the above example with the url_base_path
appended, and then the value of authorize/token/introspect added depending on
what kind of request is being made.

For example:
url_base_path = “/oidc/endpoint/amapp-runtime-myfederation/”

Relying Party SSO initiation endpoint

Requests to the SSO initiation endpoint are used to initiate a sign on from another
identity provider or OpenID Connect Provider.

Use the following URL:

https://<ReverseProxy hostname:Port/<application integration

point>/sps/oidc/client/<FederationName>

Requests to this endpoint should use the HTTP method GET or POST and
include the following query string parameters:

© 2019 IBM Corporation 158

Enterprise IAM Training Module

Selecting Federation standards

Functional Comparison of federation

protocols
 OAuth2 vs OpenID Connect
Before explaining the differences between OpenID Connect and OAuth2, we
start by explaining what OAuth2 and OpenID Connect have in common.
First, they both focus on security, identity, and authorization. They are both
open-web standards that use REST for communication. In both solutions, the
user can actively manage the rights that are given to the service provider.

© 2019 IBM Corporation 159

Enterprise IAM Training Module

Figure shows an example of how Facebook has implemented rights

management.

The big difference between OAuth2 and OpenID Connect is that OAuth2 offers
authorization only and OpenID Connect also offers authentication. For this
reason, OpenID connect also has additional authentication tokens that are called
"ID tokens".

However, OpenID Connect has no flow to share data between two applications.
With OAuth2, any information a user holds on any website can be shared with
another website. A user could, for example, copy his GMail address book into
Facebook by allowing Facebook to read his GMail account. Without OAuth2, the
only way to solve this is to give Facebook the GMail user name and password.
This is clearly not a smart thing to do, and this is exactly what OAuth2 is set up
to prevent.

On the other hand, OpenID Connect has an additional flow called Hybrid Flow
that is another user-interactive flow. As in Implicit Flow, tokens are returned to
the client, but there is no redirect URI. The client has to handle the
communication with the service as in the Code Authorization Flow.

 OpenID Connect vs SAML

Both OpenID Connect and SAML offer authentication and authorization, so both
can be used for the same purposes with only slightly different technical means.
But why pick one over the other?

© 2019 IBM Corporation 160

Enterprise IAM Training Module

OpenID Connect is a recently published protocol that uses new techniques, like
JSON and REST (vs XML and SOAP for SAML). It was designed to support web
apps, native apps and mobile applications, whereas SAML was designed only for
web-based apps. Because XML requires a heavy library to parse content, JSON
and REST are easier to implement in the implementation languages commonly
used on the web.
According to SURF, there is also a difference in the focus of the protocols:
OpenID Connect is user-centric, whereas SAML 2.0 is organization-centric. User
consent is an essential part of the OpenID Connect protocol, but it is also possible
with SAML. Some analysts point out that the pre-defined set of user attributes
offered by OpenID Connect is more geared toward consumer-to-web service
provider scenarios than toward enterprise scenarios (where one would expect
roles, entitlements, etc.).

In SAML, security is implemented at the message level and uses XML-based

technologies for signing and encrypting messages. Additionally, transport-level
security can be implemented with TLS, which is a smart thing to do (defence in
depth).

OpenID Connect has it the other way around: transport-level security is

mandatory, and message-level security is optional. The IdP will typically demand
that clients implement additional message-level security in user-not-present
situations, for instance (for browser-based clients the user is always present).
Message-level security is made possible through encryption and by signing JWT
objects.

While SAML uses a static trust-configuration setup through meta-data, OpenID

Connect has some dynamic aspects. OpenID Connect allows so-called "Dynamic
Client Registration", in which new clients are provided with access tokens and
are redirected to a client registration endpoint to be registered with an IdP and to
receive further client credentials.

To conclude, both protocols solve the same problem, but in a different way.
Because OpenID uses modern techniques, we expect that the market share of
OpenID Connect will grow and take over the leading position of SAML.

© 2019 IBM Corporation 161

Enterprise IAM Training Module

 OpenID Connect vs LDAP

Both OpenID Connect and LDAP offer authentication and authorization; the
main difference is that LDAP is an enterprise-oriented solution whereas OpenID
Connect is more web-oriented. LDAP is used for sharing of information about
users, systems, networks, and applications in the (internal) network. With LDAP,
user data is stored in a directory that contains user accounts. OpenID Connect
does not talk directly to a directory or database, but requires a separate service
that authenticates a user, which can be an LDAP implementation.
According to the literature, it seems that LDAP is used mainly to search for
specific data (like users) and that SSO is an additional feature.

OpenID uses the open standards REST and JSON, whereas LDAP uses XML.
This is not unusual because LDAP was released in 1993 when Javascript (1995)
the basics of JSON? and the REST protocol (2000) did not even exist.

In short, LDAP may be used when an Enterprise SSO solution is required. If you
are looking for a web SSO solution, use OpenID Connect. It is built with the web
in mind, it is a smaller, and, in our opinion, it is easier to understand. OpenId
Connect also uses the new standards in web programming and is therefore easier
and faster to implement for web solutions.

 OpenID Connect vs CAS

Unlike CAS , OpenID Connect is a new standard that is adopted by many
leading companies. Because OpenID Connect is implemented by leading
companies, it is more likely that well-trained security experts have looked into
the protocol.

CAS should be used for SSO authentication of local users. They do not
support federated authentication, which is possible with SAML and OpenID
Connect.

© 2019 IBM Corporation 162

Enterprise IAM Training Module

X = Does not offer this property

V = Offers this property
O = Optional
? = We do not know the value for this property of this protocol.
* Authentication is not supposed to be handled by OAuth2, but many
developers do use
the protocol for this purpose on the bases that authorization implies
authentication.

Based on this comparison, we know that OAuth2 and CAS do not meet the
requirement of offering authentication and authorization.
Thus, three potential solutions remain: OpenID Connect, SAML 2, and LDAP.
Because OAuth2 is the basis of OpenID Connect, we decided to continue looking
into this protocol.

© 2019 IBM Corporation 163

Enterprise IAM Training Module

UNIT 7: MULTI FACTOR AUTHENTICATION (MFA)

© 2019 IBM Corporation 164

Enterprise IAM Training Module

CHAPTER 12: Origin Of MFA

Originally, just one factor was utilized to authenticate the transmitting entity. By
that time, Single-factor Authentication (SFA) was mostly adopted by the
community due to its simplicity and user friendliness. Evidently, this is the
weakest level of authentication. By sharing the password, one can compromise
the user account, i.e. unauthorized user can also attempt an access by utilizing the
dictionary attack or rainbow table.

Commonly, the minimum password complexity requirement is to be considered

while utilizing this type of authentication. Next, it was realized that authentication
with just a single factor is not reliable to provide adequate protection due to the
number of recent security threads. As an intuitive step, Two-factor
Authentication (2FA) was proposed coupling the representative data
(username/password combination) with the factor of personal ownership, such
as a mobile phone. Generally, the authentication evolution is shown below
Figure. Almost immediately, Multi-factor Authentication (MFA) was proposed
providing higher level of safety to facilitate continuous protection of computing
devices and other critical online services from unauthorized access. This offered
an elevated level of security as user was required to present the evidence of the
identity itself, which belong to two or more different factors.

© 2019 IBM Corporation 165

Enterprise IAM Training Module

Introduction
Multi-factor authentication is defined as ‘a method of authentication that uses
two or more authentication factors to authenticate a single claimant to a single
authentication verifier’.

The authentication factors that make up a multi-factor authentication request

must come from two or more of the following:

1. Something you know, such as a password or passphrase. This method

involves verification of information that a user provides, such as a
password/passphrase, PIN, or the answers to secret questions (challenge-
response).

2. Something you have, such as a token device or smartcard. This method

involves verification of a specific item a user has in their possession, such as
a physical or logical security token, a one-time password (OTP) token, a key
fob, an employee access card, or a phone’s SIM card. For mobile
authentication, a smartphone often provides the possession factor in
conjunction with an OTP app or a cryptographic material (i.e., certificate or a
key) residing on the device.

3. Something you are, such as a biometric. This method involves verification of

characteristics inherent to the individual, such as via retina scans, iris scans,
fingerprint scans, finger vein scans, facial recognition, voice recognition, hand
geometry, and even earlobe geometry.

The claimant being authenticated may be a person, device, service, application or

any other security principal that can be authenticated within the system.

An authentication verifier is an entry point to a confined sub-system where a

single technical authentication policy is enforced. Multi-factor authentication
often involves the use of passphrases in addition to one or more of the following
multi-factor authentication methods:

 Universal 2nd Factor (U2F) security keys

 physical one-time PIN (OTP) tokens
 biometrics
 smartcards
 mobile apps
 Short Message Service (SMS) messages, emails or voice calls
 software certificates.

© 2019 IBM Corporation 166

Enterprise IAM Training Module

Multi-factor authentication versus multi-step

authentication
A common authentication approach often confused with multi-factor
authentication is multi-step authentication. Multi-step authentication is an
architectural approach to accessing resources sequentially through multiple
authentication verifiers. Each authentication verifier grants access to increasingly
privileged areas of the system until access to the desired resources is achieved.
Authentication verifiers may be single-factor or multi-factor in nature.

While multi-step authentication may significantly improve the security of a

system, it is easier for an adversary to bypass than multi-factor authentication as
there is no single point within the system that uses two or more authentication
factors to authenticate a single claimant to a single authentication verifier. As a
result, an adversary can incrementally compromise a system, gaining ever
increasing access while never having to overcome the requirement for multi-
factor authentication. For this reason, the ACSC does not recognise multi-step
authentication as being a suitable substitute for multi-factor authentication.

Consider a remote access solution. In this scenario, a computer has an Internet

Protocol Security (IPsec) certificate that authenticates the computer to the VPN
concentrator, a user has a passphrase that authenticates them to the VPN
concentrator and then a passphrase that authenticates them to the Active Directory
(AD) domain.

This scenario demonstrates multi-step authentication; however, there is no multi-

factor authentication implemented in this scenario. When authenticating to the
VPN concentrator, the user and computer are considered separate claimants,
therefore the computer's IPsec certificate and the user's passphrase are not a form
of multi-factor authentication. Furthermore, the user authenticates separately to
the VPN concentrator and to the AD domain. These authentications take place on
different authentication verifiers and fail to use different types of authentication
factors; therefore, this approach is also not multi-factor authentication.

© 2019 IBM Corporation 167

Enterprise IAM Training Module

The risk associated with this scenario is that an adversary may be able to
compromise the computer’s IPsec certificate at one point in time, compromise the
passphrase the user uses to authenticate to the VPN concentrator at another point
in time and, finally, compromise the user’s AD credentials at yet another point in
time. In this way the adversary is able to increase their access over time, which
increases the level of risk associated with this approach.

Consider a second remote access solution. In this scenario, the user is

authenticated to the VPN concentrator using a passphrase and one-time PIN from
a physical token. All other authentication steps are the same as in the previous
scenario.

This scenario demonstrates a relatively secure remote authentication architecture

with a multi-factor authentication method used to authenticate the user to the VPN
concentrator. In this case, the computer is authenticated with single-factor
authentication in the form of the computer’s IPsec certificate. The multi-factor
authentication takes place on entry into the remote access environment (using the
user’s passphrase and one-time PIN), which verifies access through to the
corporate environment, which remains protected by single-factor authentication
in the form of the user’s passphrase.

© 2019 IBM Corporation 168

Enterprise IAM Training Module

Multi-factor authentication methods

 U2F security keys

This multi-factor authentication method uses a physical token or card (referred to

as either a U2F security key or U2F authenticator) as a second factor. Software
on the user’s device prompts the user to either press a button on the U2F security
key or tap it using Near Field Communication (NFC). In doing so, the U2F
security key uses public key cryptography to verify the user’s identity by signing
a challenge-response request from a service which had been passed through via a
web browser or mobile app. The service then verifies that the response is signed
by the valid and correct private key for that service, and grants or denies access
to resources.

 Physical one-time PIN tokens

This multi-factor authentication method uses a physical token that displays a

time-limited one-time PIN on its screen as a second factor. Alternatively, the user
may be required to press a button on a physical token, which is connected to their
device, to submit the one-time PIN on their behalf. The time on both the physical
token and the authentication service are synchronised and the authentication
service knows what one-time PIN should be used by all physical tokens that it
services at a particular time. When the user authenticates with a passphrase and
one-time PIN, the authentication service verifies that all details are correct for
that user and grants or denies access to resources.

© 2019 IBM Corporation 169

Enterprise IAM Training Module

 Biometrics

This multi-factor authentication method uses biometrics, such as a fingerprint or

iris scan, as a second factor. When the user enrols they provide a scan of the
appropriate biometric as a reference point for the authentication service to
compare to. When the user authenticates they provide a passphrase along with
their biometric data, the authentication service verifies both the passphrase and
the biometric data with those provided at enrolment, and grants or denies access
to resources. It should be noted though, that for every biometric mechanism, due
to the wide range of differences between individuals, some of the potential users
will not be able to successfully enroll.

There are, however, potential security vulnerabilities in this multi-factor

authentication method caused by the fact that biometric characteristics are not
secrets (especially if the biometric reader converts biometric data into a hashed
form), biometric matching is probabilistic rather than deterministic, and there is
a reliance on the biometric capture software installed on the user’s device. If an
adversary compromises the user’s device and gains elevated privileges, then it is
possible for the adversary to use the services provided by the biometric capture
software to intercept and replay legitimate authentication requests or initiate
fraudulent authentication requests on the user’s behalf – within the limitations of
any anti-replay measures. Furthermore, the effectiveness of biometrics is reliant
on the quality of the biometric readers and capture software to ensure that false
negatives (denying access when it should be allowed) and, more importantly,
false positives (granting access when it should have been denied) provide an
appropriate trade-off.

 Smartcards

This multi-factor authentication method uses a private key stored on a smartcard

as a second factor. Software on the user’s device prompts the user to unlock the
smartcard by entering a PIN or password. When the smartcard is successfully
unlocked, the software on the device verifies the user’s identity by signing an
authentication request with the user’s private key. The authentication service then
verifies that the authentication request is signed by the valid and correct private
key, and grants or denies access to resources.

Like biometrics, this multi-factor authentication method has a potential security

vulnerability due to the software involved in interacting with the smartcard. If the
user’s device is compromised and an adversary gains elevated privileges, they
can potentially intercept and replay legitimate authentication requests or initiate

© 2019 IBM Corporation 170

Enterprise IAM Training Module

fraudulent authentication requests on the user’s behalf – within the limitations of

any anti-replay measures.

 Mobile apps

This multi-factor authentication method uses a time-limited one-time PIN or

password provided via a mobile app as a second factor. When the user enrols they
either scan a QR code or provide a phone number or an email address so that a
one-time PIN or password can be provided to them to register the mobile app.
During the logon process the user requests the mobile app to provide them with
a one-time PIN or password in order to complete the authentication process. The
user then provides this information to the authentication service, which verifies
that all details are correct for that user and grants or denies access to resources.

The advantage of this multi-factor authentication method is that it uses a second

factor that the user already has and therefore minimizes the cost to the system
owner; however, there are also a number of disadvantages, namely:

 use of devices for web browsing or reading emails may mean that the
device running the mobile app may no longer be secure
 many devices are not secure, and a device can be compromised by
motivated and competent adversaries, particularly when travelling
overseas.

 SMS messages, emails or voice calls

This multi-factor authentication method uses a time-limited one-time PIN or

password provided via an SMS message, email or voice call to a device as a
second factor. When the user enrols they provide a phone number or an email
address so that a one-time PIN or password can be provided to them to register.
During the logon process the user requests that the authentication service provide
them with a one-time PIN or password in order to complete the authentication
process. The user then provides this information to the authentication service,
which verifies that all details are correct for that user and grants or denies access
to resources.

The advantage of this multi-factor authentication method is that it uses a second

factor that the user already has and therefore minimises the cost to the system
owner. however, there are also a number of disadvantages, namely:

 depending on the user's location, telecommunication networks may have

degraded service or no service at all, which may affect the availability to
receive a one-time PIN or password

© 2019 IBM Corporation 171

Enterprise IAM Training Module

 use of devices for web browsing or reading emails may mean that an SMS
message, email or voice call containing the one-time PIN or password may
no longer be secure, particularly when SMS messages are delivered via
VoIP or internet messaging platforms
 many devices are not secure, and a device can be compromised by
motivated and competent adversaries, particularly when travelling
overseas
 telecommunication networks do not provide end-to-end security and an
SMS message, email or voice call may be intercepted by motivated and
competent adversaries, particularly when travelling overseas.

 Software certificates

This multi-factor authentication method uses a software certificate stored on a

device as a second factor. When the user wishes to authenticate, the system
attempts to access the user’s software certificate, which is stored in a file, in the
registry or in the Trusted Platform Module (TPM) of their device. If successful,
the software installed on their device assists the user to verify their identity by
signing an authentication request with the user’s private key. The authentication
service then verifies that the authentication request is signed by the valid and
correct private key, and grants or denies access to resources.

The security vulnerability in this multi-factor authentication method is due to a

reliance on the software and the operating system installed on the user’s device.
If an adversary compromises the user’s device, then it is possible for the adversary
to use the services provided by the software in order to intercept and replay
legitimate authentication requests or initiate fraudulent authentication requests on
the user’s behalf – within the limitations of any anti-replay measures. By
compromising the user’s device, an adversary can gain access to both
authentication factors easily with a low likelihood of detection. There is also the
additional risk that if an adversary can gain elevated privileges, the user’s keys
and certificates can be stolen from their device and used by the adversary from
their own devices or infrastructure to enable prolonged and difficult to detect
remote access to a network. For this reason, it is recommended that organizations
only use software certificates for low risk transactions or systems.

© 2019 IBM Corporation 172

Enterprise IAM Training Module

Time-based one-time password (TOTP)

A time-based one-time password (TOTP) is a temporary passcode, generated by
an algorithm, for use in authenticating access to computer systems.

The algorithm that generates each password uses the current time of day as one
of its factors, ensuring that each password is unique. Time-based one-time
passwords are commonly used for two-factor authentication and have seen
growing adoption by cloud application providers. In two-factor authentication
scenarios, a user must enter a traditional, static password and a TOTP to gain
access.

There are various methods available for the user to receive a time-based one-
time password, including:

 hardware security tokens which display the password on a small screen;

 mobile apps, such as Google Authenticator;
 text messages sent from a centralized server.

Time-based one-time passwords provide additional security, because even if a

user's traditional password is stolen or compromised, an attacker cannot gain
access without the TOTP, which changes every 30 or 60 seconds. TOTP is an
approved standard of the Internet Engineering Task Force.

One-time password (OTP)

One Time Password (OTP) is a password system where passwords can only be
used once, and the user has to be authenticated with a new password key each
time. OTP has much stronger security because the user has to enter a newly
created password key even if his key or password is exposed. The OTP is
standardized by the IETF and standardized again by verification related
companies.
A lot of OTP solutions are secret and/or proprietary however some like Open
Authentication (OATH)-usually HMAC-SHA1 are open-source and widely used
and supported between OTP providers.
OATH uses an event based OTP algorithm (it can also support time based
however this isn’t wide spread) which usually uses a secret character sequence
(a.k.a. seed) only known to the two parties (being the user software/device and
the OTP server) and the request number and sometimes other data such as
customer unique seed, etc.. All this data is running via the algorithm (usually
HMAC-SHA1) to generate the OTP. RSA was one of the first companies to offer
an enterprise OTP solution suing various software platforms and other form

© 2019 IBM Corporation 173

Enterprise IAM Training Module

factors such as tokens. RSA uses a time-based algorithm to calculate the OTP and
as such requires the time to be synchronized between the client side and server-
side OTP components and has on the user side a time indicator, so the user can
time their password entry.
The major upside to time-based OTP is than an event-based token if someone got
an OTP the only time limit they have to using it is until you generated a new OTP
and used it. In a time based OTP, one would only have a pre-defined time limit
to use set OTP (e.g., 25 seconds) which would be more than enough at most
instances. Event based OTP‘s on the other hand do not require time
synchronization to take place and does not require the user to wait for a password
to expire before entering it, etc...

Synchronization techniques
 Challenge-Response type OTP
The OTP system generator passes the user’s secret pass-phrase, along with a seed
received from the server as part of the challenge, through multiple iterations of a
secure hash function to produce a one-time password. After each successful
authentication, the number of secure hash function iterations is reduced by one.
Thus, a unique sequence of passwords is generated. The server verifies the one-
time password received from the generator by computing the secure hash function
once and comparing the result with the previously accepted one-time password.
 Time-synchronized type OTP
The time-synchronized one-time passwords are usually related to physical
hardware tokens (e.g., each user is given a personal token that generates a one-
time password). Inside the token is an accurate clock that has been synchronized
with the clock on the authentication server. On these OTP system, time is an
important part of the password algorithm since the generation of new passwords
is based on the current time rather than the previous password or a secret key.
 Event-synchronized type OTP
Each time you ask an event-based token for a new password, it increments the
internal counter value by one. On the server, each time you successfully
authenticate, the server also increments its counter value by one. In this way the
token’s and the server’s counter values stay synchronized in lock step and always
will generate the same one-time password. Event based tokens can get out of sync
if the token is asked to generate a bunch of one-time passwords that are never
actually used in authentication attempts. Then the token’s counter value is
increased while the server, oblivious, never increments his. Finally, a token-
generated one-time password is used for an authentication attempt, but it fails
because the server doesn’t recognize it.

© 2019 IBM Corporation 174

Enterprise IAM Training Module

 Time-Event synchronized type OTP

In both event-based tokens and time-based tokens it is possible for the server to
auto-correct for synchronization problems, within certain limits. For event-based
tokens, the server always knows a lower bound on the current counter value (i.e.,
the counter value used in the previous successful authentication attempt) but not
an upper bound. Therefore, if an unrecognized one-time password is seen, the
server can try several counter values beyond its expected counter value to see if
any of them match. If one happens to work, then the server knows that the
intervening counter values have been ―lost and it should skip over them. For
time based tokens, a similar strategy of trying out a few time intervals in the past
and the future works to auto-synchronize with clock drift. Of course, regular use
of the token is necessary to keep the drift within the recognized range.

Types of OTP-token Authentication

Since OTP does the authentication process by the OTP generating device
(hereafter token) that users have, and the password generated by this, it provides
double authentication process and stronger security than the static type that
provides a single process. OTP is divided into Asynchronous type and
Synchronous type depending on whether there is a synchronization process, as
shown in Table.

ASYNCHRONOUS TYPE &SYNCHRONOUS TYPE

Asynchronous Pros Users actively input the set of
type values sent by OTP
authentication server -clear
responsibility when there is an
accident -mutual
authentication process
Cons Users should always input the
set of values -inconvenient to
use -when values are repeated,
it can be exposed to danger
Synchronous type Pros OTP token always generate
different password every few
minutes -convenient to use
Cons When there is time difference
between the token and the
authentication server, users
should manually set the time
again

© 2019 IBM Corporation 175

Enterprise IAM Training Module

 Benefits of a one-time password

The one-time password avoids common pitfalls that IT administrators and

security managers face with password security. They do not have to worry about
composition rules, known-bad and weak passwords, sharing of credentials or
reuse of the same password on multiple accounts and systems. Another advantage
of one-time passwords is that they become invalid in minutes, which prevents
attackers from obtaining the secret codes and reusing them.

HOTP vs TOTP: What's the Difference?

 HOTP: Event-based One-Time Password

Event-based OTP (also called HOTP meaning HMAC-based One-Time

Password) is the original One-Time Password algorithm and relies on two pieces
of information. The first is the secret key, called the "seed", which is known only
by the token and the server that validates submitted OTP codes. The second piece
of information is the moving factor which, in event-based OTP, is a counter. The
counter is stored in the token and on the server. The counter in the token
increments when the button on the token is pressed, while the counter on the
server is incremented only when an OTP is successfully validated.

To calculate an OTP the token feeds the counter into the HMAC algorithm
using the token seed as the key. HOTP uses the SHA-1 hash function in the
HMAC. This produces a 160-bit value which is then reduced down to the 6 (or
8) decimal digits displayed by the token.

 Several techniques that use OTP

 LinOTP: is acronym for Linux One Time Password that uses OTP to
increase the security of all types of logon processes.
 MOTP: is acronym for Mobil One Time Password which deals with
synchronization between client and server with period of time usually
3munities; several software downloaded on mobiles support this
technology.
 SMSOTP: SMS OTPs are used as an additional factor in a multi-factor
authentication system. Users are required to enter an OTP after logging in
with a user name and password.

© 2019 IBM Corporation 176

Enterprise IAM Training Module

 HOTP: is acronym for HMAC One Time Password algorithm based on an

increase in counter value. Both client and server have a counter value.
Server generates the password for using the counter. If both passwords
match, the server authenticates the user and updates the counter (increment/
decrement the counter).
 CROTP: is acronym for The OATH Challenge-Response algorithm based
on challenge from authentication server. While server sends random
challenge consists of 4 character defined as PIN, the user enters PIN value
then sends response to the server.
 TOTP: is acronym for Time One Time Password is used as an additional
factor in a two-factor authentication system. Users are required to enter
an OTP after logging in with a user name and password to generate OTP
in a period of time.

 TOTP: Time-based One-Time Password

Time-based OTP (TOTP for short), is based on HOTP but where the moving
factor is time instead of the counter. TOTP uses time in increments called the
timestep, which is usually 30 or 60 seconds. This means that each OTP is valid
for the duration of the timestep.

 Comparison

Both OTP schemes offer single-use codes, but the key difference is that in HOTP
a given OTP is valid until it is used, or until a subsequent OTP is used. In HOTP
there are a number of valid "next OTP" codes. This is because the button on the
token can be pressed, thus incrementing the counter on the token, without the
resulting OTP being submitted to the validating server. For this reason, HOTP
validating servers accept a range of OTPs. Specifically, they will accept an OTP
that is generated by a counter that is within a set number of increments from the
previous counter value stored on the server. This is range is referred to as the
validation window. If the token counter is outside of the range allowed by the
server, the validation fails, and the token must be re-synchronized.

So clearly in HOTP there is a trade-off to make. The larger the validation window
the less likely the chance of needing to re-sync the token with the server, which
is inconvenient for the user. Importantly though, the larger the window the greater
the chance of an adversary guessing one of the accepted OTPs through a brute-
force attack.

In contrast, in TOTP there is only one valid OTP at any given time - the one
generated from the current UNIX time.

© 2019 IBM Corporation 177

Enterprise IAM Training Module

 Choice

Choosing between HOTP and TOTP purely from a security perspective clearly
favours TOTP. Importantly, the validating server must be able to cope with
potential for time-drift with TOTP tokens in order to minimize any impact on
users.

© 2019 IBM Corporation 178

Enterprise IAM Training Module

UNIT 8: INTRODUCTION TO AUDITING & REPORTING

© 2019 IBM Corporation 179

Enterprise IAM Training Module

CHAPTER 13: Auditing & Reporting

Auditing
The term auditing has two different distinct meanings within the context of IT
security, so it’s important to recognize the differences.

First, auditing refers to the use of audit logs and monitoring tools to track activity.
For example, audit logs can record when any user accesses a file and document
exactly what the user did with the file and when.

Second, auditing also refers to an inspection or evaluation. Specifically, an audit

is an inspection or evaluation of a specific process or result to determine whether
an organization is following specific rules or guidelines.

A complete audit trail of system activities is a necessity to assure that the system
is functioning properly, even if there are no apparent signs of system failure or
unauthorized access. The system should provide a complete record of all access
control activity, like authentication requests, data access attempts and changes to
privilege levels. The record should contain both successful and failed activities.

Audit reports include those that describe:

• Lists of identities and their associated access.

• The person approving access for specific information.

• The management of group and supervisory accounts.

• The number of users accessing a particular application or information

resource.

Additionally, the processes and supporting systems should be able to provide

reports that detail access approvals and reviews, because these are the areas of
frequent weakness that are uncovered when auditing an organization’s identity
and access management process.

© 2019 IBM Corporation 180

Enterprise IAM Training Module

 Auditing to Assess Effectiveness

A proper auditing makes it possible to view an integrated life cycle of each

identity. Auditing means that it is possible to run different reports from the IAM
system. The reports supplement the data available in log files. The IAM system
should provide full reports to auditing users and interest groups, e.g. data
protection officers and supervisors. The reports should be provided and delivered
automatically in different formats. Viewing the reports should be possible by
conditions and time periods the user has chosen. It should be possible to see
precise rights, restrictions, roles and information an identity has had on each
information system on a given date.

The IAM system should also provide other versatile reports. There should be
available lists of all the users with different prerequisites, such as users with a
specific work role or users of a specific target system. There should be listings of
added, removed and inactive users, listings of unprocessed user right requests,
listings of rejected user rights and separate, selected listings for supervisors and
data protection officers. For the IAM administrator the system should also
provide provisioning reports of failed and succeeded cases.

Log files are typically created and maintained in each target system separately. It
is necessary to review the logs periodically. System logs are high in volume,
which makes it difficult to isolate and identify a given event for identification and
investigation. Some IAM systems have an option to provide a centralized log
storage with intelligent log analyzing tools.

Apart from centralized logging, every critical target systems’ user rights
management action have to generate a complete user-specific log and change
history. Also, using log files have to be logged. All the logged information has to
be easily provided in different kinds of auditing and analysing situations. Log
files have to be available for indisputable user rights auditing. No one can have a
right to change or remove log files. Typically, a log can include user IDs, dates
and times of log-on and log-off, system identities (IP-addresses, host names etc.)
and both successful and rejected authentication and access attempts.

The changes made to the IAM system have to generate a log file that is available
for administrators. Also, user actions have to be logged real-time. The archiving
obligation for log files is the time the person is working for the organization + 12
years. Log files need to be archived 12 years after their emergence. After the time
limit, the log files have to be erased appropriately.

According to ISO 27799, patient information systems should create a secure audit
record each time a user accesses, creates, updates or archives patient data. The

© 2019 IBM Corporation 181

Enterprise IAM Training Module

audit log should uniquely identify the user, the data subject, the function
performed by the user and note the date and time when the function was
performed.

 Inspection Audits

Secure IT environments rely heavily on auditing as a detective security control

to discover and correct vulnerabilities. Two important audits within the context
of access control are access review audits and user entitlement audits.

It’s important to clearly define and adhere to the frequency of audit reviews.
Organizations typically determine the frequency of a security audit or security
review based on risk. Personnel evaluate vulnerabilities and threats against the
organization’s valuable assets to determine the overall level of risk. This helps
the organization justify the expense of an audit and determine how frequently
they want to have an audit.

Audits cost time and money, and the frequency of an audit is based on the
associated risk. For example, potential misuse or compromise of privileged
accounts represents a much greater risk than misuse or compromise of regular
user accounts. With this in mind, security personnel would perform user
entitlement audits for privileged accounts much more often than user entitlement
audits of regular user accounts.

As with many other aspects of deploying and maintaining security, security audits
are often viewed as key elements of due care. If senior management fails to
enforce compliance with regular security reviews, then stakeholders will hold
them accountable and liable for any asset losses that occur because of security
breaches or policy violations. When audits aren’t performed, it creates the
perception that management is not exercising due care.

 Access Review Audits

Many organizations perform periodic access reviews and audits to ensure that
object access and account management practices support the security policy.
These audits verify that users do not have excessive privileges and that accounts
are managed appropriately. They ensure that secure processes and procedures are
in place, that personnel are following them, and that these processes and
procedures are working as expected. For example, access to highly valuable data
should be restricted to only the users who need it. An access review audit will
verify that data has been classified and that data classifications are clear to the
users. Additionally, it will ensure that anyone who has the authority to grant
access to data understands what makes a user eligible for the access. For example,

© 2019 IBM Corporation 182

Enterprise IAM Training Module

if a help desk professional can grant access to highly classified data, the help desk
professional needs to know what makes a user eligible for that level of access.

When examining account management practices, an access review audit will

ensure that accounts are disabled and deleted in accordance with best practices
and security policies. For example, accounts should be disabled as soon as
possible if an employee is terminated. A typical termination procedure policy
often includes the following elements:

• At least one witness is present during the exit interview.

• Account access is disabled during the interview.
• Employee identification badges and other physical credentials such as
smartcards are collected during or immediately after the interview.
• The employee is escorted off the premises immediately after the interview.

The access review verifies that a policy exists and verifies personnel are following
it. When terminated employees have continued access to the network after an exit
interview, they can easily cause damage. For example, an administrator can create
a separate administrator account and use it to access the network even if the
administrator’s original account is disabled.

 User Entitlement Audits

User entitlement refers to the privileges granted to users. Users need rights and
permissions (privileges) to perform their job, but they only need a limited number
of privileges. In the context of user entitlement, the principle of least privilege
ensures that users have only the privileges they need to perform their job and no
more.

The Role of Internal Auditors

Because IAM touches every part of the organization — from accessing a facility’s
front door to retrieving corporate banking and financial information — chief audit
executives (CAEs) may wonder how organizations can control access more
effectively to gain a better understanding of the magnitude of IAM. For instance,
to effectively control access, managers must first know the physical and logical
entry points through which access can be obtained. Poor or loosely controlled
IAM processes may lead to organizational regulatory noncompliance and an
inability to determine whether company data is being misused.

As a result, the CAE should be involved in development of the organization’s

IAM strategy. The CAE brings a unique perspective on how IAM processes can

© 2019 IBM Corporation 183

Enterprise IAM Training Module

increase the effectiveness of access controls, while also providing greater

visibility for auditors into the operation of these controls.

The purpose of this GTAG is to provide insight into what IAM means to an
organization and to suggest internal audit areas for investigation. In addition to
involvement in strategy development, the CAE has a responsibility to ask
business and IT management what IAM processes are currently in place and how
they are being administered. While this document is not to be used as the
definitive resource for IAM, it can assist CAEs and other internal auditors in
understanding, analysing, and monitoring their organization’s IAM processes.

Reporting Audit Results

The actual formats used by an organization to produce reports from audit trails
will vary greatly. However, reports should address a few basic or central
concepts:
• The purpose of the audit
• The scope of the audit
• The results discovered or revealed by the audit
In addition to these basic concepts, audit reports often include many details
specific to the environment, such as time, date, and a list of the audited systems.
They can also include a wide range of content that focuses on
• Problems, events, and conditions
• Standards, criteria, and baselines
• Causes, reasons, impact, and effect
• Recommended solutions and safeguards
Audit reports should have a structure or design that is clear, concise, and
objective. Although auditors will often include opinions or recommendations,
they should clearly identify them. The actual findings should be based on fact and
evidence gathered from audit trails and other sources during the audit.

Protecting Audit Results

Audit reports include sensitive information. They should be assigned a

classification label and only those people with sufficient privilege should have
access to audit reports. This includes high-level executives and security personnel

© 2019 IBM Corporation 184

Enterprise IAM Training Module

involved in the creation of the reports or responsible for the correction of items
mentioned in the reports.
Auditors sometimes create a separate audit report with limited data for other
personnel. This modified report provides only the details relevant to the target
audience. For example, senior management does not need to know all the minute
details of an audit report. Therefore, the audit report for senior management is
much more concise and offers more of an overview or summary of findings. An
audit report for a security administrator responsible for correction of the problems
should be very detailed and include all available information on the events it
covers.
On the other hand, the fact that an auditor is performing an audit is often very
public. This lets personnel know that senior management is actively taking steps
to maintain security.

Distributing Audit Reports

Once an audit report is completed, auditors submit it to its assigned recipients, as
defined in security policy documentation. It’s common to file a signed
confirmation of receipt. When an audit report contains information about serious
security violations or performance issues, personnel escalate it to higher levels of
management for review, notification, and assignment of a response to resolve the
issues.

Using External Auditors

Many organizations choose to conduct independent audits by hiring external
security auditors. Additionally, some laws and regulations require external audits.
External audits provide a level of objectivity that an internal audit cannot provide,
and they bring a fresh, outside perspective to internal policies, practices, and
procedures

© 2019 IBM Corporation 185

Enterprise IAM Training Module

UNIT 9: IDENTITY MANAGEMENT AND USER

PROVISONING

© 2019 IBM Corporation 186

Enterprise IAM Training Module

CHAPTER 13: Introduction to Identity Manager

Business Challenges
In order to effectively compete in today’s business environment, companies are
increasing the number of users (customers, employees, partners, and suppliers)
who are allowed to access information. As IT is challenged to do more with fewer
resources, managing user identities and their access to resources throughout the
identity lifecycle is even more difficult. Typical IT environments have many local
administrators using manual processes to implement user changes across multiple
systems and applications.

Consider this real-life example, an organization hire a new employee, now

organization need to issue him a corporate email address and login credentials on
all systems or applications which are related to his job. Various application or
system may relate to his job then IT administrator need to create his Identity (user
accounts) on all various applications manually. In similar manner you need to
manually delete his user accounts from all applications when he leaves the
company. Because there is a lag time between the HR department notifying the
various systems administrators, the various systems that the former employee had
accounts on (company intranet, extranet) are still active. This means that,
effectively, the former employee has access to sensitive company data. If this
employee has taken a position with a competitor while still having access to the
data, this leaves the former employer open to risk. So in real environment it is
more difficult to manage identity lifecycle.

As the world of on demand gains global acceptance, the traditional processes of

corporate user administration are no longer able to cope with the demands of
increased scale and scope expected from them. Identity management is a super-
set of older user provisioning systems that allows for the management of identity
and credential information for customers, partners, suppliers, automated
processes, corporate users, and others.

Solution
An integrated identity management solution can help get users, systems, and
applications online and productive fast, and maintain dynamic compliance to
increase the resiliency and security of the IT environment. Identity Manager is
primarily concerned with user lifecycle management. Identity Manager allows

© 2019 IBM Corporation 187

Enterprise IAM Training Module

your organization to manage authorization and privileges across your entire

system to increase security while decreasing the investment of time and money.
These solutions also help your team members be more productive by automating
tasks that used to be manual.

Identity management takes a lifecycle approach to the management of an identity

and access control from the beginning of the process. Specifically, identity
management handles the changes that occur during the lifetime of the user’s
account. This specifically means that it has the ability to integrate with pre-
existing information sources within the enterprise, such as directories and HR
systems. This gives a complete approach to identity management by leveraging
the existing information in data directories as well as integrating and utilizing the
HR system to access information about an employee (hirings, promotions,
transfers, termination of employment). In this manner, the identity is managed
through all stages of the process to ensure consistent handling of the identity. This
holistic lifecycle approach helps to minimize the risk to the enterprise because it
is ordered rather than fragmented.

Identity Manager
Identity management is a foundational security component to help ensure users
have the access they need, and that systems, data, and applications are
inaccessible to unauthorized users.

Customers implement an Identity management solution to address many business

requirements. The overall driving requirement is to provide a combination of
business processes and technologies, to manage and secure access to information
and resources within the organization.

To achieve this goal, the Identity management solution:

 Provides a method of granting users access to applications and systems that
are needed to perform their jobs.
 Has the capability to authorize proper access levels to resources based on
business policies.
 Has an audit trail to ensure proper operation.

A business organization must have efficient automated processes so that

employees:
 Can quickly obtain access to the correct application
 Can terminate access when an employee leaves

© 2019 IBM Corporation 188

Enterprise IAM Training Module

Identity Manager is an automated and policy-based solution that manages user

access across IT environments, helping to drive effective identity management
and governance across the enterprise. By using roles, accounts, and access
permissions, it helps automate the creation, modification, and termination of user
privileges throughout the entire user lifecycle. Identity Manager can help increase
user efficiency, reduce IT administration costs, enforce security, and manage
compliance.

The below are three main features of Identity Manager.

 Centralized user management

 Simplify user Management
 lifecycle management

Identity Manager centralizes the process of provisioning and accessing user

accounts on the operating systems and applications in your organization.

Identity manager simplify the user-management process. Identity Manager helps

companies automate the process of provisioning employees, contractors, and
business partners in one or more organizations with access rights to the
applications they need, whether in a closed enterprise environment or across a
virtual or extended enterprise.

Identity Manager provides lifecycle management of user accounts on remote

resources and policy-based provisioning to enable access to the managed
resources that an enterprise requires. Identity management is a comprehensive,
process-oriented, and policy-driven security approach that helps organizations
consolidate identity data and automate the deployment across the enterprise.

In additional, there is one more solution which is called as Access

Management solution. Access management manages access control for
various resources (systems and applications) within the enterprise. Access
Manager enables Web accessed resources, provides a way to authenticate
people, and provide a single sign-on (SSO) to access resources, once access
is granted.

Naturally, there is a complementing relationship between Identity and

Access management [IAM] (for example, an employee (user identity) has
a job function that requires access to certain resources. This access is
granted using a combination of linked accounts (user accounts) and
access controls on those resources). An integrated IAM solution provides
a combination of business processes and software technologies to manage

© 2019 IBM Corporation 189

Enterprise IAM Training Module

and secure access to proprietary information within an enterprise. Not

only is this good business practice, but several industry sectors are
regulated through security compliance requirements that are directly
aimed at their IAM solution. Security compliance requirements also play
a big role in certain customers looking to implement an integrated IAM
solution in their environment. For example, to meet compliance
requirements, customers want to ensure that identities are removed for
users who no longer have a business need for these identities. Customers
also want to restrict access to resources given to a user based on business
needs.

Identity and access management is the information security

discipline that allows users access to appropriate technology
resources, at the right time. It incorporates three major concepts:
identification, authentication and authorization. Together, these
three processes combine to ensure that specified users have the
access they need to do their jobs, while unauthorized users are kept
away from sensitive resources and information.

There are several common specific business requirements that

organizations can address through an Identity and Access [IAM]
solution:

 Provide a method of provisioning and de-provisioning of user

accounts across the organization, using the approval processes
established by the business. These requirements form the core of
identity lifecycle management use cases.
 Provide the capability to authorize proper access levels to
resources based on business policies. These capabilities form the
core of access management use cases.
 For Web accessed resources, such as Web applications, the
solution must provide a way to authenticate people, and only
require SSO to access granted resources. These requirements
improve the user experience for people accessing various
applications through the normal course of their daily activities
within the company.
 Finally, there must be an audit trail to:
 Ensure that proper identity management enforcement is in place
 Ensure that proper access control enforcement is in place
 Verify compliance with business policies

© 2019 IBM Corporation 190

Enterprise IAM Training Module

These requirements address the use cases around various

compliance initiatives. Overall, an IAM deployment addresses the
security requirements of a company through addressing the various
human aspects of information security.

Centralized User Management

Identity management is the process of managing the information for a user’s
interaction with an organization. As such, it is an important element of e-business
security and is vital to sustaining a healthy e-business. Without a solid identity
management solution, problems can occur when users—whether they are
employees, customers, business partners, or suppliers—require access to IT
resources. The benefits of centralizing the control over user management, while
still allowing for decentralized administration, affects two key business areas: the
cost of user management can be reduced, and security policies can be enforced.
The capabilities of an identity management solution can be classified into eight
levels. These capability levels can readily be arranged into a pyramid as shown
in below figure

the base of which is the most core required capability of the provisioning solution.
After the capabilities in the lowest level are addressed, you can move up to the

© 2019 IBM Corporation 191

Enterprise IAM Training Module

next level in the pyramid, which provides increasingly more powerful

capabilities. The ideal provisioning solution addresses all eight levels.
 Adapters to access controlled systems
 Password management
 Access rights accountability
 Access request approval and process automation
 Access request audit trails
 Distributed administration
 User administration policy automation
 Self-regulating user administration across organizations

a) Capabilities of an identity management as centralized user

management

Adapters to access controlled systems

In order to automate provisioning, the solution must communicate securely with

each target system being managed. If this adapter does not exist, then an
administrator must still make the required changes manually. The adapters are the
key mechanisms that translate the commands of the provisioning solution into the
proprietary language understood by the managed resources. Further, the richness
of the language used is important. Managed systems (SAP, for example) support
the definition of hundreds of parameters describing user access. The adapter must
support the needs of the managed system and the needs of the organization in
creating or changing accounts.

Communication between the provisioning solution and the managed system must
be bidirectional, secure, and bandwidth-efficient. Bidirectionality is critical to
capturing changes made directly to the managed system and reporting the change
to the provisioning solution for evaluation and response. The link must be
encrypted so that no one can listen in and steal authentication information such
as passwords. The link must also allow authentication of the source so that a new
command cannot be injected into the system by an imposter to create an
inappropriate account.

Last, because the managed resources are physically distributed across the
corporate wide area network (WAN) or the Internet, bandwidth efficiency must
be considered. These networks often have limited available capacity and are

© 2019 IBM Corporation 192

Enterprise IAM Training Module

expensive, requiring the provisioning solution to operate with as little overhead

as possible.

When we talk about managed systems, we have to look at two types of

repositories:
 User repositories
 Endpoint repositories

User repositories

User repositories contain data about people, and most companies

have many user repositories and will continue to add new ones due
to new and custom applications. These can be:

 Human Resources systems

 Applications
 LDAP and other directories
 Metadirectories

Endpoint repositories

Endpoint repositories contain data about privileges and accounts, and most
companies have a great variety of these repositories implemented throughout
their environment. Some of these are:

 Operating systems, such as Linux, Windows XP and AIX

 Network devices
 RACF
 Email Servers
 ERPs
 Databases

Therefore, it is important when considering centralized identity management

systems to be sure that the coverage of the system takes both types of repositories
into full account. These repositories hold a wealth of identity-related information.
Tying all of the information together rather than duplicating it is cost-effective
and eliminates mistakes.

© 2019 IBM Corporation 193

Enterprise IAM Training Module

Password management

Password management is the ability to control password quality and change

passwords throughout an environment. As companies deploy more and more
systems that contain access controls, the number of passwords required to be
remembered by each user increases. This increase poses a risk to the organization
as more users have a tendency to write down their passwords in order to keep
track of them. A costly side effect of this is the increased workload on the help
desk to reset forgotten passwords. (Research shows that approximately 30% of
total calls to the average help desk are for password-reset assistance.)

Password strength is also problematic for many organizations. Hackers possess

effective tools and techniques for cracking poorly constructed passwords.
Organizations desire to enforce stronger password formation rules across the
enterprise but must balance that desire against poor end-user experience and
increases in forgotten passwords.
Password management capabilities enable users to self-service their own
accounts. Users visit a Web-based system, authorize themselves, then may reset
or synchronize their passwords on all of their accounts. Further, the passwords
they select can be evaluated against rules on their formation to ensure uniform
conformance with organizational password policies. A user typically has multiple
accounts and passwords. The ability to synchronize passwords across platforms
and applications provides ease of use for the user. It can also improve the security
of the environment because each user does not have to remember multiple
passwords and is therefore less likely to write them down.

Key points to password management include:

 User self-service through the Web without logging onto the

network
 Challenge-response system to authenticate a user with a forgotten
password by using shared secrets
 Ability to implement password formation rules to enforce
password strength across the organization
 Ability to synchronize passwords for multiple systems to the
same value to reduce the number of different passwords to be
remembered by the user
 Delivery of password-change status (success or failure) to
requestor
 Ability to securely deliver passwords to users for new accounts

© 2019 IBM Corporation 194

Enterprise IAM Training Module

Access rights accountability

Tracking precisely who has access to what information across an organization is

a critical function of the provisioning solution. Not only does it allow control of
sensitive systems, but it should expose all accounts that have unapproved
authorizations or authorizations that are no longer necessary. These inappropriate
accounts pose one of the most serious threats to corporate security because they
are valid, active accounts so they cannot be detected as a traditional cyber-attack.
Access rights accountability provides configuration control over all accounts and
their specific authorities.

Orphan accounts are those active accounts found on many systems that cannot be
associated with a valid user. Improperly configured accounts are those associated
with valid users but granted improper authorities. These accounts may appear at
any time due to local administrators retaining rights to use local administrative
consoles. In enterprise-wide environments, these local consoles cannot be
disabled because of their multiple operational use. The key to the control of
improper and orphan accounts is, on a continuous basis, to associate every
account with a valid user and maintain a system-of-record detailing the approved
authorities of the account. When the user’s status with the organization changes,
their access rights must change too. If the account configuration changes, it must
be compared with an approved configuration and policy.

The ability to control orphan accounts requires that the provisioning system link
gather account information with authoritative information about the users
themselves. Authoritative user identity information is typically found in Human
Resources and various databases and directories containing information about
users in other businesses.

The ability to control improper accounts is much more difficult. It requires a

comparison of the desired with reality at the account-authority level. Simple
existence of an account does not expose its capabilities. Accounts in sophisticated
IT systems include hundreds of parameters defining the authorities; these are the
details that must be controlled. Accounts found to be orphaned or improperly
configured must be reported and corrected. Provisioning solutions should notify
the proper personnel to fix account settings.

 Access rights should include:

 Flexible mechanisms to connect to multiple data stores containing accurate
information about valid users
 Ability to load identity store information about a scheduled or event basis
 Ability to detect and respond to identity store changes in near-real time

© 2019 IBM Corporation 195

Enterprise IAM Training Module

 Ability to retrieve account information from target managed resources on

a scheduled basis, both in bulk or in filtered subsets to preserve network
bandwidth
 Ability to detect and report in near-real-time local administrator account
maintenance (creation, deletion, changes) made directly on local resources
 Ability to compare local administrator changes against a system-of-record
of account states to determine whether changes comply with approved
authorities and policies
 Ability to notify designated personnel of access-rights changes made
outside the provisioning solution
 Ability to compare account user IDs with valid users to identify accounts
without owners (orphans)
 Ability to automatically suspend or delete a detected orphan account
 Ability to automatically suspend or roll back a reconfigured account that
violates policy
 Ability to examine reports on orphan accounts
 Ability to readily view the accounts associated with a user or a resource
 Ability to assign discovered orphan accounts to a valid user

Access request approval and process automation

Access request approval and process automation is a key component in rapidly

and accurately changing user access rights. The approval processes are a
specialized form of workflow that determines, based on organizational policy, the
need to approve a requested change to access rights prior to its execution. Many
organizations still rely on paper and e-mail forwarded in many different paths
through the organization.

These approaches can be very slow. Requests can sit idle in an inbox or be
rejected because they are missing key information; consequently, the process
must begin again. A complete provisioning workflow solution automatically
routes requests to the proper approvers and escalates to alternates if action is not
taken on the request in a specified time. This workflow automation can turn a
process that typically takes a week into one that takes only minutes.

Some organizations also require that information about accounts or background

information be added to the request as it flows through the process. This
information may come from users involved in the process or it may be computed
or extracted from other systems.
A workflow automation tool should offer the following features:

© 2019 IBM Corporation 196

Enterprise IAM Training Module

 Web-based mechanism for requesting access to a system

 Automatic approval routing to the persons appropriate to the
system access requested and organizational structure
 Review and approval mechanisms that offer a zero-footprint
client
 Ability to use defined organizational information to
dynamically determine routing of approvals
 Ability to delegate approval authority to another person
 Ability to escalate a request to an alternative approver if the
allotted time elapses
 Ability for different personnel to view different levels of
information based on their job duties
 Ability to request information from approval participants to
define account-specific information during the process
 Ability to determine service instances where a physical account
should be created
 Ability for the system to change account information in the
managed resources of a specific organization Web-based
mechanism for requesting access to a system
 Automatic approval routing to the persons appropriate to the
system access requested and organizational structure
 Review and approval mechanisms that offer a zero-footprint
client
 Ability to use defined organizational information to
dynamically determine routing of approvals
 Ability to delegate approval authority to another person
 Ability to escalate a request to an alternative approver if the
allotted time elapses
 Ability for different personnel to view different levels of
information based on their job duties
 Ability to request information from approval participants to
define account-specific information during the process
 Ability to determine service instances where a physical account
should be created
 Ability for the system to change account information in the
managed resources of a specific organization
 Ability to request information from specific participants in the
workflow process

© 2019 IBM Corporation 197

Enterprise IAM Training Module

 Ability to request information from external functions,

applications, and data stores during the process
 Ability to easily create, design, and modify a workflow via a
graphical drag-and-drop interface

Access request audit trails

Traditionally, many organizations have treated audit logs as places to look for the
cause of a security breach after the fact. Increasingly, this is seen as an inadequate
use of the information available to an organization, which would be exhibiting
better due diligence by monitoring and reacting to logged breaches in as near to
real time as possible.
Centralized audit trails of access requests are an important aspect of supporting
independent audits of security practices and procedures in an organization.

These audit trails capture all aspects of the administration of access rights, from
initial access requests to changes in account details. Security audits are part of
every organization, whether they are conducted by internal security audit teams
or are external audits supporting formal bookkeeping. If recordkeeping is
incomplete, inaccurate, or stored in multiple locations, then these audits can
consume extensive time and human effort to conduct. Audits are frequently
disruptive to daily work efforts but are mandatory for the safe and secure
operation of the organization. Among other things, audit teams look for orphan
accounts or inappropriate access privileges that exist on important systems.
Audits may occur from once a quarter to as frequently as once a week, depending
on the organization.

An access request tool must include the following:

 Time-stamped records of every access change request, approval

or denial, justification, and change to a managed resource
 Time-stamped record of every administrative and policy-driven
change to access rights
 Time-stamped record of any encountered orphan accounts and
bypasses of administrative systems
 Convenient, flexible means of running reports that show audit
trails for users, systems, administrators, and time periods
 Audit trail that is maintained in a tamper-proof environment

© 2019 IBM Corporation 198

Enterprise IAM Training Module

Distributed administration

Distributed administration enables the administrative tasks involved with

provisioning, whether manual or automated, to be distributed securely among
various departments, organizations, or partners. This is important for two reasons:
accuracy and scale. It is wise to move the process of requesting and approving
access changes close to the people who know whether the resource is truly needed
by the individual.

Further, this distribution allows the workload to be balanced across a large

number of administrators rather than a single dedicated and centralized team. This
becomes fundamental in large organizations with multiple regional offices and
those with multiple business partners. Distribution should be performed all the
way down to the individual level when desired for self-service or self-enrollment.
To accomplish this, the system must support delegated administration and user
authentication. Delegated administration enables the responsibilities for using
and changing identity information to be delegated down through an organization
in a controlled manner.

Administrative tasks such as requesting access for a user, approving a change, or

defining local policies can be delegated to individuals throughout an organization
or its partner network. In this way, individuals that have the most accurate
knowledge of users needs can request or approve changes. Lower levels can
define local policies for access rights assignment within the guidelines created by
the organization. A key aspect of delegated administration is filtering the
information presented to an administrator on a need-to-know basis. Not only does
this make the system more usable to the administrator, but it also prevents
exposing information to personnel without a need to know. For example, external
business partners may be administering their own users into a common supplier
environment, but each business partner must remain invisible to the other
business partners.

Authentication to the system becomes critical at this point. As widely dispersed

individuals may make changes affecting access rights for others, it is critical that
system security be maintained. Frequently these interfaces are accessible to users
over the Internet, and that requires stronger authentication approaches. To meet
the need for stronger authentication, the solution should enable you to use your
own custom authentication mechanisms.

An administration tool should be able to:

© 2019 IBM Corporation 199

Enterprise IAM Training Module

 Define organizational structures based on the access-granting

authorities of an organization
 Delegate each administrative task with fine-grained control (for
example, approval authority, user creation, workflow definition)
Delegate administrative tasks to n-levels of depth
 Access all delegated capabilities over the Web with a zero-
footprint client
 Create private, filtered views of information about users and
available resources
 Incorporate Web access control products to include the
provisioning solution within the Web single sign-on
environment
 Incorporate custom user authentication approaches
commensurate with internal security policies
 Distribute provisioning components securely over WAN and
Internet environments, including crossing firewalls

User administration policy automation

User administration policy automation is the way to evaluate and enforce business
processes and rules for granting access. Role Based Access Control (RBAC) is a
method of granting access rights to users based on their assignment to a defined
role in the organization. Provisioning solutions that embody RBAC or other types
of rules that assign access rights to users based on certain conditions and user
characteristics are examples of user administration policy automation.

Automation is key to managing large numbers of users across disparate resources

and assigning, monitoring, and revoking user entitlements. The solution should
enable users to be defined as members of groups, including roles. Entitlements to
resources for these groups of users are defined in the security policies. Any
change to information about a user should be evaluated to determine whether it
alters the user’s membership to a group. If there is an effect, policies must be
reviewed and changes to entitlements must be put into place immediately.
Likewise, a change in the definition of the set of resources in a policy may also
trigger a change in entitlements.

The following elements should be included in user administration policy

automation:

© 2019 IBM Corporation 200

Enterprise IAM Training Module

 Ability to associate access-rights definition with a role within

the organization
 Ability to assign users to one or more roles
 Ability to implicitly define subsets of access to be unavailable
to a role
 Ability to explicitly assign users individual access rights
 Ability to dynamically and automatically change access rights
based on changes in user roles
 Ability to define implicit access rights available to users in a
role upon their request and approval
 Ability to use defined organizational information to
dynamically determine routing of approvals
 Ability to detect, evaluate, and respond to user authority
changes made directly to a managed resource
 Ability to report on roles, rights associated with roles, and users
associated with roles
 Ability to set designated times for changes in access rights or
policies
 Ability to create unique user IDs consistent with policies and
not in current use or previous use by the organization
 Ability to create user authorizations extending an existing
account
 Support for mandatory and optional entitlements (optional
entitlements are not automatically provisioned but may be
requested by a user in the group)
 Support for entitlement defaults and constraints (each
characteristic of an entitlement may be set to a default value, or
its range can be constrained, depending on the capabilities of
the entitlement to be granted)
 Ability to create a single account with multiple authorities
governed by different policies
 Ability to create user IDs using a set of consistent algorithms
defined by the organization

Self-regulating user administration across organizations

This ultimate level of the hierarchy is the ability to provision across multiple
organizations that each contain user groups and shared services. In this

© 2019 IBM Corporation 201

Enterprise IAM Training Module

environment, a change in a user’s status is automatically reflected in the access

rights inside the user’s organization and also in the outside services offered by
other organizations. As the provider of services to other organizations, user access
rights are automatically established based on your security policies and the
assertion of the users authenticity provided by the sponsor or a third party.

Key points of self-regulation include:

 Adherence to open standards

 Secure environment for transmitting access changes across the
Internet
 Protection of private user information through secure facilities
and sound processes
 Auditing access rights changes

 Benefits of Centralized User Management

The benefits of centralizing the control over user management, while still
allowing for decentralized administration, impacts these four business areas:

 The cost for user management can be significantly reduced.

 The amount of lost productivity while users wait for their
accounts to be created or to have their passwords reset can be
reduced.
 The risks of former employees having access to IT resources after
they separate from the business can be reduced.
 Security policies can be automatically enforced.

Let us take a closer look at the capabilities of centralized user management that
help realize these benefits.

i. Single Interface

Most large IT systems today are very complex. They consist of many
heterogeneous resources (operating systems, databases, Web application servers,
and so on). Individual user accounts exist in every database or user identity
repository. This means that an administrator must master a different interface on
each platform or resource type in order to manage the user identity repository.
This can be compounded by having specialized administrators focusing on

© 2019 IBM Corporation 202

Enterprise IAM Training Module

specific platforms. As the number and complexity of operations increases, the

result is often an increase in errors due to mistakes, time delays, or coordination
problems. This situation can be resolved through the centralization of identity
management and implementing role-based access control over the administration
of users. The centralization of the cross-environment management provides a
common interface for administration of user identity information, thus reducing
education and maintenance costs.

ii. Security Policy Enforcement

Identity management policies should be implemented as part of the standards and

procedures that are derived from the corporate security policy. Implementing
identity management policies that comply with the corporate security policy is a
key factor for a successful identity and credential management system. Central
control makes it possible to accommodate the business and security policies,
enabling security administrators to implement them in an efficient and
enforceable way.

Without centralized identity management and the use of life cycle rules, it is
almost impossible to enforce the corporate policy in a complex environment
dealing with a variety of target platforms, different system specifications, and
different administrators.
iii. Central Password Management

A user typically has multiple accounts and passwords. The ability to synchronize
passwords across platforms and applications provides ease of use for the user. It
can also improve the security of the environment because each user does not have
to remember multiple passwords and is therefore less likely to write them down.
Password strength policy can also be applied consistently across the enterprise.

Centralized password resets enable a user or administrator to reset one or all

account passwords from a central interface. This prevents lost productivity due to
the inability to access critical systems.

If a user’s password changes on the target resource directly, it may be useful to

update the central system in some environments if the password conforms to the
password policy or the password change is not allowed. If password
synchronization is used, other accounts can be synchronized to maintain
consistency.

© 2019 IBM Corporation 203

Enterprise IAM Training Module

iv. Delegation of Administration

As the number and type of users within the scope of an organization’s identity
management system changes, there will be increasing burdens on the system. Any
centralized system run by an IT department could face the burden of having to
manage users who are within other business units or even within other partner
organizations.

A key feature of any centralized system is therefore the ability to delegate the
day-to-day management of users to nominated leaders in other business units or
partner organizations.

The extreme example of delegation is delegation to an individual to manage some

features of his own identity. Examples of this would be changing location details
or the password self-reset.

v. User Self-Care

The most frequent reason users call the Help Desk is because they have forgotten
their password and they have locked their account while entering incorrect
passwords.

A robust identity management solution should provide users with an automated

tool for resetting their passwords based on them suppling correct responses to one
or more password challenge questions. Depending on the risks or the
classification of data on the server, this tool may send the new password to the
user’s e-mail address of record or present the user with a Web page to enter a new
password on the spot. The tool may also generate audit records and notifications
to IT or administrative personnel monitoring user self-care activities.

vi. Multiple Repository Support

When we talk about repository support, we must look at two types of

repositories:

 User repositories
 Endpoint repositories

User repositories

© 2019 IBM Corporation 204

Enterprise IAM Training Module

User repositories contain data about people, and most companies

have many user repositories and will continue to add new ones due
to new and custom applications. These can be:

 Human resources systems

 Applications
 Lightweight Directory Access Protocol (LDAP) and other
directories
 Meta directories

Endpoint repositories

Endpoint repositories contain data about privileges and accounts,

and most companies have a large variety of these repositories
implemented throughout their environment. Some of these are:

 Operating systems, such as Windows, AIX, or Linux

 E-mail systems such as Microsoft Exchange or Lotus Notes
 Enterprise Business Applications such as SAP, Oracle e-
Business Suite, or Siebel
 PKI and strong authentication solutions such as Entrust Authority
PKI server and RSA Authentication Manager
 Access Management solutions such as IBM Tivoli Access
Manager
 Network devices
 Mainframe user repositories such as RACF

vii. Workflow

Managing identity and account-related data involves a great deal of approvals and
dependencies. It takes a lot of time and effort to collect the necessary approvals
and check for all sorts of dependencies between related components.

To reduce these often manually conducted chores, the identity management

system should have an automated workflow capability that allows the system to:

 Gather approvals.
 Reduce administrative workload.
 Reduce turn-on time for new managed identities (account
generation, provisioning, and so on).
 Enforce completeness (do not do this task before everything else
is gathered).

© 2019 IBM Corporation 205

Enterprise IAM Training Module

The workflow component is a core value point within an identity management

solution.

viii. Centralized Auditing and Reporting

Traditionally, many organizations have treated audit logs, on each of the

corporate repositories, as places to look for the cause of a security breach after
the fact. Increasingly, this will be seen as an inadequate use of the information
available to an organization, which could be exhibiting better due diligence by
monitoring and reacting to logged breaches in as near real time as possible.

This requirement can only be met using centralized threat management tools, but
an important step towards meeting this goal should be part of an identity
management solution. Centralized auditing and logging of all additions, changes,
and deletions made on target repositories should be part of any centralized
identity management solution.

Simplify User Management

Identity manager simplify the user-management process. This section discusses
how to simplify the user-management process. This is largely achieved by having
a clear security policy, a well-organized implementation of the policy, and
sensible automation of the necessary processes in place.

a) Automation of Business Processes

All user accounts have a life cycle: They are created, modified, and deleted. It
can take a long time to get a new user online, as administrators are often forced
to manually obtain approvals, provision resources, and issue passwords.
Generally, with manual work, there is the opportunity for human error and
management by mood. Self-service interfaces enable users to perform some of
these operations on their own information, such as password resets and personal
information updates.

Automating some of the business processes related to the user account life cycle
reduces the chance for error and simplifies operations. Any centralized identity
management solution must provide the means to emulate the manual processes
involved in provisioning requests, an approvals workflow, and an audit trail, in
addition to the normal provisioning tools.

© 2019 IBM Corporation 206

Enterprise IAM Training Module

 Automated Default and Validation Policies

When creating user account information, some characteristics are common to all
or a sub-set of users based on the context. Default policies, which fill in data
entry fields with pre-set values automatically if not specified, reduce the effort
to fill out those values for every account.

A validation policy ensures that information about an object complies with the
rules defined for that object in the enterprise. An example would be that the field
user name must be eight characters and start with a letter. Another validation
policy may be that every user must have at least one active group membership.

 Single Access Control Models

Defining an access control model for each type of resource (e-business, enterprise
and previous platforms, and applications) in an organization can be complex and
costly. A single access control model provides a consistent way to grant users
access to resources and control what access the user has for that resource or across
a set of resources.

For some organizations, a role-based access control model is a good goal for
which to aim, as this reduces cost and improves the security of identity
management.

 Ubiquitous Management Interfaces

Work styles are changing and not everyone is office bound. Some people may
work in a different business location everyday, while others may work from a
home office. Identity management interfaces should be ubiquitous to adjust to our
work styles. It may be necessary for users in partner organizations or clients to
self-manage some of their account data. This means that the software on the
access device may not be under the control of the parent organization. Since a
Web browser interface is a pervasive interface available on most devices, it makes
sense that any identity management solution interface should be Web based.

In order for administrators to perform their work tasks anytime from anywhere
with a network connection, the identity management solution must be Web
enabled and capable of being integrated with Internet-facing access control
systems.

© 2019 IBM Corporation 207

Enterprise IAM Training Module

 Integration of other Management Architectures

Identity management is one part of an overall security architecture. Many

organizations are experiencing the benefits of automating and centralizing
security administration. Integrating identity management with access control
solutions and the threat management architecture can help an organization to
deploy applications faster and pursue new business initiatives, while enforcing
policy compliance across the organization. Security management also must
integrate with systems management so that potential threats to an organization
can be detected and resolved. For example, if the threat management detects an
unpatched application server, operating system, and so on, then the systems
management tools should automatically distribute the required patch.

Within the field of identity management, the use of automated provisioning may
trigger workflows. Distributing software or updating the configuration of the
user’s workstation by using the software distribution functionality found in the
system’s management architecture is one example of the type of functionality
required from an identity management solution.

Lifecycle Management

Identity management in general is the process of managing persons and their

accounts across all systems. The notion of lifecycle management introduces the
following concepts:

The person exists as a person entity to the identity management solution. From
the time of its creation to its deletion, it will change over time due to external
events such as transfers, promotions, leaves of absences, temporary assignments
or any other identity-related business process.

A person who uses an IT asset is considered an account from the identity

management perspective. The identity management solution sees this accounts as
an account entity owned by the person entity. The person entity changes will
affect its own accounts from the time they are created until the time they are
deleted. The person entitlements for each account owned are verified every time
the person or account entitlement definitions are changed. There may also be a
need to routinely verify that the account is compliant with security policies.

Life cycle management introduces the concept that a person’s use of an IT asset
from the time that the account is created until the time that the account is deleted

© 2019 IBM Corporation 208

Enterprise IAM Training Module

will change over time due to external events such as transfers, promotions, leaves
of absence, temporary assignments, or management assignments. There may also
be a need to routinely verify that the account is compliant with security policies
or external regulations. This effort is an on-going process and not a one-time
event. Control activities must therefore be implemented into the business
processes. Automation increases the effectiveness of these controls and business
processes.

Life cycle is a term used to describe how accounts for a person are created,
managed, and terminated based on certain events or a time-based paradigm.
A lifecycle is a term to describe how persons or accounts for a person are created,
managed, and terminated based on certain events or a time-based paradigm.

The below figure represents a closed-loop process where a person is registered to

use an IT asset, an account is created, and access provisioning occurs to give this
person account access to system resources.

Over time modifications occur where access to some resources is granted while
access to other resources may be revoked. The cycle ends when the person
separates from the business and the termination process removes access to
resources, suspends all accounts, and eventually deletes the accounts and the
person from the systems.

Provisioning solutions are the link between the classical central management
solution and the target resources. The capability to quickly negotiate provisioning
requirements that map to the identity models and processes of a business is crucial
when architecting a solution. The provisioning aspect garners much of the focus
and attention. User provisioning is where the process begins, and if provisioning

© 2019 IBM Corporation 209

Enterprise IAM Training Module

is sluggish or incomplete, users (employees, consultants, customers) develop

negative first impressions of the organization.

a) The Creation Cycle

The creation cycle includes the following:

Person creation
The person entity is created with the identity management solution. In most cases
person attributes, such as user name, e-mail address, phone number, and other
identity-related data, are imported from a person-authoritative system such as a
Human Resources (HR) system for employees, a contract system for business
partner persons, and other data sources for customer persons.

Account creation
The account entity is created on the managed platforms using attributes from the
person entity.

 The provisioning cycle

The provisioning cycle includes the following:

 Identifying the sponsor (for example, sales or HR), determining the nature
of the relationship (customer, internal employee), verifying the user’s
identity, and assigning a role or roles.
 Fulfillment, which entails gaining approval for the appropriate systems,
creating the user’s identity in the appropriate directories and repositories,
and granting access to those accounts.

 The modification cycle

During the maintenance phase of the lifecycle, administrators maintain the

following elements:

Person The person’s attributes, such as name, e-mail address, and phone number.

Identity The user’s credentials, such as user name and password, as well as
information about the user that may be based on person entity, including name,
e-mail address, and phone number.

© 2019 IBM Corporation 210

Enterprise IAM Training Module

Access rights The systems, accounts, and applications the user has access to and
the level of access.

Policy management Updating of access rights based on membership in a

particular group or department and consistent enforcement of corporate policies.

Privacy Enactment of regulations that require enterprises to secure the privacy of

certain types of information that are related to specific individuals.
Ideally, users should experience changes in access rights as the organization
changes and as their roles within the organization change. The maintenance phase
of the lifecycle offers significant opportunity for automation and efficiency gains.

 The termination cycle

Termination is the phase with which, from a security perspective, organizations

struggle the most. Auditors discovering hundreds or thousands of user accounts
that should have been disabled or deleted is common.

During the termination phase, organizations should verify that the relationship
between the user and the organization is, in fact, dissolving and disable access
accordingly. Often, accounts are disabled for a term and then deleted.
Unfortunately, although this sounds simple, it demands process rigor.
 Reconciliation
Reconciliation is the process of synchronizing the accounts and supporting data
in Identity Manager with the accounts and supporting data on a managed resource
or endpoint. It is the Identity Manager discovery process that queries the state of
the accounts on the managed endpoint. To determine an owner relationship,
reconciliation compares the account information with existing user data stored on
the Identity Manager server by first looking for the existing ownership within the
Identity Manager server and, secondly, applying adoption rules configured for the
reconciliation.

Reconciliation is run for the following reasons:

 Load access information into Identity Manager.

When a service is first integrated into Identity Manager for management of

the managed endpoint’s accounts, there must be an initial load of accounts
and accompanying data associated with the service. This is performed by an
initial reconciliation.

© 2019 IBM Corporation 211

Enterprise IAM Training Module

 Monitor accesses granted outside of Identity Manager administration.

Periodically, reconciliations must be run to monitor the state of accounts and

note whether they have changed and no longer meet the policies defined
within Identity Manager. Accounts that are not owned by people (orphan
accounts) are also monitored through this means.

Access Control Models of Identity Manager

Access control is basically identifying a person doing a specific job,
authenticating them by looking at their identification, then giving that person only
the key to the door or computer that they need access to and nothing more. In the
world of information security, one would look at this as granting an individual
permission to get onto a network via a user-name and password, allowing them
access to files, computers, or other hardware or software the person requires, and
ensuring they have the right level of permission (i.e. read only) to do their job.
So, how does one grant the right level of permission to an individual so that they
can perform their duties? This is where access control models come into the
picture.

Access control models have three flavours: Mandatory Access Control (MAC),
Role Based Access Control (RBAC), Discretionary Access Control (DAC).

This section looks at some of the access control models that are commonly
found or are planned for use with a centralized identity management solution.

a) Role-Based Access Control [RBAC] Model

Role-based access control, as its name suggests, is the granting of access

privileges to a user based upon the work that they do within an organization. This
allows an administrator to assign a user to single or multiple roles according to
the work she is doing. Each role enables access to specific resources.

© 2019 IBM Corporation 212

Enterprise IAM Training Module

RBAC examples

Some RBAC examples are:

A new customer Alex registers with an organization by completing a form

on a Web site. As a result of doing so, Alex may be awarded the role of
customer by the central user administration system that in turn populates
Alex's account to all customer-facing resources.

A new employee Betty, on starting with an organization, could be awarded

the role of basic user by the administrator and as a result, her account
information could be populated to the network access system and to an e-
mail system. Betty may not yet have interacted with any of the systems, so
in this case, the administrator must assign the accounts with a default
password and ensure that each system makes Betty change her password
upon first access.Betty, on starting with an organization, could be awarded
the role of basic user by the administrator and as a result, her account
information could be populated to the network access system and to an e-
mail system. Betty may not yet have interacted with any of the systems, so
in this case, the administrator must assign the accounts with a default
password and ensure that each system makes Betty change her password
upon first access.

A senior employee Charles would already have the basic user role from
the time when he joined the organization. His work now requires that
access be granted to applications that are not included within the basic user
role. If he now needs access to the accounts and invoicing systems, Charles
could be awarded the accounting role in addition to the basic user role.

A manager Dolly would already have the basic user role from the time
when she joined the organization and may also have other roles. As she has
been promoted to a management post, so her needs to access other systems
have increased. It may also be, however, that her needs to access some
systems, as a result of her previous post, are no longer appropriate in her
management role. Thus, if Dolly had basic user and accounting as her roles
before promotion, it may be that she is granted the manager role, but has
her accounting role rescinded. This would leave her with the basic user and
manager roles suitable for her post.

© 2019 IBM Corporation 213

Enterprise IAM Training Module

 Discretionary Access Control [DAC] Model

The DAC model is when the owner of a resource decides whether to allow a
specific person access to her resource. This system is common in distributed
environments that have evolved from smaller operations into larger ones. When
it is well managed, it can provide adequate access control, but it is very dependant
upon the resource owner understanding how to implement the security policies of
the organization, and of all the models it is most like to be subject to management
by mood. Ensuring that authorized people have access to the correct resource
requires a good system for the tracking of leavers, joiners, and job changes.
Tracking requests for change is often paper driven, error prone, and can be costly
to maintain and audit.
 Mandatory Access Control [MAC] Model

The MAC model is where the resources are grouped or marked according to a
sensitivity model. This model is most commonly found in military or government
environments. One example would be the markings of unclassified, restricted,
confidential, secret, and top secret. User privileges to view certain resources are
dependant upon that individual’s clearance level.

© 2019 IBM Corporation 214

Enterprise IAM Training Module

Corporate Regulatory Compliance Using

Identity Management
Identity Manager addresses corporate regulatory compliance in the following key
areas:

 Provisioning and the approval workflow process

 Audit trail tracking
 Enhanced compliance status
 Password policy and password compliance
 Account and access provisioning authorization and enforcement
 Recertification policy and process

© 2019 IBM Corporation 215

Enterprise IAM Training Module

 Reports

a) Provisioning and the approval workflow process

Identity Manager provides support for provisioning, for user accounts and for
access to various resources. Implemented within a suite of security products,
Identity Manager plays a key role to ensure that resources are provisioned only
to authorized persons. Identity Manager safeguards the accuracy and
completeness of information processing methods and granting authorized users
access to information and associated assets. Identity Manager provides an
integrated software solution for managing the provisioning of services,
applications, and controls to employees, business partners, suppliers, and others
associated with your organization across platforms, organizations, and
geographies. You can use its provisioning features to control the setup and
maintenance of user access to system and account creation on a managed
resource.

At its highest level, an identity management solution automates and centralizes

the process of provisioning resources. The solution includes operating systems
and applications, and people in, or affiliated with, an organization. Organizational
structure can be altered to accommodate the provisioning policies and procedures.
However, the organization tree used for provisioning resources does not
necessarily reflect the managerial structure of an organization. Administrators at
all levels can use standardized procedures for managing user credentials. Some
levels of administration can be reduced or eliminated, depending on the breadth
of the provisioning management solution. Furthermore, you can securely
distribute administration capabilities, manually or automatically, among various
organizations.
The approval process can be associated with different types of provisioning
requests, including account and access provisioning requests. Lifecycle
operations can also be customized to incorporate the approval process.

Models for provisioning

Depending on business needs, Identity Manager provides alternatives to

provision resources to authorized users on request-based, role-based, or
hybrid models.

© 2019 IBM Corporation 216

Enterprise IAM Training Module

Approval workflows

Account and access request workflows are started during account and
access provisioning. You typically use account and access request
workflows to define approval workflows for account and access
provisioning.

Account request workflows provide a decision-based process to determine

whether the entitlement provided by a provisioning policy is granted. The
entitlement provided by a provisioning policy specifies the account request
workflow that applies to the set of users in the provisioning policy
membership. Multiple provisioning policies might apply to the same user
for the same service target. There might also be different account request
workflows in each provisioning policy. The account request workflow for
the user is based on the priority of the provisioning policy. If a provisioning
policy has no associated workflow and the policy grants an account
entitlement, the operations that are related to the request run immediately.
For example, an operation might add an account.

However, if a provisioning policy has an associated workflow, that

workflow runs before the policy grants the entitlement. If the workflow
returns a result of Approved, the policy grants the entitlement. If the
workflow has a result of Rejected, the entitlement is not granted. For
example, a workflow might require a manager's approval. Until the
approval is submitted and the workflow completes, the account is not
provisioned. When you design a workflow, consider the intent of the
provisioning policy and the purpose of the entitlement itself.

 Audit trail tracking

Identity Manager provides audit trail information about how and why a
user has access. On a request basis, Identity Manager provides a process
to grant, modify, and remove access to resources throughout a business.
The process provides an effective audit trail with automated reports.

The steps involved in the process, including approval and provisioning

of accounts, are logged in the request audit trail. Corresponding audit
events are generated in the database for audit reports. User and Account
lifecycle management events, including account and access changes,
recertification, and compliance violation alerts, are also logged in the
audit trail.

© 2019 IBM Corporation 217

Enterprise IAM Training Module

 Enhanced compliance status

Identity Manager provides enhanced compliance status on items such

as dormant and orphan accounts, provisioning policy compliance status,
recertification status, and various reports.

Dormant accounts. You can view a list of dormant accounts with the
Reports feature. Identity Manager includes a dormant account attribute
to service types that you can use to find and manage unused accounts
on services.

Orphan accounts. Accounts on the managed resource whose owner in

the Identity Manager Server cannot be determined are orphan accounts.
These accounts are identified during reconciliation when the applicable
adoption rule cannot successfully determine the owner of an account.

Provisioning policy compliance status. The compliance status based

on the specification of provisioning policy is available for accounts and
access. An account can be either compliant, non-compliant with
attribute value violations, or disallowed. An access is either compliant
or disallowed.

Recertification status. The recertification status is available for user,

account, and access target types, which indicates whether the target type
is certified, rejected, or never certified. The timestamp of the
recertification is also available.

 Password policy and password compliance

Use Identity Manager to create and manage password policies.

password policy defines the password strength rules that are used to
determine whether a new password is valid. A password strength rule
is a rule to which a password must conform. For example, password
strength rules might specify that the minimum number of characters of
a password must be five. The rule might specify that the maximum
number of characters must be 10.

The Identity Manager administrator can also create new rules to be used
in password policies.

If password synchronization is enabled, the administrator must ensure

that password policies do not have any conflicting password strength
rules. When password synchronization is enabled, Identity Manager

© 2019 IBM Corporation 218

Enterprise IAM Training Module

combines policies for all accounts that are owned by the user to
determine the password to be used. If conflicts between password
policies occur, the password might not be set.

 Account and access provisioning authorization and

enforcement

A provisioning policy grants access to many types of managed

resources, such as Identity Manager server, Windows NT servers, and
Solaris servers.

Provisioning policy parameters help system administrators define the

attribute values that are required and the values that are allowed.

Policy enforcement is the way Identity Manager allows or disallows

accounts that violate provisioning policies.

You can specify one of the following policy enforcement actions to

occur for an account that has a noncompliant attribute.

Mark Sets a mark on an account that has a noncompliant attribute.

Suspend Suspends an account that has a noncompliant attribute.

Correct Replaces a noncompliant attribute on an account with the

correct attribute.

Alert Issues an alert for an account that has a noncompliant attribute.

 Recertification policy and process

A recertification policy includes activities to ensure that users provide

confirmation that they have a valid, ongoing need for the target type
specified (user, account, and access). The policy defines how frequently
users must validate an ongoing need. Additionally, the policy defines
the operation that occurs if the recipient declines or does not respond to
the recertification request. Identity Manager supports recertification
policies that use a set of notifications to initiate the workflow activities
that are involved in the recertification process. Depending on the user
response, a recertification policy can mark a user's roles, accounts,
groups, or accesses as recertified. The policy can suspend or delete an
account, or delete a role, group, or access.

© 2019 IBM Corporation 219

Enterprise IAM Training Module

Audits that are specific to recertification are created for use by several
reports that are related to recertification:

Accounts, access, or users pending recertification Provides a list of

recertifications that are not completed.

Recertification history Provides a historical list of recertifications for

the target type specified.

Recertification policies Provides a list of all recertification policies.

User recertification history Provides history of user recertification.

User recertification policy Provides a list of all user recertification

policies.

 Reports

Security administrators, auditors, managers, and service owners in your

organization can use one or more of the following reports to control and
support corporate regulatory compliance:

 Accesses Report, which lists all access definitions in the system.

 Approvals and Rejections Report, which shows request activities
that were either approved or rejected.
 Dormant Accounts Report, which lists the accounts that were not
used recently.
 Entitlements Granted to an Individual Report, which lists all users
with the provisioning policies for which they are entitled.
 Noncompliant Accounts Report, which lists all noncompliant
accounts.
 Orphan Accounts Report, which lists all accounts not having an
owner.
 Pending Recertification Report, which highlights recertification
events that can occur if the recertification person does not act on an
account or access. This report supports filtering data by a specific
service type or a specific service instance.
 Recertification Change History Report, which shows a history of
accesses (including accounts) and when they were last recertified.
This report serves as evidence of past recertifications.

© 2019 IBM Corporation 220

Enterprise IAM Training Module

 Recertification Policies Report, which shows the current

recertification configuration for a specific access or service.
 Separation of Duty Policy Definition Report, which lists the
separation of duty policy definitions.
 Separation of Duty Policy Violation Report, which contains the
person, policy, rules violated, approval, and justification (if any),
and who requested the violating change.

Test your Knowledge

1. What is Identity Manager?
2. How Identity manager help to simplify user management?
3. What is Role Based Access control of Identity Manager?

© 2019 IBM Corporation 221

Enterprise IAM Training Module

UNIT 10: IDENTITY MANAGER STRUCTURE &

COMPONENTS

© 2019 IBM Corporation 222

Enterprise IAM Training Module

CHAPTER 14: Identity Manager Structure &

Components

Identity Manager Entities

Identity Manager’s role is to manage users and their accounts. Passwords, group
memberships, and other attributes are associated with the users and accounts.
These all relate to managed systems and applications. To enable management of
users, accounts, and associated information, Identity Manager uses roles and
policies. Identity Manager also contains workflow, audit logs, and reports.

The entities managed by Identity Manager are:

 Users, accounts and attributes

 Passwords
 Group memberships
 Managed systems and applications
 Users, Accounts, And Attributes

A user is typically an employee of the company or organization or is

typically an individual who needs access to an organization's managed
system or application but who is not considered an employee.

Typically when employee joined organization is defined in the HR system

of the company. A user has its several attributes, this may include first, last,
and full names, phone numbers, employee number, supervisor, and e-mail
address. Identity Manager read the data of user from HR System. In other
word, you can say HR system is authoritative data source for any user
identity. This data is feed in to Identity Manager system. In next step
Identity Manager create accounts on various managed system like AD,
UNIX, SAP, internal applications etc.

An account is a person's access to Identity Manager or to a Service

(managed resource), such as Linux, Active Directory, Solaris, SAP, and so
on. Accounts have attributes that are defined by the managed resource.

© 2019 IBM Corporation 223

Enterprise IAM Training Module

Reconciliation is the process of determining the accounts existing at

managed resources and processing each against provisioning policies
defined within Identity Manager based on the owner. An orphan account is
an account that is not associated with a Person. Orphan accounts are
generated when the conciliation process cannot automatically associate
the account with a person.

The above figure shows the relationship between a user and account. In the
figure, a user, or an employee, Jane Doe is defined in the HR system of the
company. When Jane is defined to Identity Manager, user accounts on
managed resources such as UNIX, Microsoft Active Directory, and
internal applications can be provisioned according to the provisioning
policy.
 Identity feed

Identity Manager users are created either by importing identity records with the
use of an identity feed or by manually creating each user. An identity feed is the
process of synchronizing the data between an authoritative data source, such as
an HR system, and Identity Manager. The initial reconciliation populates Identity
Manager with new users, including their profile data. A subsequent reconciliation
creates new users and also updates the user profile of any duplicate users that are
found.

© 2019 IBM Corporation 224

Enterprise IAM Training Module

Identity feeds use data from an external authoritative data source to create,
modify, and delete user records in Identity Manager. Identity feeds are usually
implemented using connectors. Connectors can read file-based data in several
standard formats, such as comma-separated value, Extensible Markup Language
(XML), and LDAP Data Interchange Format (LDIF). Connectors can also extract
data from structured data sources such as directories and databases. Common
reasons for using an identity feed are to:

 Keep Identity Manager’s user records synchronized with

authoritative data source (i.e. human resources database)
 Perform a mass update of user records in Identity Manager

 Passwords

All accounts have passwords. Account passwords can be centrally

managed by their owners or administrators using the Identity Manager
Web interface. Password management is a very important topic. Since
passwords represent access to corporate applications, they must be securely
managed during their entire life cycle. Identity Manager provides a full set
of features to manage the passwords in a secure environment.

Identity Manager uses a challenge/response function to verify a user’s

identity if they have forgotten their Identity Manager password. The
challenge questions can be picked from a standard list or defined by the
user. When a user logs into Identity Manager for the first time, they enter
or select the challenge questions (if configured) and responses. On
subsequent logins to Identity Manager, they can select a forgot password
option and a subset of the challenge responses are used to verify the user.

 Managed systems and applications

Identity Manager manages users on many managed systems. These include

operating systems, applications, databases, directory servers and home-
grown business applications.

Example of managed system and applications are Active Directory,

Apache Directory Server, Red Hat Directory Server, Sun Java System
Directory Server, IBM Tivoli Directory Server, Lotus Domino, Oracle
RDBMS, IBM DB2, Microsoft SQL Server, SAP Sybase, Teradata,
MySQL, Unix servers, Linux servers, AIX servers, Box Cloud, Guardium
GDPR, StealthBits GDPR, Oracle eBusiness Suite, Remedy AR System,
Salesforce, Documentum Content Serve, SharePoint, PeopleTools, SAP

© 2019 IBM Corporation 225

Enterprise IAM Training Module

HANA database, SAP NetWeaver, ServiceNow, Google Applications,

Microsoft Office 365, Cisco WebEx Meetings, Dropbox, SAP Concur,
Zoho Workplace, Exchange Email, G Suite etc. or any home-grown
application inside the company.

Role
An Identity Manager provide user entitlement, or you can say Identity
manager do entitlement management for user accounts. Entitlement
management is technology that grants, resolves, enforces, revokes and
administers fine-grained access entitlements (also referred to as
“authorizations,” “privileges,” “access rights,” “permissions” and/or
“rules”). Its purpose is to execute IT access control policies to ensure that
user should not have access to more privileges than they need to perform
their jobs.

User entitlement refers to the privileges granted to users when their

accounts are first created and during the lifetime of the accounts. One of
the primary considerations is ensuring that the principle of least privilege
is followed. Users should not have access to more privileges than they need
to perform their jobs.

Managing changes during the lifetime of the account can be challenging.

Often, the process requires users to submit a request that must go through
an approval process, and during this time, the user isn’t able to complete
job requirements. Bypassing the process improves productivity but
sacrifices security.

Identity Manger recorded all changes in logs, creating an accurate audit

trail. The audit trail can be used during an audit or review to determine
whether the approval process is being followed. When someone’s account
is granted administrative privileges, the audit trail provides information
about who requested the change, who approved it, and who implemented
it.

Identity Manager used role for managing user entitlement. Roles (or
Organizational roles) are a method of providing users with entitlements to
managed resources. Roles determine which resources are provisioned for
a user or set of users who share similar responsibilities. A role is a job
function that identifies the tasks that a person can do and the resources to
which the person has access.

© 2019 IBM Corporation 226

Enterprise IAM Training Module

If users are assigned to an organizational role, managed resources that are

available to that role, then become available to the users in that role. The
resources must be properly tied to that role. For example: Let’s suppose
there are two roles Role A and Role B. Role A is tied with entitlement of
provisioning user on Salesforce, while Role B entitlement is for SAP
account. Identity manager create accounts in Salesforce for users who have
Role A and create accounts in SAP for users who have Role B.

You can assign a user to one or more roles. Additionally, roles can
themselves be members of other roles, in what is termed child roles that
contribute to role hierarchy. A role might have more than one parent, and
the inheritance comes from all parents and ancestors.

A role might be a child role of another organizational role, which then

becomes a parent role. That child role inherits the permissions of the parent
role. A role might be a child role of another organizational role in a
provisioning policy. That child role also inherits the permissions of
provisioning policy.

Activities are often assigned to roles rather than to individuals. This role-
based model lowers the risk that individuals might gain more system access
than required by their job function. You can also define policies (separation
of duty policy) to prevent users from having multiple roles that result in a
conflict of interest.

© 2019 IBM Corporation 227

Enterprise IAM Training Module

This diagram shows an example role hierarchy. The roles are shown in
blue. The role relationships are shown with blue arrows. People are shown
in green. A role hierarchy an include business roles and application roles.
Roles can have multiple children, like the All Hospital Employees role.
Roles can have multiple parents, like the Doctors role. People can be
members of multiple roles. Anna is a member of the Cardiologist and
Clinical Educators roles and receives the entitlements associated with those
roles. And, since the roles are part of a role hierarchy, she inherits the
entitlements from the Doctors, eMR User, and All Hospital Employees
roles.

Policy
 Identity Policy

An identity policy defines how a user's ID is created. Identity Manager

automatically generates user IDs from the identity policy. Identity
policies can be set as a global policy or as a service-specific policy. If
the identity policy is not a global policy, the policy can be assigned on
a per-service basis (for example, it only applies to specific service
types) or it can be assigned to a combination of service types or
instances. For example, if all user IDs must be composed of the user's
first initial and last name, a global identity policy must be created for
the organization. If all user IDs for a specific service must contain a
certain number, a service-specific identity policy must be created for
the service.

An identity policy defines the characteristics of a user ID used when

requesting a new account. An administrator defines the targets and the
rule that is used to generate user IDs automatically for the services to
which the rule is applied. The user ID can be based on attributes of the
user for whom the account is being created. An identity policy generates
a default user ID used when requesting a new account. An administrator
defines the rule to generate the user ID and specifies the service targets
that apply.

You can define basic rules for an identity policy. Basic rules can specify
which attributes to use, how many characters are used from each
attribute, and what case to use when creating a user ID. To set a
character limit, an identity policy rule defines the number of characters
to use from a first and second attribute to form the user ID. Forming the
user ID from the attributes has the following conditions:

© 2019 IBM Corporation 228

Enterprise IAM Training Module

 If the number of characters in the attribute is greater than the

specified character limit, only the character limit is used.
 If the number of characters in the attribute is less than or equal to
the specified character limit, the entire value of the attribute is
used.
 If a second attribute is not specified, only the first attribute is used.
 If a duplicate user ID exists when Identity Manager creates a user
ID, the process appends an integer to the new user ID to create a
unique user ID.

 Password Policy

A password policy defines the password strength rules that are used to
determine whether a new password is valid. A password strength rule
is a rule to which a password must conform. For example, password
strength rules might specify that the minimum number of characters of
a password must be 5. The rule might also specify that the maximum
number of characters must be 10.

A password policy sets the rules that passwords for a service must meet,
such as length and type of characters allowed and disallowed.
Additionally, the password policy might specify that an entry is
disallowed if the term is in a dictionary of unwanted terms.
You can specify the following standards and other rules for passwords:
 Minimum and maximum length
 Character restrictions
 Frequency of password reuse
 Disallowed user names or user IDs
 Specify a minimum password age

 Adoption Policy

During reconciliation, an adoption policy determines the owner of

an account. An account without any owner is an orphan account. An
adoption policy matches the attributes for an account on a managed
resource to the attributes for Identity Manager user. If the adoption
policy returns a single result, the account is adopted. If there is no
unique result, the account remains an orphan.

© 2019 IBM Corporation 229

Enterprise IAM Training Module

 Provisioning Policy

A provisioning policy is used to define what accounts can be created for

a user. A provisioning policy grants access to many types of managed
resources, such as Identity Manager Server, Windows NT servers,
Active Directory, Mail Servers and Solaris servers.

A provisioning policy defines the accounts and access that are

authorized to users or automatically provisioned for users by the user's
role. When account and access are authorized to a user by a provisioning
policy, they can be requested by the user. A provisioning policy can be
used to support role-based provisioning, in which accounts and access
are automatically provisioned to a user, based on the user's roles.

Provisioning policies are important to support security compliance.

Identity Manager evaluates all account and access requests based on the
provisioning policy to identify accounts and access that are not
authorized and take appropriate actions to handle noncompliant account
and access.
 Separation of Duty Policy

A separation of duty policy allows you to manage rules that define

which static organizational roles are mutually exclusive. In simple
terms, members of role A cannot be members of role B and vice versa.
Separation of duty (SoD) policies are used to protect against conflicts
of interest. Separation of duty policies may be owned by a person or an
organizational role.

More complex separation of duty policies can be defined. This may be

used to ensure that no one person can control an entire process. Rules
can be created so that a person can only be a member of a defined
numbers of roles within the policy. For example, a separation of duty
policy may contain roles A, B, C, and D. The rule could restrict
membership to just three of the defined roles. So in our example, a user
could have any three of those four roles, such as A, B, and D, but having
all four of them would be a policy violation.

Separation of duty (SoD) is a policy-driven feature to manage potential

or existing role conflicts. A valuable feature of a role-based

© 2019 IBM Corporation 230

Enterprise IAM Training Module

provisioning system is to provide users with only the services they

require for their job. Often, departments have conflicting roles and
establish policies that prohibit one person from belonging to conflicting
roles. For example, if you have a person that can request a check,
another person must approve that request. If the person who writes the
checks is the same person that approves the checks, they might write
checks to themselves. This situation is a liability and a violation of
accounting practices.

 Recertification Policy

A recertification policy allows accounts, accesses, and users to be validated

periodically, either at fixed dates or on a rolling calendar basis (for example, three
months since the last time the item was recertified). A recertification policy is
created by creating a workflow and assigning it to a calendar event. Account
recertification is a common account lifecycle requirement.
 Recertification ensure security compliance by asking users if they still
require a specific account or access
 Recertification support for defining policies and workflow to collect
periodic recertification of user access rights for compliance audits
 Recertification can be applied to accounts, access entitlements, roles, and
users
 Recertification schedule can be based on calendar (specific date and time)
or based on time interval (rolling schedule).

Logical Component Architecture of Identity

Manager
The below figure shows Logical component architecture of Identity
Manager. Identity manger have below two components.
1. Data tier
2. Application Server

© 2019 IBM Corporation 231

Enterprise IAM Training Module

Data tier
Data tier is typically LDAP or Database in which Identity Manager store
all information of Users, roles, policies and transactional log record and
audit data. Identity Manager can use either LDAP or Database or both to
store this information.

Identity Manager can store all information of Users, roles, policies and
transactional log record and audit data in LDAP alone.
Identity Manager can store all information of Users, roles, policies and
transactional log record and audit data in Database alone.
Identity Manager can use both LDPA and database. In that scenario
normally, Users, roles, policies are stored in LDAP. While transactional
log record and audit data are stored in database.

Application Server Identity Manager is centralized web browser-based

application. Normally Identity manager application can be developed in
JAVA platform Enterprise Edition or in .NET Framework. Identity
Manager need to be deployed on JAVA application server or .NET
framework technology application server as per technology on which it
was developed.

© 2019 IBM Corporation 232

Enterprise IAM Training Module

Test your Knowledge

1. What is Identity Feed?
2. What is Password Policy?
3. Explain Separation of duty policy?

© 2019 IBM Corporation 233

Enterprise IAM Training Module

UNIT 11: IAM GOVERNANCE

© 2019 IBM Corporation 234

Enterprise IAM Training Module

CHAPTER 15: Identity & Access Management

Governance

Introduction
Identity and Access Management Governance is a set of processes and
policies for organizations to manage risks and maintain compliance with
regulations and policies by administering, securing, and monitoring
identities and their access to applications, information, and systems.
Although potentially complex in implementation, the concept of Identity
and Access Management (IAM) Governance is fairly straightforward:
determine who should have access to what resources and who should not,
according to government regulations, industry-specific regulations (SOX,
HIPPA, GLBA, etc.), and business regulations and guidelines.

Figure: Deliver the right accesses for the right people to the right
resources at the right time in the right context

For a governance approach to make sense to the lines of business, the

organization must:

 Provide visibility in a business context for the control and protection of

business assets.
 Improve or maintain productivity levels.
 Provide automation to reduce costs and save time.

Key aspects of IAM Governance include:

 Access request governance

 Entitlement certifications
 Reports and audits

© 2019 IBM Corporation 235

Enterprise IAM Training Module

 Analytics and intelligence, including role management, entitlement

management, separation of duties enforcement, and privileged
identity management

In addition to addressing the certification and lifecycle of these key

artifacts, businesses might consider building an end-to-end IAM
Governance solution and providing related functions, such as access
enforcement, user provisioning, password management, and user
lifecycle management.

The Approach: Integrated IAM Governance

with Intelligence and Accountability
Driven by GOVERNANCE, RISK, AND COMPLIANCE (GRC) and
business information collaboration needs, organizations want to deploy
solutions that address the key aspects of governance. Organizations
seeking IAM governance want a streamlined method to govern, secure, and
monitor user access to resources. They require transparency across their
businesses to ensure that they can mitigate the risk of providing user access.
This transparency must be delivered in a way that

 Is consumable by the lines of business.

 Is consistent with the organization’s overall governance policies.
 Promotes the exchange of information.
 Strengthens the organization’s overall security risk posture.

Identity governance provides a governance framework for efficient and

compliant access to the right people with the right resources at the right
time. Using Identity and Access Governance, an organization can quickly
build a solution that is based on analytics, intelligence, and policies to
manage people, applications, and entitlements. This solution provides the
consistency and breadth needed for IAM governance, risk management,
and compliance.

A closed loop process to achieve IAM Governance

Developing a logical, phased approach to IAM governance increases the

change for success.

© 2019 IBM Corporation 236

Enterprise IAM Training Module

A closed loop process for IAM Governance

People, their identity attributes, and their associated roles provide critical
links to the business and business processes that deliver organizational
visibility, accountability, and improved efficiency. Applications and their
associated roles link entitlements to the users so that they can perform their
job through appropriate access to systems and information. The
management of application entitlements should leverage the business
context of identities, services, and the surrounding environment. An
ongoing review of user activity monitoring aids conformance to policies
and regulations, but it also can leverage the monitoring and analysis of user
activities to predict, detect, and correct abnormal user behavior. It is also a
key feedback loop into an organization’s overall governance infrastructure.

The organization decides where to start

Achieving IAM governance does not require that an organization start with
planning and follow the phases in any specific order. Organizational
priorities, controls, operating procedures, and the current state of the
identity repositories dictate where a business starts and where to build an
authoritative System of Record (SOR) for IAM Governance.

Organizations can start with:

 Monitoring their operations and user accesses.

 Collecting and modeling their data.
 Coarse grained access control.
 Certifying existing accesses and data cleansing.

© 2019 IBM Corporation 237

Enterprise IAM Training Module

Organizations can adapt, evolve, and incrementally deploy their

governance solution.

 Access and Role Certification

Initial and periodic access certification for continued business needs

help direct and control operations. It also expands the means to manage
compliance.

Access certification

 Includes review and certification of user access assignment via role

or direct assignment to determine who received access to what,
when, and why.
 Ensures that users have only the privileges and exception
entitlements they need to perform their job.
 Can detect policy violations, access anomalies, orphan and dormant
accounts, etc.

Maintaining the certification and access change history aids the

certification and audit processes.

Role (re)certification

Identity Manager supports User to Role (re)certification and User to

Access (re)certification with the RECERTIFICATION POLICY.
Recertification policy simplifies and automates the process of
periodically revalidating a target type (account or access) or a
membership (role or resource group). Depending on the business needs
and the risk level of protected resources, organizations can set a suitable
period to perform the scheduled access certification. They can also kick
off a certification campaign that is based on demand or on an event,
such as a management event or anomaly detection. The process sends
recertification notification and approval events to the participants. A
recertification policy includes activities to ensure that users provide
confirmation that they have a valid, ongoing need for a specified
resource or membership.

© 2019 IBM Corporation 238

Enterprise IAM Training Module

Access and user certification enhance compliance and reduces risk

The recertification policy also defines the operation that occurs if the
recipient declines or does not respond to the recertification request.
Recertification policies use a set of notifications to initiate workflow
activities in the recertification process. For example, a system
administrator of a specific service can create a recertification policy for the
service that sets a 90-day interval for account recertification. If the
recipient of the recertification declines recertification, the account can be
automatically suspended.

During the certification process, the solution can do bulk or selective

certification. For a time-critical certification, the solution provides options
to automatically escalate or delegate the action item to an alternate user
when timely action is not taken. The solution also helps automate business
processes that are related to changes in user identities with lifecycle
management with role membership.

© 2019 IBM Corporation 239

Enterprise IAM Training Module

Automatic remediation

To deliver validation and remediation of user access and to ensure that the
changes are immediately reflected on the end system, organizations can
integrate access certification with user provisioning. If the certifier
removes the access or role for a user, the system automatically removes the
user access.

Certifiers can

 Preview the impact of the certification before submitting it to see if any roles,
accounts, or groups are affected by the access decision.
 Save incremental progress as a draft and complete the certification at a later time.

Approval and recertification policies deliver change control at the user,

role, and access level. Without substantially impacting the business, the
change control process can consume any change to the business that affects
the user, role, and access structure.

 Access request and fulfillment

Depending on their business needs, organizations can

 Automate access fulfillment with either role-based assignment or a

subset of employees or managed systems, while keeping other
access requests or exceptions fulfillment through a request-based
model.
 Start with a manual assignment and evolve toward a hybrid model
with the intention of deploying a fully role-based deployment in the
future.
 Target a hybrid approach when it might be impractical for business
reasons to achieve complete role-based provisioning.
 Deploy only request-based provisioning and avoid investing in
efforts to define and manage role-based, automated provisioning
policies.

The hybrid model of provisioning resources combines the request and

role-based approaches, which are supported by many Identity Manager
solution. Its access request management delivers a quick-start option to
streamline user provisioning. It also offers users the opportunity to
manage their role memberships, access rights, passwords, personal
information, and approval tasks.

© 2019 IBM Corporation 240

Enterprise IAM Training Module

Identity Management provisioning models

Access requests can be automatically approved or go through an approval

process. Identity Manager provides a powerful workflow engine. Email
and an action item in their To-do list notify the approver of the pending
requests. Requesters can check the status of a request and track its
progress.

After the access request is approved automatically or by an approver, the

associated provisioning policy can fulfill the request by creating and
updating the user’s account or group. Provisioning Policy in Identity
Manager defines the accounts and access that are authorized to users or
automatically provisioned for users by the user's role.

 Access Enforcement

Associating the entitlement with an IT binding is optional. However,

enforcing entitlements that are predefined for the application, not just
associating user/role membership with a group on an application, is
critical for building a closed loop governance system. This stage is
also where independent access certification of entitlements has value;
it can be delivered and managed separately from roles if necessary.

With Identity Access Governance, organizations can:

 Manage consistent sets of access control policies in line with security

policies and compliance regulations across enterprise systems.
 Implement a policy-based access control system that delivers unified
authentication and authorization to diverse Web-based applications,

© 2019 IBM Corporation 241

Enterprise IAM Training Module

files, and operating systems. The system offers single sign-on

capabilities to web, Microsoft Windows, Java, and mainframe
applications. The standards-based (XACML) entitlements management
(roles, rules, attributes) is used for data security and fine-grained access
control. The entitlement data is used for runtime enforcement, which
provides Integrated Role-Based Access Control (RBAC) And
Rule/Attribute-Based Access Control (ABAC).

 Manage and enforce fine-grained entitlement and data-level access

control based on roles, business attributes, and contextual information,
such as relationship, environment, action, behavior, and device. This
type of control is critical to ensuring privacy and data security.

 Detecting and Fixing Anamoly and Noncompliance

Sometimes, employees are granted access that bypasses the control

framework for request and provisioning. Sometimes, when employees
leave or change jobs, their application and system accounts might not
be terminated, which results in dormant and ORPHAN accounts.
These unaccounted and extraneous accesses expose an organization to
security breaches, higher license costs, and audit failures due to non-
compliance.

 Role and Entitlement Mining and Modeling

As described in Intelligent role management for improved security and

compliance, roles and role hierarchies can greatly simplify and automate
user access request, certification, and access management. Intelligent role

© 2019 IBM Corporation 242

Enterprise IAM Training Module

management can also place a meaningful business context on an access to

make it intuitive to the business users. By modeling, analyzing, and
simulating the roles, entitlements, and separation of duties, organizations
can understand the impact that they have on the business and any
established user access permissions. Both the business and IT sides of the
organization should approve the final enterprise role and policy structure.

Effective IAM governance requires:

 Establishing agreed upon business objectives.

 Engraining these objectives into the process.
 Defining controls.

These processes and controls must be based on the resources to be

protected; relevant standards; and legal, regulatory, and business
requirements.

Organizations should perform an internal assessment to:

 Identify the process, such as the processes for bringing users into
and out of the company, division, and department.
 Discover data across people and the application and data
infrastructure.

Start small and involve the line of business

When you are doing role planning:

 Target a department, division, or job responsibility.

 Communicate with the key line of business personnel.
 Learn how job functions are tied to the critical business processes
today.
 Determine how they can be better organized and optimized in the
future.

Start a certification campaign to collect and cleanse the data

When embarking on any role development project, it is important to gain

visibility into the current application access environment. In parallel, IT
should clean up user and entitlement data to match known users to known
accounts and entitlements. This process delivers immediate value for

© 2019 IBM Corporation 243

Enterprise IAM Training Module

organizations as they seek to address compliance requirements or as a

precursor to role creation. Data clean-up includes identification and
collection of data from prioritized target systems that have relevant user
and entitlement data, such as user provisioning solutions, Active Directory,
LDAP, HR databases, financial databases, ERP applications, RACF, and
access management solution.

Avoid role proliferation by periodic role modeling, analysis, and

reviews

While roles help simplify the access certification and access management,
it is important not to implement so many roles that the roles become
unmanageable. Role planning and role management requires in-depth
thinking about the purpose and structure of the role (flat vs. hierarchical).

Periodic modeling, analysis and/or review of the roles should be performed

to remove redundant, overlapping, and obsolete roles and to maintain the
optimized set of roles.

 Role and User Lifecycle Management

Role and User Lifecycle describes how roles, users, and accesses are
created, managed, and terminated based on certain events or a time-
based paradigm.

© 2019 IBM Corporation 244

Enterprise IAM Training Module

Identity management supports automated provisioning and

deprovisioning through the user lifecycle

User lifecycle management relates to the activities that surround:

 User operations. For example, these activities might include on-

boarding, off-boarding, modifications, transfers, promotions, and
temporary assignments.
 Account/access operations. For example, these activities might
include adding, deleting, modifying, suspending, and restoring
entitlements.

The operational workflow can automate provisioning and deprovisioning

based on lifecycle events. Operational workflows can also be associated
with lifecycle policies. These capabilities can automate large numbers of
manual tasks that administrators must perform due to changes in the
environment. These changes include common reoccurring events that are
driven by business policies, such as password expiration or contract
expiration. Lifecycle policies can also eliminate the possibility of
unenforced policies.

 Delegated Administration

As the number and type of users in an organization’s identity

management system changes, there are increasing burdens on the
system. Any centralized system run by an IT department might manage
users who are in other business units or even other partner
organizations.

Identity Manager support the ability to delegate the day-to-day

management of users to nominated leaders in other business units or
partner organizations. As an example, at the extreme, organizations can
delegate individuals to manage some features of their own identity, such
as changing location details or resetting a password.

 Actionable Reporting, Auditing and Monitoring

Ongoing reporting, auditing, and monitoring provide organizations

with two key benefits.

KEY IDENTITY GOVERNANCE REPORTS enable an organization to

meet their audit requirements for both external regulatory mandates and

© 2019 IBM Corporation 245

Enterprise IAM Training Module

internal corporate security policies. These reports are granular enough to

identify what fine-grained permissions a particular user or role is entitled.

USER COMPLIANCE AUDITING AND MONITORING delivers a

consistent litmus test on the enterprise role and entitlement structure. That
is, does the defined role structure really match and align with what users
do with the access they have been granted? This link is critical for end-to-
end governance, because it creates a feedback loop into the role definitions,
policies, and on-going change control.

Some key reports may include:

 Access Pending Recertification Report

 Recertification Change History Report
 Report of dormant and non-compliant accounts
 Entitlements granted to an individual
 Reports related to Shared access
 Failed Authentication Event History
 Resource Access by Accessor
 Locked Account History
 Most Active Accessors

There are many other standard reports that demonstrate compliance

with security policies and provide an audit trail. Reports can also
provide a means to detect attacks, system inconsistencies, and dormant
accesses. For example:

RECERTIFICATION CHANGE HISTORY and the ENTITLEMENT

GRANTED TO AN INDIVIDUAL reports can provide an audit trail of
the accesses granted to an individual during the user’s lifecycle.

MOST ACTIVE ACCESSORS and ENTITLEMENTS GRANTED

TO AN INDIVIDUAL reports detect an unauthorized and malicious
access.

RESOURCE ACCESS BY ACCESSOR and ENTITLEMENTS

GRANTED TO AN INDIVIDUAL reports can detect an access that
the user has never used and which should probably be removed from
the user’s access list.

© 2019 IBM Corporation 246

Enterprise IAM Training Module

 Analytics and Intelligence

Analytics and intelligence can greatly improve day-to-day operational

efficiency and mitigate any impending risks. Analytics and intelligence
are collected through archive and live data across multiple data sources,
including the provisioning and certification data.

 IAM Governance for Cloud, Mobile and Social Media

Resources

With the proliferation of IT resources and services in cloud, mobile and

social media, it is important that access to these resources/services are
governed, they are compliant, and processes are in place to mitigate
risks, like in house IT resources or devices. Identity Manager helps by
providing adapter for these resources, which can be used to configure
these resources as provisioning and access targets and manage them as
any other in-house resource and service.

Test your Knowledge

1. What is Identity Governance?

© 2019 IBM Corporation 247

Enterprise IAM Training Module

UNIT 12: PRIVLEGED IDENTITY MANAGER

© 2019 IBM Corporation 248

Enterprise IAM Training Module

CHAPTER 16: Privileged Identity Manager

What is Privileged Identity

Privileged identity refers to the pre-built accounts in nearly every operating

system and application. Privileged accounts are general user identities
distinguished by the assignment of security, administrative, or system
authorities.

Privileged identities are typically distinguished by the names they use.

For example, administrator, sa, root, db2admin.

Unlike a personal identity like jdoe, you can access privileged accounts
only with a privileged password, and account access is hard to disable. In
an enterprise environment, multiple Administrators might share access to
a single user ID for easier administration. When multiple Administrators
share accounts, you can no longer definitively prove that an account was
used by one Administrator as opposed to another. You lose personal
accountability and audit compliance.

Privileged IDs and why they are a problem

Privileged ID refers to any account that holds special or extra permissions

for enterprise resources, such as Windows servers, UNIX/Linux servers,
network appliances, database systems, and ERP applications.

These IDs include:

 Pre-built administrator or super-user accounts (such as root, sa, and
administrator) that are found in many operating systems and
applications.
 Individual user accounts with escalated privileges where misuse and
abuse can have significant business impact.
 Accounts that are created for staff or contractors who perform a set of
delegated administrative tasks on a set of enterprise resources.

Hackers compromising a privileged ID are an obvious risk. However,

authorized users with privileged accounts in an organization also represent

© 2019 IBM Corporation 249

Enterprise IAM Training Module

a clear and present danger to the data security of an IT infrastructure.

Studies of security breaches by various authorities consistently reveal that
insider threat is as much or more an issue as external hackers. Thirty to
fifty percent of incidents are being caused by insiders. Insider negligence
rather than malicious behavior is often the cause – such as sharing of
passwords, use of weak passwords, or writing passwords on Post-It notes.
Social engineers, disgruntled employees, suppliers and competitors can be
adept at maneuvering around strong controls to exploit points of weakness,
including simply looking over someone's shoulder to steal information.
Once the organization’s perimeter is breached, weak internal controls can
give hackers unfettered access to critical data and applications.

Traditionally, organizations issue privileged IDs to individual users. They

configure the accounts with privileges that match the intended roles.
However, this model of IT administration is no longer enough for
organizations in which consolidation, virtualization, and server density
continues to increase dramatically. Administrators:

 Must manage increasingly larger numbers of resources.

 Are being overwhelmed by the multitude of accounts to manage and
passwords to remember.

At the same time, there is also an increasing trend for organizations to

delegate specific administrative tasks to staff and contractors. These tasks
include help desk for user assistance and operators for system backups.
This situation presents more challenges since these tasks are often
delegated to a large pool of staff or contractors whose membership changes
frequently.

Additionally, employees, such as application owners and developers,

might require occasional or one-time privileged access to specific
resources to perform maintenance tasks for applications. These users need
short-term, time-bound access to specific resources. Their access also
requires justification.

Organizations without identity management systems might be tempted to

allow privileged users to share one or more common user IDs on each
resource. Sharing common user IDs circumvents the need to continually
add and delete accounts as users come and go. This approach is undesirable
for several reasons.

© 2019 IBM Corporation 250

Enterprise IAM Training Module

Lack of individual accountability

It is impossible to track who has access to the credentials of an account

over any time period. Credentials to these IDs can pass from one user to
another over email and instant messaging and on pieces of paper. Actions
that are performed on the resource with this ID cannot be attributed to a
specific person. Lack of individual accountability removes an important
deterrent against irresponsible or malicious acts by anyone who knows the
password to the ID.

Password management challenges

Administrators might set passwords for IDs to predictable values or
patterns that prevent users who share the ID from repeatedly asking for the
password. Frequently changing the password becomes burdensome. It is
difficult for anyone to change the password without inadvertently locking
out other users.

This method puts any organization in a precarious position.

 Sensitive privileged accounts have the most poorly secured credentials.

 Actions cannot be traced to a single person.
 The organization does not conform to security audit rules and
compliance regulations.

Organizations with an identity management system might assign individual

privileged IDs to every IT staff member who requires privileged access to
each resource. If an organization assigns every privileged user an account
to a managed resource, management becomes troublesome and expensive.
In an extreme example, an IT staff of 400 that manages 10,000 servers
might easily end up with as much as 4,000,000 privileged administrative
IDs. It is technically possible to set up the roles, policies, and workflow in
the identity management system to automate the provisioning and
deprovisioning of these IDs. However, the following issues are likely to
occur:

Administrative overhead
Security administrators and resource owners spend an inordinate amount
of time tweaking provisioning policies, reconciling accounts, and
performing audits to minimize account proliferation on managed
resources.

© 2019 IBM Corporation 251

Enterprise IAM Training Module

Password management challenges

Users are provisioned with many accounts on each resource. They must
then:

 Remember the password to each account.

 Change passwords regularly.
 Recertify the business need to own each account regularly.

In this situation, users might

 Write down the passwords and create a security exposure.

 Forget the password when they finally want to use the ID.

Processing overheads on systems

With many accounts to manage, the identity management system and

various resources become overburdened with frequent provisioning and
deprovisioning requests.

The below figure summarizes the two extreme situations related to how
organizations might deal with privileged IDs.

The solution is an identity management system that provides a secure and

convenient way for IT staff to share privileged IDs. This solution must
include:

 A Credential Vault to securely store the credentials to privileged IDs.

© 2019 IBM Corporation 252

Enterprise IAM Training Module

 A Check-out Check-In (COCI) mechanism so that a privileged user can

check out an ID (with password) for exclusive use for a limited time
period whenever necessary. The user can check in the ID when he
finish, whereupon the password is changed.
 A means for centrally provisioning and managing IDs on various
resources.
 Roles and policies for dictating which users have access to which IDs.
 A way for users to request access to IDs and for managers to approve
the requests.
 Audit logs to record all COCI activities. These logs show which user
had access to which IDs over a specific time period.

With this solution, an organization can:

 Avoid the proliferation of privileged IDs on its resources.

 Allow privileged users to access a privileged ID:
 If they need it.
 When they need it.
 On the condition that they need it.
 Only as long as they need it.
 Make privileged users accountable for the IDs that they owned or
checked out.
 Delegate management of IDs and its access policies to respective
resource owners.
 Produce audit logs and reports to demonstrate compliance and to use
for post-incident forensics.

This solution for sharing IDs is best applied on privileged roles that fit the
previously described scenarios. However, not all privileged IDs must be
shared. It is also not appropriate to force-fit all privileged IDs as shared
IDs. After all, the process of COCI introduces varying degrees of
inconvenience to privileged users.

For example, an Active Directory domain administrator can use an

individual Active Directory account to access all Windows computers in
the domain. When this user changes roles, the organization changes only
the user’s Active Directory group membership. There is no need to
provision or deprovision accounts when new computers are added to the
domain or when a user changes role. In this situation, the case is weak for
making users check out shared administrative IDs.

© 2019 IBM Corporation 253

Enterprise IAM Training Module

For scenarios in which a few resources are managed by dedicated

administrators who access them regularly, it remains appropriate to issue
individual privileged IDs.

Most organizations do well with a blend of individual and shared privileged

IDs that offer the optimal combination of security, convenience, and
productivity. Each employee might have privileged accounts on some
systems and regular user accounts on others. Furthermore, these
entitlements may change as a user changes role in the organization. In this
case, the organization benefits from a single identity management system
that:

 Provides lifecycle management of all IDs in the enterprise, whether

privileged or non-privileged or individual or shared.
 Manages entitlements to all IDs based on user roles and organizational
policies.
 Provides a single view into the organizational governance of user ID
entitlements to security administrators and security auditors.
 Supports single sign-on to systems and applications with individual and
shared IDs.
 Provides migration capability from individually-owned privileged IDs
to shared IDs, or vice-versa, for different managed resources as the
situation warrants.

Privileged Identity Manager is an identity management system that

supports the above requirements.

What is Privileged Identity Manager

Privileged Identity Manager [PIM] helps organizations manage, automate,

and track the use of shared privileged identities. Privileged Identity
Manager [PIM] provides the following features:
 Centralized administration, secure access, and storage of privileged
shared account credentials
 Role-based access control for shared accounts
 Lifecycle management of shared accounts ownership
 Single sign-on through automated check-out and check-in of shared
credentials
 Auditing of shared credentials access activities
 Session recording and replay

© 2019 IBM Corporation 254

Enterprise IAM Training Module

UNIT 13: IAM ON CLOUD

© 2019 IBM Corporation 255

Enterprise IAM Training Module

CHAPTER 17: Cloud IAM

Introduction

Organizations are faced with providing secure authentication, authorization, and

Single Sign On (SSO) access to thousands of users accessing hundreds of
disparate applications. Ensuring that each user has only the necessary and
authorized permissions, managing the user’s identity throughout its life cycle, and
maintaining regulatory compliance and auditing further adds to the complexity.
These daunting challenges are solved by Identity and Access Management (IAM)
software.

Traditional IAM supports on-premises applications, but its ability to support

Software-as-a-Service (SaaS)-based applications, mobile computing, and new
technologies such as Big Data, analytics, and the Internet of Things (IoT) is
limited. Supporting on-premises IAM is expensive, complex, and time-
consuming, and frequently incurs security gaps.

Identity as a Service (IDaaS) is an SaaS-based IAM solution deployed from the

cloud. By providing seamless SSO integration to legacy on-premises applications
and modern cloud-based SaaS applications, Platform as a Service (PaaS) and
Infrastructure as a Service (IaaS) resources, mobile, Big Data, and the IoT, IDaaS
provides end-to-end enterprise IAM services. Via the cloud,
organizations gain simplified IT architecture, faster deployments, lower total cost
of ownership (TCO), and enhanced capabilities enabling digital transformation.

 Evolution of IAM over the Years

IAM has evolved over the years in response to IT and business

needs. During the first generation of computer systems, IAM was
conceptually simple:
 Limited in scope with a focus on users, with only usernames and passwords
for traditional employees
 Relatively few users and even fewer applications; each account was unique
to a specific application
 Users and applications were located on-premises with little remote
computing
 Fewer regulatory controls, auditing requirements, and security concerns

© 2019 IBM Corporation 256

Enterprise IAM Training Module

IAM evolved as a discipline and technology with these present fundamentals:

 User life cycle management with provisioning and deprovisioning
 Role-based and fine-grained access control
 Centralized Directory Services (DS) such as Lightweight Directory Access
Protocol (LDAP) and Microsoft Active Directory (AD).
 Movement toward centralized identities and federated access with Single
Sign On (SSO) access into applications
 Strengthened password protections for length, passphrases, One-Time
Passwords (OTP)
 Strong authentication mechanisms including Multifactor Authentication
(MFA) and biometrics
 Enhanced governance, auditing, monitoring, and security controls

As a result, the third generation of IT brought IAM its own set of

challenges:
 Multiple siloed on-premises IAM solutions adding cost and complexity; no
single IAM solution for the enterprise.
 Reactive, iterative improvements resulting in piecemeal patchwork
architecture; difficult to secure and manage
 Frequently supporting different applications for provisioning,
authorization, access control, governance, auditing, and security
monitoring; too often building applications with governance and auditing
as an after-thought
 Overemphasis on legacy and on-premises applications with limited
capability for distributed mobile users, cloud-based applications, or
business-to-business applications

Increasingly, traditional on-premises IAM solutions are now coupled with cloud-
based IAM to more effectively support the rapidly evolving nature of digital
transformation and computing requirements.

 Diving into IAM

Modern IAM solutions build on previous generations of software, but they’re

more expansive in their scope (process and technology).

One can expect these features from today’s IAM solutions:

 Strong access management controls for authentication and authorization,
ensuring only the right people get access into applications with the correct

© 2019 IBM Corporation 257

Enterprise IAM Training Module

permissions and within defined usage parameters (time, location, source

address, and so on).
 Single Sign On (SSO) technology and federated access, allowing a user’s
identity to be used across a wide spectrum of applications without the need
to login multiple times with different accounts and passwords (a security
risk)
Cloud Identity enables SSO support for all applications, including on-premises
and cloud.

 Defining the Cloud Paradigm

Cloud computing is a model for enabling ubiquitous, convenient, on-demand

network access to a shared pool of configurable computing resources (for
example, networks, servers, storage, application, and services) that can
be rapidly provisioned and released with minimal management
effort or service provider interaction.
Cloud computing providers offer computing resources as services.
Cloud computing providers make their services available to customers
who are subscribers or consumers. By leveraging a metered pay-as-you-go
model, consumers identify the service(s) they require and then select the
provider(s) offering desired capabilities and price.

Available cloud computing resources are categorized “as a Service”

with three general service models as defined by NIST with these generally
accepted definitions:

 Software as a Service (SaaS): Consumers are provided their software

applications from the cloud service provider. The consumer gains access
to application software while the provider manages the underlying
software and infrastructure used to provide that application software.
 Platform as a Service (PaaS): Consumers use programming languages,
libraries, and tools from the provider as an application development and
deployment platform.
 Infrastructure as a Service (IaaS): Cloud service provider manages the
underlying physical infrastructure (servers, networking, storage, operating
systems) while the consumer deploys and runs their own application
software.

© 2019 IBM Corporation 258

Enterprise IAM Training Module

 Cloud Deployment Models

NIST recognizes four different cloud deployment models:

 Private clouds: Used exclusively for a single, private organization but may
support multiple internal consumers; widely considered the most secure
deployment model
 Public clouds: Used by multiple, unrelated organizations on a shared
basis; very common deployment model, particularly for SaaS applications
 Community clouds: Used by organizations with a common purpose,
mission, or audience
 Hybrid clouds: A combination of two or more cloud models (private,
public, and community)
The industry frequently uses this term to define a combination of traditional on-
premises and off-premises hosting options; essentially on-premises combined
with any cloud model.

Introducing IDaaS

IDaaS is a cloud-based implementation of IAM. As a cloud-based offering,

several core characteristics are required and should be expected regardless of
vendor:
 SaaS offering providing all the benefits of cloud computing
architecture:
Although the cloud service provider is maintaining IAM on its infrastructure, this
deployment model is SaaS (not IaaS or PaaS) as the consumer only accesses the
IAM software via approved interfaces (web browsers, APIs, and so on) and is not
responsible for management or maintenance of cloud-based assets.
 Multitenant architecture with multiple customers sharing the same cloud
IAM infrastructure in a secure manner: This distinction ensures that
customers are indeed receiving cloud-deployed solutions rather than on-
premises IAM deployed from another hosting provider (masquerading as
cloud).
 Hybrid support of on-premises and cloud-based applications:
Organizations have on-premises applications but also distributed, mobile, and
cloud-hosted applications; IDaaS solutions support an increasing number of on-
premises applications.
The ability of cloud-based applications to reach down into consumers’ data
centers, outward to their mobile users, and across to other cloud-based

© 2019 IBM Corporation 259

Enterprise IAM Training Module

applications (hosted via SaaS, PaaS, or IaaS) is a powerful capability inherent to

mature IDaaS solutions.

In Figure , you see a representative IDaaS implementation

supporting applications in different environments.

Figure: Deploying IDaaS across applications with Cloud Identity.

Because IDaaS is hosted from the cloud, it supports applications regardless of

their location or topology:
 On-premises enterprise users
 Mobile users located anywhere on the globe
 Web-based or SaaS applications such as MS Office 365, Salesforce,
Google Apps, Workday, or ServiceNow
 Applications hosted in IaaS or PaaS cloud environments
IDaaS is powerful because as a SaaS application, it has the ability to reach
anywhere there is a network (even wireless) connection without the need for
hardware at the customer site.

 Understanding IDaaS Advantages

IDaaS provides relief to those managing data centers and frustrated with many
challenges of on-premises applications. Many of the challenges encountered by
those managing IAM solutions in their own environments are negated with
IDaaS.
IDaaS solutions provide customers relief from the overhead of infrastructure
support, specialized staffing, providing consistent deployments, and maintenance

© 2019 IBM Corporation 260

Enterprise IAM Training Module

and upgrades. As you evaluate IDaaS, be sure to factor the benefits in this section
into your decision matrix with their associated savings.

1. Infrastructure
IDaaS solutions don’t require servers, storage, or other infrastructure
installed and maintained at the consumer’s location; everything
is hosted from the cloud. For IDaaS, the only client side equipment
required is smart card readers or biometric devices on workstations
if MFA is utilized, but those devices are necessary regardless
of IDaaS or IAM. The benefit to the consumer is that there are no
capital expenditures (CAPEX) on hardware or infrastructure.

2. Staffing
IDaaS transfers administrative support from the consumer to the
cloud service provider. The infrastructure administrative duties
such as installation and configuration are already performed by the
cloud service provider at the multitenant level for all consumers;
the cloud provider staff performs these tasks for everyone. Application
level configuration specific to the customer’s application
environment may still be performed by the consumer, but wizards
and templates ensure that the “heavy lifting” is no longer required.
The consumer reaps the benefit of highly skilled, on-premises staff
being freed up to support other business-centric initiatives.

3. Deployment
IDaaS solutions are automatically deployed via the cloud by using
a standardized multitenant architecture. When a new consumer
starts its service, a new IDaaS environment is provisioned in the
cloud by using virtualization and cloning technologies. A standardized
baseline IDaaS image at the latest version and security
patch level is then customized via the consumer using selfservice
portal access, wizards, and templates.
The benefit of a standardized deployment process ensures that
the consumer is provided a secured, standardized, and baselined
environment so he can start his application specific customizations
sooner and at less risk.

4. Maintenance and upgrades

IDaaS solutions shift the overhead and complexity of mundane
maintenance and upgrade tasks to the cloud service provider. As
a SaaS application, these duties are transferred from the consumer
to the cloud service staff. Centralizing these operations

© 2019 IBM Corporation 261

Enterprise IAM Training Module

outside the responsibility of the consumer ensures that the IDaaS

software and consumers’ data and configurations are regularly
patched and upgraded to the latest version and security release,
properly backed-up and replicated to the Disaster Recovery (DR)
environment, and tuned for optimal performance and efficiency.
The benefits are that the maintenance and upgrade workload is
shifted to cloud staff specializing in these duties, which removes
the burden from the consumer’s IT staff.

 Planning Your IDaaS Strategy

Identity as a Service (IDaaS) performs complex tasks and performs critical

functions, but much of this is masked from consumers and users. Without going
into deep detail, it is beneficial to have a working understanding of the “magic
behind the curtain.”
Organizations come to IDaaS with different support requirements ranging from
on-premises legacy applications, hybrid mixed workloads, and cloud-only
implementations. Regardless of customer requirements, all can benefit from a
refined checklist of critical capabilities and best practices.

The benefits of IDaaS for on-premises consumers include

 Enhanced end-to-end capability, eliminating siloed IAM solutions,
ensuring a secure governance, risk, and compliance (GRC) solution, and
simplifying the landscape
 Elimination of infrastructure and support requirements for on-premise
IAM solutions resulting in lower cost
 Laying the foundation for expansion into future cloud services by creating
an IDaaS capability

Many organizations have a cloud footprint, but for those without,a SaaS solution
such as IDaaS is a good way to start.

The benefits of IDaaS for these consumers are

 End-to-end capability and no support of on-premises infrastructure and
staffing for traditional IAM.

© 2019 IBM Corporation 262

Enterprise IAM Training Module

 Simplified implementation and deployment for private web, mobile, and

SaaS applications
 Accelerated delivery of new applications for customers in the B2C, B2B,
B2E, and B2IoT spaces
 Robust GRC and IGA for the enterprise that’s secure and auditable
 Self-service portals and employee launch pads for speed and convenience

 Hybrid environments
Organizations with a combination of on-premises and cloudbased applications
are hybrid implementations. A majority of companies haven’t or can’t move all
their on-premises applications to the cloud (for a variety of reasons), but they’re
leveraging cloud for commodity-based or new technology applications.
Hybrid environments are also the most complex environments to support, but
they benefit greatly from IDaaS:
 Simplified end-to-end cloud-based IAM for the enterprise across on-
premises and cloud-hosted applications
 Elimination of siloed piecemeal IAM solutions that are costly, complex,
and have gaps in coverage
 Standardized and consistent IAM services for all types of customers
regardless of applications utilized
 Self-service portals and employee launch pads to consolidate and
simplify application access
 Accelerated access to new capabilities via SaaS and mobile applications
while maintaining access to legacy applications
Providing an end-to-end enterprise-level solution for IAM is the strength of
IDaaS solutions. Hybrid environments are particularly well suited for IDaaS to
reduce complexity and costs for on premises applications and extend
functionality into the cloud for modern SaaS applications.

 Planning Your Success with IDaaS

Prior to implementing IDaaS, developing a plan is essential for success. With a
foundational knowledge of cloud and IAM functions and technologies, the steps
of planning for IDaaS are straightforward.

Your checklist should include:-

 Scope and capabilities: How deep into your application stack do you want
to extend IDaaS, and what do you want to achieve? IDaaS is designed to

© 2019 IBM Corporation 263

Enterprise IAM Training Module

protect on-premises applications, but you must consider organizational

constraints for how far you can implement cloud-based IAM.
 Governance and management responsibilities: What are the current
rules and responsibilities, and how will those change with IDaaS? Positive
organizational change and shifts are part of IDaaS and must be part of the
planning process.
 Web access requirements: Who will access IDaaS supported systems,
and where are the users located? Perform your due diligence and
homework to know what ports, protocols, network access restrictions, and
security requirements exist for the full population of your users (not just
those in the office).
 Mobile and cloud users: What mobile and cloud applications and users
do you have today and will have in the near future? Large legacy
applications with thousands of users get all the attention; however, you
must account for the mobile and cloud applications that you don’t
necessarily host but are critical to your users.
 Auditing, reporting, and compliance requirements: What
organizational and industry specific compliance regulations must be
accounted for? IDaaS brings powerful GRC and IGA capabilities, but your
organization has specific requirements that must be supported. Ensure that
your compliance experts are part of the planning sessions early on to ensure
the IDaaS solution meets their needs.
 Policies, standards, and strategies: What are the current recommended
and regulatory requirements for access control, account and password
management, and monitoring and auditing? This is an excellent time to
ensure that your practices and policies are meeting the standards and if not,
to bring them up to the latest requirements.

© 2019 IBM Corporation 264

Enterprise IAM Training Module

Appendix

When auditing identity and access management (IAM), the following checklist
is a high-level overview and is not intended to be a comprehensive audit
program or address all IAM-related risks.
Audit Question/Topic Status
1. Is there an IAM strategy in place?
A critical element for an effective IAM process is
the presence of a consistent approach to manage
the supporting information technology (IT)
infrastructure. Having a cohesive
strategy across the organization will enable all
departments to manage people, their identities,
and the access they need using similar processes,
if not necessarily with the same technology.
• Inquire about current IAM strategies in the
organization.
• If they exist, determine how and by whom they are
managed.
2.Are the risks associated with the IAM
process well understood by management and
other relevant individuals? Are the risks
addressed by the strategy?
Simply having a strategy does not ensure it covers
all the risks that IAM may present. It is important
that the strategy contains elements that identify
all relevant risks.
• Determine whether a risk assessment of
established IAM processes was conducted.
• Determine how risks are identified and addressed.
3.Is the organization creating or changing an
IAM process only to satisfy regulatory
concerns?
It is critical that IAM processes are integrated
with broader business issues and strategies. There
are numerous benefits to having a robust IAM
environment, such as having a better internal
control environment.
• Determine the needs of the organization with
respect to IAM.

© 2019 IBM Corporation 265

Enterprise IAM Training Module

• Determine whether the IAM processes extend

into the organizaton or just meet an external third-
party requirement.
4. Are the regulations governing the
organization well understood?
New regulations are being created, and for large
multinational organizations, it can be difficult to
identify all of the regulatory requirements with
which the organization must comply.
• How does the organization determine the
regulatory requirements it must meet?
• How does the organization remain current with
these regulations?
• How does the organization capture, store, and retrieve
this information?
5.Is the IAM environment centralized or
distributed appropriately to reflect the
structure of the organization?
An ideal technical situation would be to have a
single software solution with consistent processes
clearly documented and managed through a
single implementation tool. However, due to the
challenges associated with legacy system
integration and the modification of processes
used to grant approvals, these technologies have
not lived up to their potential.
• If multiple IAM solutions exist, how are they
managed to identify, prevent, or detect
unauthorized or unnecessary permissions granted
to users?
6. How are password policies established, and
are they sufficient for the organization?
Policies that govern IAM processes are critical
components of any effective solution. Therefore,
it is important to understand how the policies are
established, how they are communicated, and
how the technology elements of the environment
support their compliance.
• What password parameters have been established
for companywide applications?
• Are they consistently applied?
• How are changes to these parameters controlled?

© 2019 IBM Corporation 266

Enterprise IAM Training Module

7. How is information logged, collected, and

reviewed?
It is important to understand what types of events
are logged, where they are captured, and how
frequently they are reviewed.
• Determine whether the organization uses event
logging with respect to IAM.
• If event logs are used, determine when and how
they are reviewed.
• If logs are reviewed and discrepancies are
discovered, how are these items resolved?

© 2019 IBM Corporation 267