Selecting a User Provisioning Solution

Selecting a User Provisioning Product
© 2014 Hitachi ID Systems, Inc. All rights reserved.

User provisioning products help organizations to create, manage and deactivate login IDs and other re-
sources for users. They are intended to streamline administration of user access to systems as users are
hired, move through an organization, and leave.
This document helps organizations to define criteria which can be used to select an appropriate user provi-
sioning product.
The selection process begins with the business case for a user provisioning system. This business case is
used to develop functional and technical requirements, which in turn drive the product and vendor selection
process.
Contents
1 Introduction 1
2 Business Case for User Provisioning 2
2.1 Provisioning Resources More Quickly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Simplifying Security Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Reducing System Administration Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.4 Improving Access Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4.1 Identifying and Removing Orphan Accounts . . . . . . . . . . . . . . . . . . . . . . 3
2.4.2 Timely Access Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4.3 Security Policy Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4.4 Audit Trails and Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4.5 Initial Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Functionality 4
3.1 Basic Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Authorization Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Fulfillment Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Easy to Use Human Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
i

3.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 Automatic Change Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6 Consolidated and Delegated User Administration . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7 Directory Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.7.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Technology 12
4.1 Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Integration With Other Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Scalability and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Securing the user provisioning System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Security Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6 Effective Audit Trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Deployment and Management 20

5.1 Rapid Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 Vendor Quality 23
6.1 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3 Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.4 Services Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7 Conclusions 25

1 Introduction
User provisioning products help organizations to create, manage and deactivate login IDs and other re-
sources for users. They are intended to streamline administration of user access to systems as users are
hired, move through an organization, and leave.
This document helps organizations to deﬁne criteria which can be used to select an appropriate user provi-
sioning product.
The selection process begins with the business case for a user provisioning system. This business case is
used to develop functional and technical requirements, which in turn drive the product and vendor selection
process.
The remainder of this document is organized as follows:
• Business case for user provisioning
Every user provisioning project must begin with a business justiﬁcation. This is the background for all
subsequent requirements.
• Functionality
Basic functions that a user provisioning system should meet.
• Technology
Technical architecture considerations, and how they impact an user provisioning system’s usability.
• Deployment and management
Design considerations that impact the initial deployment and ongoing administration of a user provi-
sioning system.
• Vendor quality
The qualities of a successful user provisioning vendor.
• Conclusions
A summary, and a reminder to “try before you buy.”
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

2 Business Case for User Provisioning
A user provisioning system should not be deployed based solely on a vendor’s recommendation. Rather, it
should address real and measurable business problems, and should yield a measurable return on invest-
ment (ROI) in a short time-frame.
Following are the most common reasons for deploying a user provisioning system:
2.1 Provisioning Resources More Quickly
Users require dynamic access to systems, as their business relationship with a company changes. Systems
access must be altered to reflect hiring, staff changing responsibilities, and terminations.
An important motivation for implementing a user provisioning system is to reduce the time required to enter,
route, approve, and fulfill requests for new or changed system access.
A user provisioning system will reduce the number of days that it takes to route, approve and fulfill a change
request. This yields better customer service and improves the productivity of new hires and people whose
responsibilities have changed.
2.2 Simplifying Security Requests
Users frequently have to make security requests, to gain new access to systems as their business require-
ments evolve, or to clean up old, no-longer-needed access rights.
Users often have difficulty figuring out who to ask for security changes, and are frequently unable to artic-
ulate their needs in terminology clear and specific enough for security administrators to implement. This
slows down the security administration process and causes frustration for both users and administrators.
A good user provisioning system should reduce or eliminate this friction between users and systems security
administration processes.
2.3 Reducing System Administration Cost
Organizations with multiple operating systems, directories, and applications manage users in multiple
places, using different tools, often operated by different administrators. As staff are hired, moved and
terminated, similar updates are applied to each of their accounts, on different systems.
This administration is redundant, and reducing the amount of redundant administration has a significant
impact on overall administration cost.
In addition, much of the administration work done on most systems is routine: creating standard-setup
accounts, deactivating existing accounts, and applying routine updates. Once such changes are approved,
a user provisioning system can execute them automatically, without human intervention. This creates a
further reduction in administration costs.

