Large Scale User Provisioning With Hiim

Large Scale User Provisioning
with Hitachi ID Identity Manager

2014 Hitachi ID Systems, Inc. All rights reserved.
This document introduces the business problems of user life-cycle management: slow and complex on-
boarding; redundant administration effort; slow and unreliable deactivation; excess security entitlements
and inconsistent user prole data. It then describes how Identity Manager addresses these problems using
streamlined business processes built on integrated technology. Finally, the benets of enabling automation
and self-service to improve user and security management processes are described.
Contents
1 Introduction 1
2 Business Challenges in Identity and Entitlement Management 2
3 Shared Infrastructure for Identity Management 4
3.1 Shared user directory (LDAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Shared management layer (IDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Streamlined User and Entitlement Management Processes 6
4.1 User life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Integrations and Manual Fulllment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1 Built-in Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.2 Scriptable Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.3 Implementer Workows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5 Hitachi ID Identity Manager Technology 10
5.1 Auto-Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 ID Mapping / Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Unique Approach to Workow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4 Role Based Access Control and Segregation of Duties . . . . . . . . . . . . . . . . . . . . . 13
5.5 User Classes: Sets and Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.7 High-Performance, High-Availability Database Architecture . . . . . . . . . . . . . . . . . . . 19
6 Return on Investment 20
i
Large Scale User Provisioning with Identity Manager
1 Introduction
This document introduces the business problems of user life-cycle management: slow and complex on-
boarding; redundant administration effort; slow and unreliable deactivation; excess security entitlements
and inconsistent user prole data. It then describes how Hitachi ID Identity Manager addresses these prob-
lems using streamlined business processes built on integrated technology. Finally, the benets of enabling
automation and self-service to improve user and security management processes are described.
Identity Manager is the user provisioning component of the Hitachi ID Management Suite.
The remainder of this document is organized as follows:
Business Challenges in Identity and Entitlement Management
The motivation for deploying Identity Manager.
Shared Infrastructure for Identity Management
How the intersection of many systems with many business processes create complexity and how
implementing shared processes to manage users and entitlements helps.
Streamlined User and Entitlement Management Processes
Best practices for faster, simpler and more reliable processes to manage users and entitlements
across the enterprise.
Identity Manager Technology
The architecture and integrations that enable scalable, secure and manageable user management
processes.
Return on Investment
A basic cost savings calculation that can be used to justify investment in Identity Manager.
2014 Hitachi ID Systems, Inc.. All rights reserved. 1
Large Scale User Provisioning with Hitachi ID Identity Manager
2 Business Challenges in Identity and Entitlement Management
Several factors combine to make management of users and their security entitlements a growing challenge
for many organizations:
The number of systems and applications that users need to sign into is large and growing.
String regulatory requirements create additional administration burden.
Organizations cannot afford to increase IT support staff to cope with the ever-growing work-load.
This complexity is illustrated in Figure 1.
Business Processes
Systems and Applications
Users
Passwords
Groups
Attributes
IT Processes
Hire Retire New Application Retire Application Resign Finish Contract
Application Operating
System
Database Directory E-mail
System
ERP Legacy
App
Mainframe
Transfer Fire Start Contract Password Expiry Password Reset
Figure 1: Managing Each Application in its own Silo
The impact of this complexity is straightforward business problems:
Security and regulatory compliance:
The access deactivation process may be slow or unreliable, allowing users who have left the
organization to retain access.
Access to privileged accounts, such as Administrator, root or sa is not consistently secured,
leading to weak accountability and access to critical systems retained by departed users.
Users accumulate security entitlements over time, ending up with the ability to commit fraud or
other abuses.
IT support cost:
The IT support group must respond to a large volume login- and access-related calls.
A large number of security administration staff are needed to setup, manage and tear-down user
access in response to a changing organization.
User service:
It is difcult for users to gure out how to request access for new or reassigned users.
It takes too long to authorize and provision needed access rights.
Users must manage too many passwords and ll in too many login prompts.
3 Shared Infrastructure for Identity Management
To resolve the business problems that arise from the complexity introduced in Figure 1, it makes sense
to implement a shared infrastructure for managing users and security entitlements. This is illustrated in
Figure 2.
Business Processes
Systems and Applications
Users
Passwords
Groups
Attributes
IT Processes
Hire Retire New Application Retire Application Resign Finish Contract
Application Operating
System
Database Directory E-mail
System
ERP Legacy
App
Mainframe
Transfer Fire Start Contract Password Expiry Password Reset
Identity Management System
Figure 2: Externalizing the Management of Users and Entitlements
Using this approach, the links that connect every process to every system are severed, replaced with links
between each process and a shared IDM system, plus links between that system and each integrated
application. If before there were N processes, M applications and N M links (chaos!), now there are just
N +M links much more manageable.
A shared infrastructure for users and entitlements can take on different forms, each of which has merit and
all of which can be combined.
3.1 Shared user directory (LDAP)
The rst approach to consolidating identity and access management removing this function from appli-
cation silos and moving it to a shared infrastructure is to use a directory. Applications should then be
congured to externalize user identication, authentication and authorization information to the directory.
This approach has merit, hence the popularity of LDAP. It also has limitations:
Many systems are not compatible with LDAP, and cannot externalize their user/security databases.
Some systems that can externalize user data can only do so for some attributes, and continue to have
internal user proles, which must still be managed directly.
Many systems require data about users that is special to them, and would not benet any other part
of the IT infrastructure. If the data storage requirements of every application were added to a single
LDAP directory, then the schema would grow to thousands of attributes per user clearly not practical.
Some user-related data is condential, and does not belong in a directory whose main design function
is to publish data.
Because of these limitations, LDAP has helped to slow the proliferation of user databases but organizations
still have multiple systems to manage.
3.2 Shared management layer (IDM)
Where the physical user directory cannot be consolidated, it makes sense to at least consolidate the pro-
cesses that create, modify and delete users and entitlements on multiple systems. This is the function
of a user provisioning system to implement consistent processes which manage users and entitlements
across multiple, heterogeneous directories of users and entitlements.
Hitachi ID Identity Manager is designed to provide a shared set of processes and infrastructure to manage
users and access across heterogeneous systems. It implements multiple processes that an organization
can use to provision, update and deactivate user access to multiple systems.
4 Streamlined User and Entitlement Management Processes
4.1 User life-cycle
User movement through an organization is referred to as the user life-cycle. The processes involved vary
from one classication of user to another and sometimes from one individual to another. For example,
employees and contractors typically have different life-cycles. The process is referred to as a life-cycle,
to emphasize that users who have left an organization may later return. The user life-cycle is illustrated
graphically in Figure 3.
Figure 3: User Lifecycle Management
In the context of an identity management system, the user life-cycle has external inputs and observable
outputs. Inputs are typically business events: hire an employee or contractor, change departments, termi-
nate a user, etc. Outputs are the changes made on integrated systems and applications to reect changing
needs: create a login ID, disable a login ID, add or remove security entitlement, etc.
Every user life-cycle begins with an on-boarding event a new-hire for employees, start-of-engagement for
contractors, sign-up for customers and partners, enrollment for students, etc. This business event triggers
creation of one or more login accounts and other objects for the user in question.
Over time, users will make routine password changes and may periodically forget or lock out their pass-
words, leading to a need for IT support (password reset or clear lockout).
As users move through an organization, they may change job functions, projects, locations, etc. These
business events often trigger the need for changing access rights. In other words, their access rights need
to be managed over time.
All users leave eventually and their access rights must be deactivated. In many cases, objects belonging
to the user home directory with les, mail folder with archives messages, etc. may have to be retained
for a period of time before they are permanently deleted. Some data about users, such as their unique
identiers, and whether it is OK to re-hire them, may be retained indenitely, for future reference.
In some cases, a user who has departed will return to the organization and need to be re-activated, hence
the cycle in the user life-cycle.
Without automation, each of the above processes is handled separately, with no link between processes
and with unique processes implemented for each system and application, managed by different IT staff,
using different access administration tools. This is what leads to the complexity illustrated in Figure 1.
4.2 Business Processes
Hitachi ID Identity Manager implements several types of business processes when managing users:
Auto-provisioning:
Detect new user records on a system of record (such as HR) and automatically provision those users
with appropriate access on other systems and applications.
Auto-deactivation:
Detect deleted or deactivated users on an authoritative system and automatically deactivate those
users on all other systems and applications.
Identity synchronization:
Detect changes to personal data, such as phone numbers or department codes, on one system and
automatically make matching changes on other systems for the same user.
Self-service requests:
Enable users to update their own proles (e.g., new home phone number) and to request new entitle-
ments (e.g., access to an application or share).
Delegated administration:
Enable managers, application owners and other stake-holders to modify users and entitlements within
their scope of authority.
Access certication:
Periodically invite managers and application owners to review lists of users and security entitlements
within their scope of authority, agging inappropriate entries for further review and removal.
Authorization workow:
Validate all proposed changes, regardless of their origin and invite business stake-holders to approve
them before they are applied to integrated systems and applications.
Consolidated reporting:
Provide data about what users have what entitlements, what accounts are dormant or orphaned,
change history, etc. across multiple systems and applications.
4.3 Integrations and Manual Fulllment
Once a business process has produced a change that should be applied to an application, one of several
processes should push the change to the system in question. There are three ways to do this use a
built-in connector, use a scripted integration or ask a human being to make the change.
4.3.1 Built-in Connectors
Hitachi ID Identity Manager comes with built-in connectors for most common systems and applications, as
illustrated in Figure 4.
Directories: Servers: Databases:
Any LDAP, AD, NDS,
eDirectory, NIS/NIS+.
Windows 20002012,
Samba, NDS, SharePoint.
Oracle, Sybase, SQL Server,
DB2/UDB, ODBC, Informix.
Unix: Mainframes: Midrange:
Linux, Solaris, AIX, HPUX,
24 more variants.
z/OS with RAC/F, ACF/2 or
TopSecret.
iSeries (OS400), OpenVMS.
ERP: Collaboration: Tokens, Smart Cards:
JDE, Oracle eBiz,
PeopleSoft, SAP R/3, SAP
ECC 6, Siebel, Business
Objects.
Lotus Notes, Exchange,
GroupWise, BlackBerry ES.
RSA SecurID, SafeWord,
RADIUS, ActivIdentity,
Schlumberger.
WebSSO: Help Desk: HDD Encryption:
CA Siteminder, IBM TAM,
Oracle AM, RSA Access
Manager.
BMC Remedy, BMC SDE,
ServiceNow, HP Service
Manager, CA Unicenter,
Assyst, HEAT, Altiris, Clarify,
Track-It!, RSA Envision, MS
SCS Manager.
McAfee, CheckPoint,
BitLocker, PGP.
SaaS: Miscellaneous: Extensible:
Salesforce.com, WebEx,
Google Apps, MS Ofce
365, SOAP (generic).
OLAP, Hyperion, iLearn,
Cach, Success Factors,
VMWare vSphere.
SSH, Telnet, TN3270,
HTTP(S), SQL, LDAP,
command-line.
Figure 4: Target system types supported by Identity Manager
4.3.2 Scriptable Connectors
Hitachi ID Identity Manager includes a number of exible connectors, each of which is used to script in-
tegration with a common protocol or mechanism. These connectors allow organizations to quickly and
inexpensively integrate Identity Manager with custom and vertical market applications. The ability to quickly
and inexpensively add integrations increases the value of the Identity Manager system as a whole.
There are exible connectors to script interaction with:
API binding: Terminal
emulation:
Web services: Back end
integration:
Command-line:
C, C++
Java, J2EE
.NET
COM,
ActiveX
MQ Series
SSH
Telnet
TN3270,
TN5250
Simulated
browser
SOAP
WebRPC
Pure
HTTP(S)
SQL
Injection
LDAP
attributes
Windows
Power Shell
Unix/Linux
Organizations that wish to write a completely new connector to integrate with a custom or vertical market
application may do so using whatever development environment they prefer (J2EE, .NET, Perl, etc.) and
invoke it as either a command-line program or web service.
If the organization develops their own integrations, an effort of between four hours and four days is typical.
Alternately, Hitachi ID Systems offers xed-cost custom integrations for a nominal fee.
4.3.3 Implementer Workows
Hitachi ID Identity Manager supports the notion of an implementer-style target system, where a human
system administrator is asked to create, modify or delete a user object on the target system, in place of an
automated Identity Manager connector.
Implementer-style target systems are useful in two main circumstances:
1. A custom or vertical-market target system either has a very small or very static user population. In
these cases, the level of effort required to deploy automated integration to manage users on the target
system (typically on the order of several days) is not warranted given the small pay-back.
2. There are many target systems (hundreds, thousands) in-scope for the project and it is desirable to
give users a one stop shop experience for security change requests, using Identity Manager, at the
start of deployment. This is preferable to asking users to refer to different request systems depending
on what kind of access they require.
5 Identity Manager Technology
5.1 Auto-Discovery
Hitachi ID Identity Manager includes an auto-discovery engine, which typically extracts information about
users and groups from target systems nightly.
An auto-discovery engine extracts a full inventory of login IDs, from each target system, nightly.
The auto-discovery engine extracts a list of all available groups from each target system, nightly.
For groups that have been designated as managed, the auto-discovery engine also extracts full
group membership from the target systems.
The auto-discovery engine automatically creates, updates and removes user proles in the internal
Identity Manager database, based on the appearance of user accounts on systems that are consid-
ered authoritative sources of Identity Manager IDs.
Information such as last-login-date is used to identify dormant accounts, globally.
Identity attributes congured as managed in Identity Manager are read from each target system, into
the Identity Manager identity cache.
Auto-discovery is incremental on systems that support this such as Active Directory and most other LDAP
directories. A full extract is produced on systems where incremental listing is not supported, and a delta is
calculated on the Identity Manager server before being loaded into the Identity Manager database. .
5.2 ID Mapping / Reconciliation
Every enterprise identity management and access governance system, regardless of its features, must
support login ID reconciliation. Users have login accounts and other records on various systems and these
have to be attached to a single prole, in order to create a user-centric identity system. The process of
attaching non-standard login IDs and other user identiers to a single prole is called login ID reconciliation.
Hitachi ID Identity Manager supports multiple options for login ID reconciliation, as follows:
Automatically, typically by matching consistent login IDs.
By matching other attributes such as an SSN or employee ID, where they are available.
By drawing on an external source of data for example, some organizations maintain a mapping table
or spreadsheet.
Using a self-service reconciliation process.
When self-service login ID reconciliation is required, it works as follows:
Users are automatically invited to complete their proles for example via an e-mail with an embedded
URL.
Users sign into the registration system, using a primary login ID and password or other types of
credentials.
Users are asked to type their additional ID/password pairs. Each provided ID/password pair is com-
pared against an automatically maintained inventory of login IDs drawn from target systems, to nd
instances where the user-entered login ID appears on a system and does not yet belong to a known
user prole. Identity Manager then attempts to sign into that system with the user-entered password.
If the login attempt succeeded, the users prole is updated with the system ID and the user-entered
login ID.
Self-service reconciliation is inexpensive (about 5 minutes per user), reliable, fully automated (users are
reminded to register until they actually do) and very secure.
Both self-service and administrative login ID reconciliation are logged. Other forms of login ID reconciliation
are typically batch oriented and can be congured with logging if required.
Note that attempts to reconcile login IDs by matching on attributes of user proles on target systems are
often costly and/or insecure, especially when combined with a password management system:
The only attribute that is commonly available on every system is a users full name. This may be
inconsistent across systems and in many large organizations multiple users share the same full name
and sometimes the same location.
Failure to automatically correlate an account leads to manual, administrative reconciliation, which is
expensive.
Incorrect ID mapping allows one user to set another users password, which is a serious breach of
security.
Where self-service login ID reconciliation is required, the process is both inexpensive (25,000 users spend-
ing 5 minutes each costs nothing, while one consultant spending weeks or months is expensive) and error-
free (since IDs are claimed with a validated password). This process is, to the best of Hitachi ID Systems
knowledge, unique.
5.3 Unique Approach to Workow
Hitachi ID Identity Managers workow automation engine streamlines the process of requesting and au-
thorizing the creation of new accounts, as well as other security changes such as adding/removing group
membership, changing attribute values, renaming or moving accounts, deleting or deactivating accounts
and so on.
The Identity Manager workow engine accepts change requests from the Identity Manager web portal, the
Identity Manager web services API or the auto-provisioning engine. Its main task is to validate change
requests and manage authorization of changes by business users, who are invited to review requests via
e-mail and provide approval via the web portal.
Workow in Identity Manager is loosely coupled, in the sense that request input (API, automation, web
portal) is separated from form validation, which in turn is separated from authorizer selection and related
logic, which is separated from the process used to invite participants to respond to a change request. This
loosely coupled architecture signicantly simplies conguration and maintenance by encouraging code
reuse.
The workow automation engine works as follows:
Request input:
Users can authenticate to the system and make change requests.
Third party programs can submit change requests via a web services API.
The unattended Identity Manager process used to implement auto-provisioning, auto-deactivation
and identity synchronization can submit change requests programmatically.
Change requests are formulated as changes to user proles the requesters own (self-service)
or another users (the recipient).
Change requests may be to update prole attributes, add new accounts, add or remove group
memberships, enable or disable accounts, etc.
Plug-in programs can limit or alter requests for example by limiting who can submit a given type
of request, for whom they can make requests and by validating or populating the contents of a
request.
Request routing:
Requests are automatically routed to appropriate authorizers, which are selected based on the
identities of the requester and recipient plus the specied operations and resources.
All authorizers are invited at the same time.
1. Authorizers may delegate their responsibility in advance if they plan to be unavailable for an
extended period.
2. Identity Manager can check an authorizers out-of-ofce status in an e-mail system (example:
Exchange) and preemptively escalate the request to someone else.
In most cases, a response is only required from a subset of the authorizers for example, any
one of three people can approve a new account on a given application.
Authorizers are notied by e-mail that their input is required. They click on a URL embedded in
the e-mail to respond.
Reminders are sent to non-responsive authorizers.
If an authorizer fails to respond after too many reminders, a new authorizer is selected by esca-
lation logic.
Authorization:
Authorizers review requests using a web form, over a secure connection (HTTPS).
Authorizers normally have to sign in before they can approve a request.
Executing approved requests:
Once sufcient approvals has been collected, Identity Manager will generally apply the requested
changes to target systems.
For un-integrated systems, Identity Manager can execute a separate workow process to invite
implementers (typically system administrators) to make the approved change manually. Re-
minders, escalation and delegation apply to this workow as well.
The built-in workow engine is designed to get quick and reliable feedback from groups of business users,
who may be individually unreliable. It supports:
Concurrent invitations to multiple users to review a request.
Approval by N of M authorizers (N is fewer than M).
Automatic reminders to non-responsive authorizers.
Escalation from non-responsive authorizers to their alternates.
Scheduled delegation of approval responsibility from unavailable to alternate approvers.
5.4 Role Based Access Control and Segregation of Duties
Hitachi ID Identity Manager includes a complete infrastructure for managing user entitlements using role
based access control (RBAC).
Dene Roles:
Administrators dene roles in Identity Manager as collections of:
Login accounts on specied target systems.
Membership in groups on target systems.
Role Hierarchy:
In addition to entitlements on target systems, roles can include other roles. This allows organizations
to dene:
Technical roles, consisting of entitlements on target systems.
Business roles, consisting of other roles.
Mandatory and Optional Components:
Roles may contain both mandatory and optional entitlements. Users who are assigned a role will,
in general, be assigned all of the mandatory elements in a role. In addition, users who have been
assigned a role may request any of its optional components, which will be granted without need for
additional approvals.
Role Assignment:
Users can be assigned zero or more roles:
Some users can be outside the scope of the RBAC (role-based access control) infrastructure.
Other users can be assigned exactly one role, representing their singular job function.
Still other users can be assigned multiple roles, representing multiple job functions.
Manual and Rule-based Assignment:
Roles may be assigned via a request process i.e., a requesting user U
q
asks that a receiving user
U
p
be assigned role R
x
. Such requests may be subject to policy and human approval before being
completed.
Roles can also be assigned automatically, by dening a class of users who should be assigned a
given role and associating that class with the role. In this case, both on a batch basis (e.g., nightly),
with a throttle mechanism, and as user proles are altered in a manner that changes their qualication
for the user class, roles are automatically assigned or revoked.
Role-based Change Requests:
Requests to create new user proles can specify a role either instead of or in addition to other
entitlements that the new user should be provisioned.
Requests relating to preexisting users can include role changes. Role changes may cause entitle-
ments to be added, removed or left in place.
Approved Exceptions:
Some users may have a legitimate reason to retain privileges beyond those called for in their assigned
roles or may not need all of the privileges in that role. Identity Manager supports users who remain
legitimately out of compliance, through approved exceptions to role-based security entitlements.
Controlled Enforcement:
Users can be agged for role-based access control (RBAC) enforcement. This means that any
entitlements they have in violation of their assigned roles either too many or too few can be
detected and automatically remediated.
Cascading Changes:
Identity Manager includes an RBACenforcement engine, which is normally run as batch process every
24 hours. This engine can detect users whose actual security entitlements are out of compliance with
the entitlements that their assigned roles predict. This may be because changes were made to their
proles outside of Identity Manager, or because the roles denition has changed.
The RBAC enforcement engine detects non-compliant users and automatically submits workow
change requests to bring users back into compliance.
One of the use cases this supports is cascading role changes: an administrator can change a roles
denition and commit the change. On the next automated enforcement run, the RBAC automation
engine will automatically submit workow requests to bring users into compliance with the new role
denition. These requests may be auto-approved (depending on the organizations policy), which
means that they may be applied to target systems immediately.
Gradual Deployment:
It is impractical to deploy RBAC enforcement to every one of a large population of users, all at once.
To avoid this, Identity Manager supports gradual activation of users for RBAC enforcement, allowing
time to educate users about the new system and troubleshoot errors in the RBAC model for a few
users at a time.
Role-Aware Access Certication:
Identity Manager supports certication of user entitlements at several levels of granularity:
Fine-grained entitlements assigned to users many checkboxes, based on data pulled directly
from target systems.
Roles assigned to users fewer checkboxes, representing groups of privileges.
Approved exceptions to the privileges predicted for a user by policy, where the policy may be role
assignment or a segregation of duties rules.
Identity Manager includes what is probably the most advanced segregation of duties (SoD) engine available.
The Identity Manager SoD engine supports:
Policy denition:
An SoD rule is dened as a toxic sets of entitlements.
Entitlements that participate in the SoD rule may themselves be roles, login IDs on specied
target systems or membership in specic security groups.
Users who have at least N of the M SoD entitlements are considered to be in violation.
This is a very general model. It supports rules such as No user shall belong to more than 2 of these
30 groups.
Approved exceptions:
Users may be allowed to violate SoD rules, so long as an authorized person has approved the
violation.
Access certication is used to periodically renew approved SoD exceptions.
This is a practical model. It allows organizations to knowingly violate rules where there is a strong
business reason to do so and where suitable compensating controls are in place.
Proactive enforcement:
Identity Managers SoD engine is an integral part of the workow engine.
All change requests that pass through the Identity Manager workow engine must either:
1. Satisfy all SoD rules (i.e., violate none); or
2. Include a request for an approved exception to every violated rule.
Requesters via the Identity Manager UI, API or automation engine simply cannot ask for
violations without also asking for an approved exception.
SoD should be proactive rather than after-the-fact, wherever possible. This is supported by Identity
Manager.
Reporting on out-of-band and pre-existing violations:
There are several ways to bypass the Identity Manager pro-active SoD enforcement engine:
*
Pre-existing conditions, where a user violated the SoD rule before Identity Manager was
implemented.
*
Pre-existing conditions, where a user violated the SoD rule before the rule was added to
Identity Manager.
*
Out of band changes, made by administrators outside of Identity Manager.
In these cases, there is no general way for Identity Manager to know which of the offending
entitlements is inappropriate, so it cannot automatically remediate the violating users.
Instead, Identity Manager includes reports to identify violating users and help security staff make
appropriate remediating changes.
SoD reporting is the defense of last resort.
Deep inspection:
Consider an SoD rule: "no user may have roles R1 and R2."
Now assume that role R1 contains entitlements E1 and E2, while role R2 contains E3, E4.
Next, consider a user who already has E1, E2 and E3, but has never been explicitly assigned
R1. This user effectively has R1. If this user requests E4 or R2, the request should be agged
as an SoD violation.
The Identity Manager SoD engine, perhaps uniquely in the marketplace, will detect such vio-
lations. In general, it supports enforcement where SoD rules may cover any combination of
individual entitlements and nested roles.
To the best of Hitachi ID Systems knowledge, no other SoD engine will detect SoD violations where
the SoD rule is dened in terms of one level of the role hierarchy but the violation takes place at
another level. This means that other SoD engines in reality only give organizations a false sense of
security!
5.5 User Classes: Sets and Relationships
Hitachi ID Identity Manager includes a mechanism for classifying users individually or as they relate to
one another called user classes.
When applied to individual users, user classes can examine a users accounts, identity attributes or security
group memberships to decide whether a user is in a given class. For example, help desk users may be
members of an Active Directory group called it_support. Linux administrators may be in an LDAP OU
called ou=Admins and be members of an AD group called linux_experts.
User classes can also formalize relationships between users. For example, an organization may have a
regional IT support model, such that a given help desk user can only provide assistance, such as password
resets, to users in his region. This is supported by dening user classes that relate two users for example,
the helpdesk user must be a member of an AD group called it_support and both users must have the
same values in the Division and Country-Code attributes.
User classes have multiple uses:
1. They are used in the Identity Manager operational security model, to assign rights for managing
Identity Manager to users.
2. In the delegated user administration security model, they determine what a given user can do on
behalf of another given user.
3. They are used in the Identity Manager access control model, to determine who can see and who can
modify what identity attributes, on whose proles.
4. They are used to select users who will be invited to approve requests for changes to user proles or
entitlements.
5. They can be used by automated provisioning logic, to automatically assign roles or groups to users.
5.6 Network Architecture
Hitachi ID Identity Manager is designed for:
Security:
Identity Manager is installed on hardened servers. All sensitive data is encrypted in storage and
transit. Strong authentication and access controls protect business processes.
Scalability:
Multiple Identity Manager servers can be installed, using a built-in data replication facility. Workload
can be distributed using any load-balancing technology (IP, DNS, etc.). The end result is a multi-
master, distributed architecture that is very easy to setup, as replication is handled at the application
layer.
Performance:
Identity Manager uses a normalized, relational and indexed database back end. All access to the
database is via stored procedures, which help to minimize communication overhead between the
application and database. All Identity Manager code is native code, which provides a 2x to 10x
performance advantage as compared to Java or .NET
Openness:
Open standards are used for inbound integration (SOAP) and outbound communications (SOAP,
SMTP, HTTP, etc.).
Flexibility:
Both the Identity Manager user interface and all functionality can be customized to meet enterprise
requirements.
Low TCO:
Identity Manager is easy to set up and requires minimal ongoing administration.
Figure 5 on Page 18 illustrates the Identity Manager network architecture:
Users normally access Identity Manager using HTTPS from a web browser.
Multiple Identity Manager servers may be load balanced using either an IP-level device (e.g., Cisco
Local Director, F5 Big/IP) or simply using DNS round-robin distribution.
User
Password
Synch
Trigger
Systems
Load
Balancer
SMTP or
Notes Mail
Incident
Management
System
System of
Record
IVR
Server
Reverse
Web Proxy
Target Systems
with local agent:
OS/390, Unix,
older RSA
Firewall
TCP/IP + AES
Various Protocols
Secure Native Protocol
HTTPS
R
e
m
o
t
e

D
a
t
a

C
e
n
t
e
r
Firewall
L
o
c
a
l

N
e
t
w
o
r
k
Target Systems
with remote agent:
AD, SQL, SAP, Notes, etc
Target Systems
E
m
a
ils
T
ic
k
e
t
s
L
o
o
k
u
p
&
T
r
ig
g
e
r
N
a
t
iv
e
p
a
s
s
w
o
r
d
c
h
a
n
g
e
A
D
, U
n
ix
,
O
S
/
3
9
0
,
L
D
A
P
,
A
S
4
0
0
V
a
lid
a
t
e
P
W
W
e
b
S
e
r
v
ic
e
s
Proxy Server
(if needed)
Hitachi ID
Application
Server(s)
SQL/Oracle
SQL
DB
SQL
DB
C
l
o
u
d
-
h
o
s
t
e
d
,
S
a
a
S

a
p
p
s
VPN
Server
Figure 5: Network architecture diagram
Users may call an IVR (interactive voice response) system with a telephone and be authenticated
either using touch-tone input of personal information or using a voice print. Authenticated users may
initiate a password reset.
Identity Manager connects to most target systems using their native APIs (application programming
interfaces) and protocols and thus requires no software to be installed locally on those systems.
Local agents are provided and recommended for Unix servers and z/OS mainframes. Use of these
agents improves transaction security, speed and concurrency.
A local agent is mandatory on older RSA SecurID servers (version 7.x and later exposes a remote
API).
Where target systems are remote and communication with them is slow, insecure or both, a Identity
Manager proxy server may be co-located with the target system in the remote location. In this case,
servers in the main Identity Manager server cluster initiate fast, secure connections to the remote
proxies, which decode these transactions and forward them to target systems locally, using native,
slow and/or insecure protocols.
Identity Manager can look up and update user prole data in an existing system, including HR
databases (ODBC), directories (LDAP) and meta-directories (e.g., WMI to Microsoft ILM).
Identity Manager can send e-mails to users asking them to register or to notify them of events impact-
ing their proles. Over 114 events can trigger e-mail notication.
Identity Manager can create tickets on most common incident management systems, either recording
completed activity or requesting assistance (security events, user service follow-up, etc.). Over 114
events can trigger ticket generation. Binary integrations are available for 17 help desk applications
and open integration is possible using mail, ODBC, SQL and web services.
5.7 High-Performance, High-Availability Database Architecture
All Hitachi ID Identity Manager components, including user interface screens, reports, service programs
and command-line / batch processes access the database using the same architecture:
1. A client component calls a client wrapper library.
2. The client wrapper library communicates with a Identity Manager database service using an IPC.
This may be shared memory (same server, very fast) or TCP/IP socket (remote server, encrypted
communication using a shared key).
3. The Identity Manager database service authenticates clients, checks what they are allowed to see/do
and invokes stored procedures to read from and write to the database.
4. Stored procedures, installed on the relational database back end (e.g., Microsoft SQL Server or Oracle
Database Server), access data in the local schema and return results.
5. Calls to stored procedures which insert, delete or update records are forwarded by the database
service to its replicating peers, so that each database instance may be kept up to date.
6. Data returned by stored procedures is passed back to the calling program.
This architecture is advantageous for several reasons:
1. Built-in data replication makes it easy to congure Identity Manager in a high-availability, fault-tolerant
architecture.
2. Using stored procedures rather than direct SQL calls signicantly improves performance while leaving
open the possibility of future schema changes.
3. Using a Identity Manager database service to front-end the physical database enables robust access
controls and easy-to-manage database replication.
4. Wrapping data calls in an encrypted protocol enables secure conguration in a distributed environ-
ment, over untrusted network segments.
6 Return on Investment
Hitachi ID Identity Manager strengthens security by:
Quickly and reliably removing access to all systems and applications when users leave an organiza-
tion.
Finding and helping to clean up orphan and dormant accounts.
Assigning standardized access rights, using roles and rules, to new and transitioned users.
Enforcing policy regarding segregation of duties and identifying users who are already in violation.
Ensuring that changes to user entitlements are always authorized before they are completed.
Asking business stake-holders to periodically review user entitlements and either certify or remove
them, as appropriate.
Reducing the number and scope of administrator-level accounts needed to manage user access to
systems and applications.
Providing readily accessible audit data regarding current and historical security entitlements, including
who requested and approved every change.
Identity Manager reduces the cost of managing users and security entitlements:
Auto-provisioning and auto-deactivation leverage data feeds from HR systems to eliminate routine,
manual user setup and tear-down.
Self-service eliminates IT involvement in simple updates to user names, phone numbers and ad-
dresses.
Delegated administration moves the responsibility for requesting and approving common changes,
such as for new application or folder access, to business users.
Identity synchronization means that corrections to user information can be made just once, on an
authoritative system and are then automatically copied to other applications.
Built-in reports make it easier to answer audit questions, such as who had access to this system on
this date? or who authorized this user to have this entitlement?
www.Hitachi-ID.com
500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com
File: /pub/wp/documents/white/idsynch/ids-white-10.tex
Date: 2011-04-12

Large Scale User Provisioning With Hiim

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Large Scale User Provisioning With Hiim

Uploaded by

Copyright:

Available Formats

Large Scale User Provisioning

with Hitachi ID Identity Manager

You might also like