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. ...
Selecting a User Provisioning Product
3.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
Selecting a User Provisioning Product
5.1 Rapid Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
Selecting a User Provisioning Product
1 Introduction
User provisioning products help organizations to create, manage and d...
Selecting a User Provisioning Product
2 Business Case for User Provisioning
A user provisioning system should not be deplo...
Selecting a User Provisioning Product
2.4 Improving Access Security
2.4.1 Identifying and Removing Orphan Accounts
Manual ...
Selecting a User Provisioning Product
3 Functionality
The business requirements set out in Section 2 on Page 2 can be conv...
Selecting a User Provisioning Product
3.2 Authorization Workflow
In most organizations, access change requests take a signi...
Selecting a User Provisioning Product
• Graphical process definition:
Workflow products frequently use a graphical modeling ...
Selecting a User Provisioning Product
3.3 Fulfillment Engine
In some enterprises, a home-grown or third party workflow engin...
Selecting a User Provisioning Product
3.4 Easy to Use Human Interface
A user provisioning system must be easy to use. In p...
Selecting a User Provisioning Product
3.5 Automatic Change Propagation
In some organizations, information sufficient to tri...
Selecting a User Provisioning Product
3.6 Consolidated and Delegated User Administration
In some cases, system administrat...
Selecting a User Provisioning Product
3.7 Directory Cleanup
A user provisioning system should assist in cleaning up user d...
Selecting a User Provisioning Product
4 Technology
4.1 Platform Support
A user provisioning system is only useful to an or...
Selecting a User Provisioning Product
4.2 Integration With Other Infrastructure
A user provisioning system should be integ...
Selecting a User Provisioning Product
4.2.2 Pitfalls to Avoid
• Avoid products where the customer is expected to develop o...
Selecting a User Provisioning Product
4.3 Scalability and Availability
User provisioning systems do not normally have to p...
Selecting a User Provisioning Product
4.4 Securing the user provisioning System
A user provisioning system is a sensitive ...
Selecting a User Provisioning Product
• “API security”
Some user provisioning products rely on third-party vendors to encr...
Selecting a User Provisioning Product
4.5 Security Policy Enforcement
A key benefit of a user provisioning system is to ens...
Selecting a User Provisioning Product
4.6 Effective Audit Trails
One of the benefits of a user provisioning system is that ...
Selecting a User Provisioning Product
5 Deployment and Management
5.1 Rapid Deployment
The main reason for installing a us...
Selecting a User Provisioning Product
• Minimal requirement for server-side agents
Installing agents on production servers...
Selecting a User Provisioning Product
5.2 Administration
The ongoing effort required to administer a user provisioning sys...
Selecting a User Provisioning Product
6 Vendor Quality
User provisioning systems typically have a lifespan of at least sev...
Selecting a User Provisioning Product
• Directories and meta directories.
• Systems of record, such as HR and contractor m...
Selecting a User Provisioning Product
7 Conclusions
As described in this document, a user provisioning system is conceptua...
Upcoming SlideShare
Loading in...5
×

Selecting a User Provisioning Solution

488

Published on

User provisioning products help organizations to create, manage and deactivate login IDs and other resources 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 provisioning 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.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
488
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Selecting a User Provisioning Solution"

  1. 1. Selecting a User Provisioning Product © 2014 Hitachi ID Systems, Inc. All rights reserved.
  2. 2. 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.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Fulfillment Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Easy to Use Human Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 i
  3. 3. Selecting a User Provisioning Product 3.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 Automatic Change Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6 Consolidated and Delegated User Administration . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7 Directory Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.7.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 Technology 12 4.1 Platform Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Integration With Other Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 Scalability and Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4 Securing the user provisioning System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5 Security Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6 Effective Audit Trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5 Deployment and Management 20 © 2014 Hitachi ID Systems, Inc. All rights reserved.
  4. 4. Selecting a User Provisioning Product 5.1 Rapid Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.2 Pitfalls to Avoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 © 2014 Hitachi ID Systems, Inc. All rights reserved.
  5. 5. Selecting a User Provisioning Product 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 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. 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 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
  6. 6. Selecting a User Provisioning Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 2
  7. 7. Selecting a User Provisioning Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 3
  8. 8. Selecting a User Provisioning Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 4
  9. 9. Selecting a User Provisioning Product 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. 3.2.2 Pitfalls to Avoid 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 5
  10. 10. Selecting a User Provisioning Product • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 6
  11. 11. Selecting a User Provisioning Product 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. 3.3.2 Pitfalls to Avoid 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 7
  12. 12. Selecting a User Provisioning Product 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. 3.4.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 8
  13. 13. Selecting a User Provisioning Product 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. 3.5.2 Pitfalls to Avoid 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 9
  14. 14. Selecting a User Provisioning Product 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. 3.6.2 Pitfalls to Avoid 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). © 2014 Hitachi ID Systems, Inc.. All rights reserved. 10
  15. 15. Selecting a User Provisioning Product 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. 3.7.2 Pitfalls to Avoid A directory cleanup facility should not: • Automatically deactivate or delete accounts. Such actions should be subject to human control, to prevent costly mistakes. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 11
  16. 16. Selecting a User Provisioning Product 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 significant user population, without requiring significant 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. 4.1.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 12
  17. 17. Selecting a User Provisioning Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 13
  18. 18. Selecting a User Provisioning Product 4.2.2 Pitfalls to Avoid • 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-defined, rigid HR integration, which only works with some kinds of systems of record, or only with specific schema on those systems. • Reliance on a single, authoritative directory. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 14
  19. 19. Selecting a User Provisioning Product 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. 4.3.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 15
  20. 20. Selecting a User Provisioning Product 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 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. 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. 4.4.2 Pitfalls to Avoid • 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 firewalls 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 16
  21. 21. Selecting a User Provisioning Product • “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- files. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 17
  22. 22. Selecting a User Provisioning Product 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. 4.5.2 Pitfalls to Avoid 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 18
  23. 23. Selecting a User Provisioning Product 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). 4.6.2 Pitfalls to Avoid 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 19
  24. 24. Selecting a User Provisioning Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 20
  25. 25. Selecting a User Provisioning Product • 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. 5.1.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 21
  26. 26. Selecting a User Provisioning Product 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. 5.2.2 Pitfalls to Avoid • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 22
  27. 27. Selecting a User Provisioning Product 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 23
  28. 28. Selecting a User Provisioning Product • 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 24
  29. 29. Selecting a User Provisioning Product 7 Conclusions As described in this document, a user provisioning system is conceptually simple, but can be difficult 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 difficult 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

×