2.4 Improving Access Security
2.4.1 Identifying and Removing Orphan Accounts
Manual system administration, combined with sometimes unreliable business processes, often leads to
“orphan accounts” on systems. Orphans are simply accounts whose owners are no longer employed by the
organization.
Orphan accounts pose a serious security risk: if an intruder compromises an orphan account, nobody is
likely to notice. An ongoing attack against an orphan account is also unlikely to be noticed.
A benefit of deploying a user provisioning system is the ability to identify and deactivate orphan accounts
on all systems.
2.4.2 Timely Access Deactivation
When staff leave an organization, their systems access should be terminated quickly. Failure to do so
means that people no longer employed with the organization are still able to access sensitive systems.
A benefit of a user provisioning system is the ability to quickly identify users whose access should be
terminated, and deactivate that access on every system where they have an account.
2.4.3 Security Policy Compliance
Security policy normally specifies how login accounts should be configured for different types of users.
Human error in manual administration means that these standards are not always enforced. Automated
administration, as implemented by a user provisioning system, ensures compliance with standards.
2.4.4 Audit Trails and Accountability
In the event of a security incident or audit, it is important to be able to justify why each user has been
granted every account that he can log into. A user provisioning system should log requests and approvals,
which constitute an audit trail for access changes.
2.4.5 Initial Passwords
An important problem when creating new login accounts is how to securely communicate the initial pass-
word to the new user. E-mail is typically insecure, as are default values such as the user’s name, employee
number or login ID.
Some user provisioning systems have effective technology to limit the number of people who have access
to the initial password on new accounts. This is a major security benefit, as it helps to assure that actions
performed by that account in question really were initiated by the authorized user.

3 Functionality
The business requirements set out in Section 2 on Page 2 can be converted into specific functional require-
ments as explained in the following sections.
In the following text, an access change may be creation of a new login account, modification of the access
rights or setup of an existing login account, or deactivation of systems access.
3.1 Basic Capabilities
3.1.1 Requirements
A user provisioning system should support basic user profile updates on every target system:
• Creating new users.
• Deleting users.
• Enabling users.
• Disabling users.
• Renaming users.
• Updating user attributes.
• Adding users to groups (e.g., security groups, mailing lists).
• Removing users from groups (e.g., security groups, mailing lists).
When creating new users or updating existing ones, the user provisioning system should be able to:
• Access every attribute in the schema of managed systems – user properties, group memberships,
etc.
• Map attributes on managed systems to some central, global schema.
3.1.2 Pitfalls to Avoid
Avoid products that either have just a subset of the features mentioned above, or do not support the same
features on every system. Make sure that the product supports at least the features identified as business
requirements on every managed system.

3.2 Authorization Workflow
In most organizations, access change requests take a significant amount of time to fill out, route and autho-
rize. A workflow system can be used to expedite this process.
3.2.1 Requirements
An authorization workflow system should support:
• Easy input of change requests on a web form, where the requester must be authenticated.
• Input of requests from another system, rather than directly from a user. In some cases, information
sufficient to specify a change request is already available, and should not be entered twice.
• Automatic determination of who should authorize a given request.
• Routing of requests to authorizers by e-mail.
• Response to authorization requests using a secure, authenticated web form.
• Different kinds of authorizers: those attached to requested resources, and those related through the
organization structure to the recipient of access changes.
• Groups of authorizers, where only some members of each group are required to approve or reject a
change request.
• Delegation, when authorizers will be unavailable for an extended period.
• Reminders, when authorizers fail to respond to requests in a timely manner.
• Escalation, when response is unacceptably delayed.
Some potential problems, that should be avoided in a workflow system used for change request authoriza-
tion, are:
• Approvals with weak or no authentication:
Authorizers should establish their identity reliably before being allowed to approve or reject a request.
This is normally done with a password or hardware token, rather than less secure means such as
e-mail or question-and-answer profiles.
• Default initial passwords:
Many systems set initial passwords on newly-created users to default or predictable value. Clearly
this compromises the security of target systems and of the organization as a whole.
• Sequential or conditional approvals:
The main objective of an authorization workflow system is to expedite approvals. Prompting one au-
thorizer for input only after another authorizer has responded is contrary to this goal. Accordingly,
sequential or conditional approvals are undesirable: it is simply better to prompt every relevant autho-
rizer at once, when a change request has been entered.

