Selecting a User Provisioning Solution

Selecting a User Provisioning Product

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

http://Hitachi-ID.com/

http://Hitachi.com/

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 arehired, 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 isused to develop functional and technical requirements, which in turn drive the product and vendor selectionprocess.

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 arehired, 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 isused to develop functional and technical requirements, which in turn drive the product and vendor selectionprocess.

The remainder of this document is organized as follows:

• Business case for user provisioning

Every user provisioning project must begin with a business justification. This is the background for allsubsequent 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, itshould 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. Systemsaccess 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 changerequest. This yields better customer service and improves the productivity of new hires and people whoseresponsibilities 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. Thisslows 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 securityadministration processes.

2.3 Reducing System Administration Cost

Organizations with multiple operating systems, directories, and applications manage users in multipleplaces, using different tools, often operated by different administrators. As staff are hired, moved andterminated, 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 significantimpact on overall administration cost.

In addition, much of the administration work done on most systems is routine: creating standard-setupaccounts, 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 afurther 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 theorganization.

Orphan accounts pose a serious security risk: if an intruder compromises an orphan account, nobody islikely 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 accountson all systems.

2.4.2 Timely Access Deactivation

When staff leave an organization, their systems access should be terminated quickly. Failure to do someans 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 beterminated, 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. Automatedadministration, 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 beengranted 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, employeenumber or login ID.

Some user provisioning systems have effective technology to limit the number of people who have accessto the initial password on new accounts. This is a major security benefit, as it helps to assure that actionsperformed 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 accessrights 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 samefeatures on every system. Make sure that the product supports at least the features identified as businessrequirements 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, informationsufficient 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 theorganization structure to the recipient of access changes.

• Groups of authorizers, where only some members of each group are required to approve or reject achange 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 ase-mail or question-and-answer profiles.

• Default initial passwords:Many systems set initial passwords on newly-created users to default or predictable value. Clearlythis 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 separateflow-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 – creatingdifferent 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 projectfailure 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 therequester or recipient of the access change. To do this, some business logic must be applied to datafrom the organization chart.

A robust system will be able to access the organization chart anywhere: in an LDAP directory, arelational database or even a text file. More restrictive systems will require this data to be stored on aparticular type of system, in a particular format.

• Complex programming at setup time:

Many workflow engines require extensive programming or configuration to setup. A successful userprovisioning 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 attributevalues, but that do not work well to authorize (and possibly block) changes. Such a workflow enginehas 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 existingworkflow, rather than requiring the customer to throw out what already works, just to get automatic updatesto 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 andauthorizers 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 becauseusers only require access changes sporadically, and even if every user in an organization is trained to usean user provisioning system, the delay between training and first use will be significant. As a result, userswill 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., useNOS 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 beable 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 systemnames, 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 isalready managed effectively in an existing system, such as human resources or contractor managementsystem. This is the system of record. In these organizations, it makes sense to leverage the existing datato trigger automated administration, rather than duplicating data entry into a workflow system.

In most cases, automated administration (automated change propagation) cannot be very specific, simplybecause data in the system of record is not very detailed. Typical automated actions include creating basicnetwork or e-mail access and deactivating access for terminated staff. Automated administration is oftenfollowed 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 thesame 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 pathbetween the systems of record and managed systems.

• Support multiple systems of record at the same time – since no one system is likely to include allattributes 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 certainlyevolve over the life of the system. At a minimum, some simple scripting is required to define flexiblerules.

• 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-worldcomplexity.



3.6 Consolidated and Delegated User Administration