• Graphical process definition:
Workflow products frequently use a graphical modeling process to define what happens and when.
While this looks great in demonstrations, this method does not scale since it requires that a separate
flow-chart be defined for each and every type of allowed transaction, on each and every target system.
As the number of systems grows and the number of transactions allowed per system – creating
different types of users, managing membership in different groups, setting different attribute values,
etc. – grows, the graphical definition process collapses.
Failure to scale the workflow definition process is the single largest cause for user provisioning project
failure at the pilot phase.
• Reliance on a particular representation of the organization:
One of the key functions of a workflow system is to identify authorizers based on the identity of the
requester or recipient of the access change. To do this, some business logic must be applied to data
from the organization chart.
A robust system will be able to access the organization chart anywhere: in an LDAP directory, a
relational database or even a text file. More restrictive systems will require this data to be stored on a
particular type of system, in a particular format.
• Complex programming at setup time:
Many workflow engines require extensive programming or configuration to setup. A successful user
provisioning system minimizes this setup, to expedite activation and reduce ongoing administration.
• Workflow that can collect user input but not authorize changes:
It is possible to construct workflow engines that elicit user input, for example to populate attribute
values, but that do not work well to authorize (and possibly block) changes. Such a workflow engine
has its place, but is no substitute for a change authorization engine.

3.3 Fulfillment Engine
In some enterprises, a home-grown or third party workflow engine already access security change requests.
In these cases, the user provisioning system should act as a fulfillment engine connected to the existing
workflow, rather than requiring the customer to throw out what already works, just to get automatic updates
to target systems.
3.3.1 Requirements
A fulfillment engine should support:
• Easy integration, preferably using a SOAP-compatible web service.
• Full functionality: the ability to create, delete, enable, disable, update or rename users on any system.
• Support both batch and single-update inputs.
Some potential problems, that should be avoided in a fulfillment engine, are:
• Use of proprietary APIs.
• Limited functionality in the fulfillment engine.
• Weak authentication of the caller to the fulfillment engine.

3.4 Easy to Use Human Interface
A user provisioning system must be easy to use. In particular, the interface accessed by requesters and
authorizers must be so simple and intuitive as to require no training.
If the end-user interface requires training, then the system will not be adopted by users. This is because
users only require access changes sporadically, and even if every user in an organization is trained to use
an user provisioning system, the delay between training and first use will be significant. As a result, users
will likely have forgotten anything they learned by when they first need to use the system.
3.4.1 Requirements
• The user interface must be web based, uncluttered, and self-explanatory.
• The system must be easily accessible from a frequently-accessed Intranet.
• User authentication to the system must be the same as authentication to other systems (e.g., use
NOS or directory credentials).
• The access change request process must be simple and linear.
• Access changes should be specified in easy-to-understand units. In practical terms, users should be
able to request access changes in terms of business roles (e.g., accounting clerk) or basic capabilities
(e.g., e-mail access), described in familiar terms. Users should not have to enter or select system
names, access types or technical privileges.
• Any requirement for user training will cause deployment of the authorization workflow system to fail.
• Too many navigation options will trigger a requirement for training.
• Specification of access changes that is too detailed or too technical.
• Use of technical language or requirement for domain knowledge in the user interface.

3.5 Automatic Change Propagation
In some organizations, information sufficient to trigger automatic provisioning or deactivation of access is
already managed effectively in an existing system, such as human resources or contractor management
system. This is the system of record. In these organizations, it makes sense to leverage the existing data
to trigger automated administration, rather than duplicating data entry into a workflow system.
In most cases, automated administration (automated change propagation) cannot be very specific, simply
because data in the system of record is not very detailed. Typical automated actions include creating basic
network or e-mail access and deactivating access for terminated staff. Automated administration is often
followed by manually entered change requests that specify the required access in greater detail.
Automated administration has three basic components:
• Monitoring systems of record for changes
• Applying business logic to filter and transform those changes
• Fulfilling access changes identified by the business logic and possibly authorized.
3.5.1 Requirements
Automated administration systems should:
• Support different types of systems of record. It is unlikely that two organizations will use exactly the
same type, with data formatted in exactly the same way.
• Allow the implementor a great deal of flexibility in defining filters and transformations in the data path
between the systems of record and managed systems.
• Support multiple systems of record at the same time – since no one system is likely to include all
attributes or all users.
• Automated actions should include both direct access changes (e.g., create account, deactivate ac-
count), and submitting change requests to the authorization workflow system.
Automated administration systems should not:
• Have a rigid model for specifying business rules. Business rules may be complex, and will certainly
evolve over the life of the system. At a minimum, some simple scripting is required to define flexible
rules.
• Require the use of a graphical process for specifying business rules. Business rules may be complex,
and while graphical specification of rules works well in a demonstration, it does not scale to real-world
complexity.

3.6 Consolidated and Delegated User Administration
In some cases, system administration must be done manually. One example of this is urgent access
deactivation, where there is no time to wait for a workflow or automated process to complete.
A user provisioning system should include a consolidated user administration capability, that allows both
global security administrators and local IT resources to manage user access to systems.
In some cases, it is more appropriate to allow local or departmental staff – either business users or IT
resources – to manage access than to invoke a workflow or ask an enterprise security administrator to do
the work.
A user provisioning system should support delegated user administration, where designated staff can per-
form limited updates to some systems, affecting only specific users.
3.6.1 Requirements
A consolidated user administration facility should:
• Be accessible from anywhere, preferably with a web interface, so that security administrators can use
it whenever and wherever required, without having to install client software.
• Support all basic user administration tasks, spanning multiple systems, from a single user interface.
A delegated user administration facility should:
• Support granular access control lists, so that designated administrators can be assigned specific
privileges – e.g., to manage only certain users, on only certain systems.
• Be able to make decisions about what administrator can perform what updates to what users on what
systems based on existing data – e.g., drawn from the corporate directory, from an HR database, from
a mainframe extract, etc. There should be no reliance on a particular platform or schema for rules
used to make delegation decisions.
A consolidated user administration facility should not require:
• That every administrator be able to manage every account on every system.
• Separate actions to create or alter login accounts in different systems.
• Client software.
• That data used to make decisions about delegated access be in a particular format (e.g., directory
structure), or on a particular kind of system (e.g., LDAP).
• That data used to make decisions about delegated access be newly entered into the system (rather
than pulled from an existing database or directory).

3.7 Directory Cleanup
A user provisioning system should assist in cleaning up user directories. In particular, it should aid in
identifying orphan and inactive login accounts, and provide a simple means to deactivate and ultimately
delete them.
3.7.1 Requirements
A directory cleanup facility should be able to:
• Relate login accounts on different systems to individual users.
• Leverage last-login-time data on one system to identify possibly inactive accounts on another system,
where last-login-time data is unavailable.
• Allow users to claim ownership of accounts, so that the system can identify those accounts that exist
but are unclaimed.
• Support batch deactivation and deletion of accounts on each system.
A directory cleanup facility should not:
• Automatically deactivate or delete accounts. Such actions should be subject to human control, to
prevent costly mistakes.