In some cases, system administration must be done manually. One example of this is urgent accessdeactivation, 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 bothglobal 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 ITresources – to manage access than to invoke a workflow or ask an enterprise security administrator to dothe 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 useit 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 specificprivileges – 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 whatsystems based on existing data – e.g., drawn from the corporate directory, from an HR database, froma mainframe extract, etc. There should be no reliance on a particular platform or schema for rulesused 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., directorystructure), 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 (ratherthan 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 inidentifying orphan and inactive login accounts, and provide a simple means to deactivate and ultimatelydelete 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 existbut 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, toprevent 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 ITinfrastructure 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 atinstallation 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 significant user population, without requiringsignificant 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 relatedsystems, 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 whatsystems 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 examplein the form of a meta directory – it should be leveraged both during deployment and at run-time. Itnever 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 foraction 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 anissue 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 systemshould 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 supporttarget systems. Setting up a user provisioning system should not require programming.

• Pre-defined, rigid HR integration, which only works with some kinds of systems of record, or only withspecific 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 normallyhired, move or are terminated at an approximately constant rate – at any time of year, day of week, ortime of day. Evenly distributed activity means that no burst of activity is likely to stress a user provisioningsystem.

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 hourper 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 areavailable 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 thanrequiring 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 userIDs on every system, because it enforces security standards, and because it contains an important audittrail.

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 flaw 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. Thismeans using HTTPS from the client web interface to the password server, and suitable protocols toencrypt 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 webservice running, and preferably almost every web server feature/module disabled.

• Working with web proxies and firewalls

It is desirable to be able to install a user provisioning server in a secure subnet, behind a reverse webproxy. This eliminates any possibility that an attacker could connect to any service on the passwordserver 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 softwarecomponent (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 communicationprotocols. They assume that if a native API was used to manage passwords on a given system, thenthat 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 targetsystem, even when its native protocol is insecure.

Encrypting communication with insecure managed systems can only be done by installing an agenton the managed system, or installing a secure application-level proxy server that is co-located in asecure 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-files.



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 itcould 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 notprovisioned 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 asingle point of control. This point of control presents an ideal place to record the history of every changerequest.

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 itwas applied to, and with what results.

Audit data should be maintained indefinitely. Ideally, audit data should be available on-line, for analysis andreports, 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 systemis difficult or costly to deploy, those savings are offset by unreasonably high initial cost and may be delayedunacceptably.

Accordingly, rapid and inexpensive deployment is essential to a worthwhile user provisioning system.

5.1.1 Requirements

• Automatic discovery of managed user IDsEvery user provisioning system must have a profile for each user, that connects that user with hislogin IDs on managed systems. This profile is mandatory.A user provisioning system should construct this profile automatically. Manual administration is socostly as to put into question project ROI.

• Automatic reconciliation of user IDs across systemsIn case user IDs on different systems are not the same, but one can be related to another by anautomatic 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 systemsIn case user IDs on different systems are not the same, and are not related by any reliable mappingprocess, 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 andmanual 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 systemNew 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 withtemplates significantly reduces a major task in system setup: defining the characteristics of everytype of user on every system.

• Self-contained systemA 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 aredundant 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 qualitytesting process. If a user provisioning system can manage accounts on a system without installingnew software on that system, it will be much simpler to install, and owners of that system will havefewer objections to its deployment.


• A massive data load

Without auto-discovery of login IDs on managed systems and self-service reconciliation of differentlogin 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 everyuser’s access to be classified in terms of those roles. Role definition and user classification are verydifficult projects in a large and dynamic organization, and can delay system activation by months oryears.

• Directory cleanup prior to deployment

Some products require that all orphan accounts be identified and removed prior to deployment. Whilethis is a valuable objective for a user provisioning system, it is not a reasonable pre-requisite fordeployment, 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 theuser provisioning system. This is awkward at best, as platform administrators must learn to definetemplates on the new system. This process can become unmanageable on systems where usershave literally hundreds of attributes, many of which are automatically set by native administrationtools, 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 thatrequire that an enterprise-class directory be pre-built and configured. These pre-requisites are costlyand unnecessary.

• Manual or semi-automated user ID reconciliation

Some products use attribute-matching and name-matching algorithms to correlate different user IDsacross managed systems. This approach rarely yields more than 80% success, and the remainingaccounts must be correlated manually.

Manual login ID reconciliation is extremely costly, even when it’s only required for 20% of the userpopulation. Since other strategies are available, manual and semi-automated reconciliation should beavoided.



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 userprovisioning 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 orcumbersome 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 userprovisioning 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 andmaintain.

• Complex workflow definition

Avoid workflow engines that require extensive programming to configure, or where the workflow isdefined using a graphical layout tool. In both of these cases, ongoing management of authorizationrouting rules will be difficult.



6 Vendor Quality

User provisioning systems typically have a lifespan of at least several years, and over this period there willbe 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 orvision will be unable to properly support its product. A vendor whose business may not be viable, or whosefocus 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 metadirectories, web user provisioning and authentication/password management. The new marketplace isfocused 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 fitbest 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 fromoperating system security diagnostics to mainframe infrastructure.

The identity management market requires specialized technology. It is a fiercely competitive market, andvendors 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/yearrange. Some vendors attempt to grow using repeated rounds of venture capital funding, followed by aninitial public offering or corporate acquisition. Some vendors have a significant cash burn rate, and may notsurvive 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 oncustomers, 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 difficult 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 difficult todeploy 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 difficult to validate on paper. Hitachi ID encourages prospective customers touse the points raised in this document to construct rigorous laboratory testing conditions, and to evaluateprospective 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: [email protected]

File: /pub/wp/documents/selecting_provisioning_product/selecting_access_product_8.texDate: June 12, 2004