4 Technology
4.1 Platform Support
A user provisioning system is only useful to an organization if it can manage accounts on the existing IT
infrastructure of that organization.
The system itself should run on a platform that the IT group already knows how to manage.
Wherever possible, software should not be installed on managed systems, to minimize change control at
installation time, and eliminate ongoing updates and troubleshooting. This architecture is sometimes called
“agentless” although that is a misnomer, since agents are still installed – just not on the managed systems.
4.1.1 Requirements
A user provisioning system should:
• Be able to manage accounts on every system with a signiﬁcant user population, without requiring
signiﬁcant change control (e.g., a local agent) or customization (e.g., custom agents).
• Be able to manipulate all relevant user attributes and privileges on managed systems.
• Run on a well-understood and already-supported platform.
• Require a minimum of agents to be installed on managed systems.
• Minimal or “roll your own” support for target systems.
• Connectors to target systems that cannot address all relevant user attributes or privileges.
• Extensive reliance on server-side software installation.
• Slow and costly development of integration with new types of target systems.

4.2 Integration With Other Infrastructure
A user provisioning system should be integrated with existing IT infrastructure components.
4.2.1 Requirements
User provisioning systems should integrate with infrastructure beyond target systems, including:
• HR systems:
The user provisioning system should be able to draw information from one or more HR and related
systems, including:
– A definitive list of what users should exist.
– Basic user attributes, such as employee ID, department code, date of hire, etc.
– Information about user termination.
– What types of access each user should have, if that data is available.
• Directories:
The user provisioning system should be able to draw information such as what users exist, and what
systems they log into, from an authoritative directory, and write updates back to that directory.
• Meta directories and map files:
If existing data mapping login IDs on different systems to individual users already exists – for example
in the form of a meta directory – it should be leveraged both during deployment and at run-time. It
never makes sense to re-create data.
• E-mail:
The user provisioning system should be able to use e-mail to prompt users to register, to ask autho-
rizers for change approvals, to notify recipients of new access rights, and in general to ask users for
action and notify them of changes.
• Help desk / issue management systems:
It is important to be able to submit completed actions and escalated requests for authorization to an
issue tracking system, both for unified reporting and to request event followup.
• Asset management systems:
In addition to systems access, a user provisioning system should be able to provision physical items,
such as computers, telephones, authentication tokens, etc.
It is reasonable to include a lightweight inventory management capability in a user provisioning sys-
tem. More robust asset management, with features such as depreciation, procurement and tax re-
porting, is beyond the scope of a user provisioning system. Accordingly, the user provisioning system
should be able to integrate with an existing asset management system.

• Avoid products where the customer is expected to develop or extend the connectors used to support
target systems. Setting up a user provisioning system should not require programming.
• Pre-deﬁned, rigid HR integration, which only works with some kinds of systems of record, or only with
speciﬁc schema on those systems.
• Reliance on a single, authoritative directory.

4.3 Scalability and Availability
User provisioning systems do not normally have to process high transaction loads. Users are normally
hired, move or are terminated at an approximately constant rate – at any time of year, day of week, or
time of day. Evenly distributed activity means that no burst of activity is likely to stress a user provisioning
system.
That said, user provisioning systems are frequently bundled or integrated with password management sys-
tems, which must support extremely bursty transaction loads – on the order of 1000 transactions per hour
per ten thousand users. This means that at least the password management component of a user provi-
sioning system must be scalable.
High availability also means that the user provisioning system should detect outages on managed systems,
and should retry updates such as creating or deleting users on those systems, when those systems are
available again.
4.3.1 Requirements
• The password management component, if any, must be extremely scalable. This is normally accom-
plished using multiple, redundant and load-balanced servers.
• The system should be fault tolerant - reinforcing the need for redundant servers.
• The system should tolerate outages on target systems, and automatically retry administrative opera-
tions.
• Avoid products that scale through some scheme for segmenting the user population. For example,
the self-service component should support every user on every user provisioning server, rather than
requiring certain users to access certain servers.
• Avoid products that have a system point of failure – a database, a web server, a load balancer, etc.
For truly high availability and scalability, there should be no one single point of failure.

4.4 Securing the user provisioning System
A user provisioning system is a sensitive part of the IT infrastructure because it can create and delete user
IDs on every system, because it enforces security standards, and because it contains an important audit
trail.
This sensitivity means that a user provisioning system must be managed securely.
4.4.1 Requirements
• Host platform
The user provisioning server must be able to run on a hardened host operating system, with a hard-
ened web server.
While every operating system and web server has a history of at least some security vulnerabilities,
these vulnerabilities are inevitably due to a ﬂaw in one subsystem or another. By disabling non-
essential subsystems, it is possible to reduce the likelihood of future problems.
• Use of encryption
All sensitive data, be it transmitted or stored, should be encrypted or hashed, as appropriate. This
means using HTTPS from the client web interface to the password server, and suitable protocols to
encrypt data going from the password server to managed systems or back-end databases.
• Host platform
Some operating system components to avoid or disable, because of their history of security problems,
include:
– Active Server Pages on IIS.
– File sharing, including NFS and SMB/CIFS/DFS.
– “Simple network services” such as echo and time-of-day.
– Windows network services such as DCOM.
Ideally, a user provisioning system should be able to run on a stripped-down server, with only a web
service running, and preferably almost every web server feature/module disabled.
• Working with web proxies and ﬁrewalls
It is desirable to be able to install a user provisioning server in a secure subnet, behind a reverse web
proxy. This eliminates any possibility that an attacker could connect to any service on the password
server directly.
This implies that all communication from users to the password server be carried over pure HTTPS.
A user provisioning server should not incorporate an application-level protocol from a client software
component (ideally there should be no client software) to the server.

• “API security”
Some user provisioning products rely on third-party vendors to encrypt their native communication
protocols. They assume that if a native API was used to manage passwords on a given system, then
that communication must be secure.
This is nonsense. Many native protocols, such as those used by Oracle (SQL*Net), MSSQL (TDS)
and SAP (CPIC), are vulnerable to attacks by packet sniffers and man-in-the-middle attacks.
A user provisioning server must include some provision to protect communication with every target
system, even when its native protocol is insecure.
Encrypting communication with insecure managed systems can only be done by installing an agent
on the managed system, or installing a secure application-level proxy server that is co-located in a
secure environment with the managed system.
• Strong user authentication
User authentication should be strong at all times. In practice, this means:
– Using hardware tokens if possible for non-password authentication.
– Implementing intruder lockout and alarms when there are repeated authentication failures.
– Avoiding weak forms of user authentication, such as e-mail, PINs or question-and-answer pro-
ﬁles.

4.5 Security Policy Enforcement
A key benefit of a user provisioning system is to ensure that all access changes comply with security policy.
4.5.1 Requirements
• All new passwords should comply with policy.
• Access changes should be made only with sufficient authorization.
• New accounts should be configured to comply with setup standards.
• Accounts created or deactivated using other tools should be identified, as these may represent viola-
tions to normal business process.
Account setup standards should be enforced when new accounts are created, rather than continuously.
Automatically adjusting the setup of existing accounts to match changed standards would be valuable if it
could be implemented. Unfortunately, automatic privilege adjustments (also known as policy-based provi-
sioning) is exceedingly difficult to setup, because it requires:
• Very large periodic extracts of access privilege details from every managed systems,
• Classification of the access privileges that every user should have, including users who were not
provisioned by the system.
Both of these processes are so costly as to be impractical.

4.6 Effective Audit Trails
One of the benefits of a user provisioning system is that all changes to user access are passed through a
single point of control. This point of control presents an ideal place to record the history of every change
request.
4.6.1 Requirements
A user provisioning audit facility should make accessible:
• A list of every user on every system.
• A list of login accounts attached to every user profile.
• Detailed history of every access change, including who initiated it, who authorized it, what systems it
was applied to, and with what results.
Audit data should be maintained indefinitely. Ideally, audit data should be available on-line, for analysis and
reports, for an extended period (years).
Audit data should not:
• Be time-expired.
• Skip detailed information.
• Be limited to access changes triggered by the system itself, ignoring changes made with other tools.

5 Deployment and Management
5.1 Rapid Deployment
The main reason for installing a user provisioning system is normally to achieve cost savings. If the system
is difficult or costly to deploy, those savings are offset by unreasonably high initial cost and may be delayed
unacceptably.
Accordingly, rapid and inexpensive deployment is essential to a worthwhile user provisioning system.
5.1.1 Requirements
• Automatic discovery of managed user IDs
Every user provisioning system must have a profile for each user, that connects that user with his
login IDs on managed systems. This profile is mandatory.
A user provisioning system should construct this profile automatically. Manual administration is so
costly as to put into question project ROI.
• Automatic reconciliation of user IDs across systems
In case user IDs on different systems are not the same, but one can be related to another by an
automatic mapping, the system should be able to automatically correlate them.
This eliminates manual processes that cross-reference IDs between systems, to construct user pro-
files.
• Self-service reconciliation of user IDs across systems
In case user IDs on different systems are not the same, and are not related by any reliable mapping
process, they must still be cross-referenced.
There are only two reliable ways to do construct user profiles in this case:
– Perform a massive correlation project, using algorithmic matching, human quality control and
manual matching and cross checking (i.e., call the user and find out!) of IDs.
– Prompt users themselves to provide this information and validate their input.
The latter is obviously preferable – self-service reconciliation is inexpensive and can be made 100%
reliable.
• Clone new accounts from templates on the target system
New accounts should be created using templates – which are real accounts on the managed systems,
used to specify how standards-compliant accounts should be setup. Creating new accounts with
templates significantly reduces a major task in system setup: defining the characteristics of every
type of user on every system.
• Self-contained system
A user provisioning system should be simple to install, which generally means that it should be self-
contained. Reliance on external infrastructure, such as a corporate directory, HR database, call track-
ing system, or even a DBMS engine on a separate server is undesirable.
Self-reliance is also an important attribute for high-availability, as it makes it simpler to engineer a
redundant solution, with no single point of failure.

• Minimal requirement for server-side agents
Installing agents on production servers is costly, as it normally entails a change control and quality
testing process. If a user provisioning system can manage accounts on a system without installing
new software on that system, it will be much simpler to install, and owners of that system will have
fewer objections to its deployment.
• A massive data load
Without auto-discovery of login IDs on managed systems and self-service reconciliation of different
login IDs, installers are forced to manually download and correlate IDs from each managed system.
This process is time consuming, expensive and error prone, and unnecessary.
• Role definition and user classification
Avoid products that require a full set of roles to defined for the user population, and that require every
user’s access to be classified in terms of those roles. Role definition and user classification are very
difficult projects in a large and dynamic organization, and can delay system activation by months or
years.
• Directory cleanup prior to deployment
Some products require that all orphan accounts be identified and removed prior to deployment. While
this is a valuable objective for a user provisioning system, it is not a reasonable pre-requisite for
deployment, as it may delay other valuable deliverables from the project.
• Centrally defined templates
Some products define template users by manually specifying every attribute of those users inside the
user provisioning system. This is awkward at best, as platform administrators must learn to define
templates on the new system. This process can become unmanageable on systems where users
have literally hundreds of attributes, many of which are automatically set by native administration
tools, and with which platform administrators may not be familiar.
• Installation pre-requisites
Avoid products that require significant server hardware or software prior to initial deployment, or that
require that an enterprise-class directory be pre-built and configured. These pre-requisites are costly
and unnecessary.
• Manual or semi-automated user ID reconciliation
Some products use attribute-matching and name-matching algorithms to correlate different user IDs
across managed systems. This approach rarely yields more than 80% success, and the remaining
accounts must be correlated manually.
Manual login ID reconciliation is extremely costly, even when it’s only required for 20% of the user
population. Since other strategies are available, manual and semi-automated reconciliation should be
avoided.

5.2 Administration
The ongoing effort required to administer a user provisioning system should be minimal.
5.2.1 Requirements
• No new passwords
The system should authenticate users with an ID and password that they already know – e.g., LDAP,
Active Directory or NDS.
Using a new ID/password would trigger a costly process to distribute new IDs, just to get into the user
provisioning system, and supporting password problems experienced by requesters, authorizers, etc.
• Web-based management
All administration tasks should be web based. Using a single, web-based interface reduces complex-
ity, and means that administration can be done from anywhere, at any time.
• Easy UI customization
The user interface should be easy to customize, to match evolving Intranet standards. A complex or
cumbersome UI customization process will trigger significant effort whenever the Intranet changes.
• Local administration
Avoid products where administration must be performed, at least in part, from the console of the user
provisioning server itself.
• Distributed UI components
Find all the different places where user interface modifications are made. The more files and pro-
cesses that have to be touched to alter the user interface, the harder it will be to customize and
maintain.
• Complex workflow definition
Avoid workflow engines that require extensive programming to configure, or where the workflow is
defined using a graphical layout tool. In both of these cases, ongoing management of authorization
routing rules will be difficult.

6 Vendor Quality
User provisioning systems typically have a lifespan of at least several years, and over this period there will
be multiple infrastructure, software and business process changes.
A user provisioning product must be supported by a capable and stable vendor. A vendor with poor skills or
vision will be unable to properly support its product. A vendor whose business may not be viable, or whose
focus may shift away from user provisioning, is likewise undesirable.
6.1 Vision
User provisioning is a component of a growing identity management market, which also includes meta
directories, web user provisioning and authentication/password management. The new marketplace is
focused on end-to-end identity management.
To survive, the vendor should focus on streamlining identity management generally, rather than just provi-
sioning systems access. Of the other identity management components, the functionality that tends to fit
best with user provisioning is authentication management.
6.2 Focus
Some vendors offer user provisioning as a part of a much larger suite of products, which may range from
operating system security diagnostics to mainframe infrastructure.
The identity management market requires specialized technology. It is a fiercely competitive market, and
vendors whose focus is elsewhere may exit as they realize little or no return on their investment.
6.3 Stability
Some of the leading vendors in the user provisioning space are small, with revenues in the $10M/year
range. Some vendors attempt to grow using repeated rounds of venture capital funding, followed by an
initial public offering or corporate acquisition. Some vendors have a significant cash burn rate, and may not
survive without further injection of cash or a public stock offering.
A successful user provisioning vendor should have no debt and be profitable. This lets the vendor focus on
customers, rather than new financing.
6.4 Services Organization
A user provisioning vendor must support integration with a diversity of existing infrastructure, including:
• Network operating systems.
• Mainframes and minicomputers.

• Directories and meta directories.
• Systems of record, such as HR and contractor management.
• DBMS servers.
• ERP and other applications.
• E-mail systems.
• Web infrastructure.
• Call tracking systems.
• Authentication hardware (tokens).
It follows that they should have at least some expertise with each of these types of systems.
This is clearly a difﬁcult challenge for any single vendor to meet. Accordingly, it is prudent to try the product,
and at the same time evaluate the vendor’s ability to support these various integrations, before purchasing.

7 Conclusions
As described in this document, a user provisioning system is conceptually simple, but can be difﬁcult to
deploy and to manage.
A careful examination of products and the vendors that make them is essential to getting:
• Rapid deployment.
• Reliable and scalable operation.
• Good user adoption.
By meeting these objectives, a user provisioning system will reduce administration cost, improve user ser-
vice and enhance security.
The issues raised here are difﬁcult to validate on paper. Hitachi ID encourages prospective customers to
use the points raised in this document to construct rigorous laboratory testing conditions, and to evaluate
prospective products empirically, with vendor assistance.
Remember: try before you buy!
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/selecting_provisioning_product/selecting_access_product
Date: June 12, 2004

Selecting a User Provisioning Solution

More Related Content

What's hot (17)

Similar to Selecting a User Provisioning Solution (20)

More from Hitachi ID Systems, Inc. (20)

Recently uploaded (20)

Selecting a User Provisioning Solution