• Site Map
• Contact Us

• Home
• Solutions
• Products
• Services
• News &  Events
• Resource Center
• Community
• Our Company

Hitachi ID Identity Manager White Paper

Abstract

This document describes the business problems of user provisioning: slow resource provisioning, redundant systems administration and unreliable access termination. It then describes how Hitachi ID Identity Manager (formerly ID-Synch) addresses these problems with process change and user provisioning technology. Finally, the business benefits of effective user provisioning are described.

Introduction

This document describes the business problems of user provisioning: slow resource provisioning, redundant systems administration and unreliable access termination. It then describes how Hitachi ID Identity Manager addresses these problems with process change and user provisioning technology. Finally, the business benefits of effective user provisioning are described.

Hitachi ID Identity Manager is the user provisioning component of Hitachi ID Management Suite. Hitachi ID Management Suite is described in [link].

The remainder of this document is organized as follows:

• Business Problems With User Provisioning

  The motivation for deploying Hitachi ID Identity Manager.

• Shared Identity Management Infrastructure

  How the proliferation of systems, each with their own user database, creates an administrative problem, and how consolidating administration of user identity can help.

• Streamlined User Provisioning Processes

  How Hitachi ID Identity Manager simplifies management of user identity data across multiple, heterogeneous systems.

• Hitachi ID Identity Manager Technology

  The Hitachi ID Identity Manager network architecture, and design features that make it scalable, secure and deployable.

• Return on Investment

  A basic ROI model describing how Hitachi ID Identity Manager can generate significant cost savings.

• Summary

Business Challenges With User Provisioning

Several factors combine to make management of users and their security rights a growing challenge for many organizations:

• The number of individual systems and platforms that users must access is large and growing.

• Users are increasingly dependent on systems access: they cannot do their jobs without it.

• Organizations cannot afford additional IT staffing to cope with the growing burden of systems administration. On the contrary, most organizations would prefer to reduce the size of IT as a proportion of organization size.

These factors lead to the following costly business problems:

• Overloaded administration: Access / security administrators are overworked. This leads to staff burn-out and turn-over. Overloaded administrators are prone to make errors, and improperly assign privileges.

• Lost productivity: Requests for new access are delayed, and the productivity of users waiting for new access rights is reduced.

• Security risk: System access persists even after users change responsibility or leave an organization. This is not only a serious security vulnerability, but can violate regulatory requirements for effective internal controls.

Hitachi ID Identity Manager is an automated user provisioning solution, designed to address these challenges.

Shared Identity Management Infrastructure

Systems administration burden is growing because there are an increasing number of systems to manage, and because almost every system manages user profiles in its own silo. For example, a single (human) user might have a personal profile on the mainframe, an LDAP directory, an e-mail system, an ERP system and elsewhere. Each of these systems is managed separately -- by different administrators, using different tools.

The natural solution for this problem is to consolidate information about users (sometimes referred to as user directories or security databases) into a single repository, and configure every system to refer to that single repository as an authoritative system of record regarding user identity.

This approach has some merit, hence the popularity of LDAP. However, it also has problems:

• Many systems are not compatible with LDAP, and cannot externalize their user/security databases.
• Some systems that can externalize user data can only do so for some attributes, and continue to have internal user profiles, which must still be managed directly.
• Many systems require data about users that is special to them, and would not benefit any other part of the IT infrastructure. If the data storage requirements of every application were added to a single LDAP directory, then the schema would grow to thousands of attributes per user -- thus creating new performance, scalability, reliability and management problems.
• Some user-related data is confidential, and does not belong in a shared directory.

The result of these problems is that while LDAP has helped to slow the proliferation of user databases, organizations continue to require, and must still manage, multiple systems that house data about users.

Since most organizations continue to have multiple user directories, the next best solution is to implement consolidated processes to manage user objects and access rights across multiple systems.

Hitachi ID Identity Manager is designed to provide a shared set of processes and infrastructure to manage users and access across heterogeneous systems. It implements multiple processes that an organization can use to provision, update and deactivate user access to multiple systems.

Streamlined User Provisioning Processes

User Lifecycle

The basic lifecycle of identity management begins with hiring a user. This triggers creation of one or more system login accounts and other user objects (e.g., HR record, phone book entries, etc.).

Over time, the user will make numerous routine password changes, and may periodically forget his password, and require an administrative password reset on one or more systems.

As the user moves through an organization, changing job functions and possibly locations, the systems he must access, and his required privileges on those systems will change.

Finally, when a user leaves an organization, his access rights must be terminated. In most cases, his actual IDs persist for a while, until they are no longer required. In many organizations, user identifiers are never reused, to support long-term audit trails.

Each of the above processes is traditionally handled separately on each system. Each system has its own user directory and user/security management tools. In most organizations, each application is managed by its own administrators.

Hitachi ID Identity Manager, a part of Hitachi ID Management Suite, is designed to leverage a single set of business processes to manage users and access rights on multiple systems, as illustrated in Figure [link].

    User Lifecycle Management (1)

Automated Change Propagation

Hitachi ID Identity Manager can monitor one or more systems of record on a periodic basis (e.g., nightly or every few hours), enumerating new, deleted and changed users. In the case of an HR application, for example, these changes may represent new hires, terminations and transfers. Auto-discovery is performed on all integrated systems and applications -- not just systems of record.

Changes detected by Hitachi ID Identity Manager are passed through a data filter, which removes users that are outside Hitachi ID Identity Manager's scope. For instance, in a scenario where Hitachi ID Identity Manager manages all users in one country, but the HR system is global, Hitachi ID Identity Manager would ignore changes to users from other countries.

All changes to a given user are aggregated and business logic is executed, with the set of changes as input. This is best illustrated with some examples:

Detected change	Actions	Net result
New user appears in an HR application.	Lookup appropriate role based on the user's location and job code. Submit a change request to the Hitachi ID Identity Manager workflow engine, to create a new user, with the HR-provided identity attributes and with resources specified by the role.	Auto-provisioning.
New phone number detected on white pages directory.	White pages has a higher priority for the phone number attribute than other systems. Submit a change request to the Hitachi ID Identity Manager workflow engine, to change the phone number in the user's profile. Once approved (most likely automatically), the new phone number is mapped to other login IDs belonging to the user, and agents are run to update this information on other systems.	Identity synchronization.
Change to termination date is detected on the HR system.	Using the identity synchronization mechanism described above, set this date on the user's profile. A separate batch process periodically identifies users with today or earlier termination dates, and submits requests to disable all accounts for every matching user.	Automated termination.
User disappears from system of record (HR).	Lookup all of a user's login IDs. Submit a "disable all accounts" change request to the Hitachi ID Identity Manager workflow engine. Given the source of the request (employee gone from HR), this type of change may be auto-approved.	Automated termination (2nd method).
User was added to Administrators group on Active Directory domain.	Since the change was detected on AD, it follows that it was not initiated by Hitachi ID Identity Manager. Submit two change requests to the workflow engine: Remove the user from the Administrators group (this is an auto-approved change). Add the user from the Administrators group (requires approval). Submit a security alarm ticket to the help desk system.	Detect unauthorized privilege escalation.

 

Collectively, these processes are known as automated user management. They are implemented by the ID-Track component in Hitachi ID Identity Manager.

Several Hitachi ID Identity Manager modules are involved in automated user management:

1. The PSUPDATE auto-discovery engine, which extracts lists of users, attributes, groups and group memberships from every integrated system and application. In most deployments, PSUPDATE runs nightly.

2. The LOADDB batch loader, which collects detected changes to users on target systems and updates the internal identity cache accordingly.

3. Login ID mapping data, which connects unique user identifiers on different systems. For example, this may map employee numbers in HR to login IDs on other systems. This data may be the produced through consistent login IDs, mapping other attributes or self-service reconciliation initiated through invitations sent to users.

4. The ID-Track module, which aggregates changes on a per-user basis and executes organization-specific business logic for each changed user. This business logic typically submits workflow change requests based on detected changes.

5. The API service, which accepts change requests from ID-Track and/or external programs and submits them to the workflow service.

6. The IDWFM workflow service, which accepts change requests, validates them, fills in missing data (e.g., assigning login IDs and e-mail addresses), selects suitable authorizers and invites them to approve or reject each change.

7. The IDTM transaction manager, which accepts approved changes from the workflow engine and runs connectors to effect changes. IDTM retries failed updates to enable reliable updates to target systems.

8. A set of agents (connectors), almost all of which run locally on the Hitachi ID Identity Manager server, each of which is designed to discover and manage users on a particular type of system or application.

Change Request Workflow

A key capability in Hitachi ID Identity Manager is to accept change requests, to route them to the appropriate authorizers, and to act on change requests once sufficient authority has been received. This is designed to streamline requests, and to eliminate the need for system administrators to manually fulfill authorized changes.

Hitachi ID Identity Manager's workflow automation engine streamlines the process of requesting and authorizing the creation of new accounts, as well as other security changes such as add/remove group membership, change attribute value, rename or move user, delete or deactivate user and so on.

The Hitachi ID Identity Manager workflow engine uses secure web input (HTTPS) and prompts authorizers for input using e-mail (normally SMTP).

The workflow automation engine works as follows:

• Request input:
  • Users can authenticate to the system and make change requests.
  • Change requests are formulated as changes to user profiles -- the requester's or another user's (the recipient).
  • Change requests may be to change data attributes, add new accounts, add or remove group memberships, enable accounts or disable accounts. In other words, changes are formulated as changes to user profiles, in relation to the recipient user's current state.
  • Plug-in programs can limit or alter requests -- for example by limiting who can submit a request, by limiting what requesters can ask for, by validating or filling in fields in a request, or by assigning a login ID to new users.
  • Requests may be for changes to user attributes or to add or remove single login accounts, collections of privileges (roles) or physical objects (e.g., tokens, building access badges, etc.).

• Request routing:
  • Requests are automatically routed to appropriate authorizers, which are selected based on the identity of the requester and based on the roles and templates requested.
  • All authorizers are prompted to respond concurrently. Authorizers may delegate alternates in their absence.
  • In most cases, a response is only required from a subset of the authorizers -- for example, any one of three people can approve access to a system.
  • Authorizers are notified by e-mail that their input is required. They click on a URL embedded in the e-mail to respond.
  • Authorizers may be prompted to respond repeatedly if no response is received within a defined period. Requests that are pending response for too long may be escalated to new authorizers or to an incident management system.

• Authorization:
  • Authorizers review requests using a web form, over a secure connection (HTTPS).

• Executing approved requests:
  • Once adequate authorization has been collected, Hitachi ID Identity Manager can automatically create login IDs, update existing IDs or request action from system administrators and others using e-mail and incident management system integration.

The Hitachi ID Identity Manager workflow engine has built-in support for automatic reminders, escalation and delegation:

• When authorizers are first chosen, their out-of-office status on their primary e-mail system may be checked, to trigger early escalation.
• Non-responsive authorizers that have been asked to review a request receive automatic reminders. The reminder interval is configurable.
• Authorizers who remain non-responsive are automatically replaced with alternate authorizers, identified using escalation business logic. Escalation is most often based on OrgChart data -- i.e., the original authorizer's direct manager is often the escalated authorizer.
• Authorizers may delegate their authority, temporarily or permanently. Delegation may trigger its own approval -- asking the new authorizer to accept responsibility.
• A workflow manager can reassign the authorizers attached to open requests, for instance when they are terminated or when a request is urgent and the authorizer is unavailable.

Templates and Roles to Simplify Configuration

(2) Hitachi ID Identity Manager provisions new users with templates and roles:

• Rather than requiring an administrator to provide every parameter when creating a new account, Hitachi ID Identity Manager copies all relevant parameters from a template account. In effect, Hitachi ID Identity Manager implements a "clone user" operation in place of a "create user" operation.

• Note that not every user object on every target system may be cloned. Requiring Hitachi ID Systems customer administrators to specify template accounts ensures that users whose profiles have grown over time, and which contain inappropriate security privileges, are not cloned.

• Change requests, automated updates or actions initiated in the consolidated or delegated administration modules may specify attributes which override those copied from the template. Examples of request attributes that affect new IDs are employee number, phone number, e-mail address, login ID, directory OU, home directory server, mail server, etc.

• Attributes may be entered by a user or administrator (e.g., phone number), may be validated by a plug-in that implements business logic (e.g., building code) or may be assigned by a plug-in that implements business logic (e.g., login ID, directory OU, e-mail address). Plug-ins embody business rules, and may be as simple or as complex as required.

• Template accounts and membership in security groups are collected into named sets called roles. This allows requests to specify whole sets of new privileges, rather than one account or security group at a time. This simplifies the request process for users, who may not have a clear, technically accurate idea of what accounts or group memberships they require.

  Normally, a role represents every system access required by a user who does a particular job. Roles may also represent functional groups, such as "network access" or "e-mail access."

• Roles may be nested, to simplify definition of incrementally larger access privileges.

• Requests for access may incorporate any combination of roles, template accounts and group memberships. They need not be purely role-based.

(3) Hitachi ID Identity Manager does not require that users be classified into roles. While policy-based provisioning, where users' real access privileges are compared to those predicted by their role membership is technically possible with Hitachi ID Identity Manager, Hitachi ID Systems recognizes that most organizations will be unable to reliably and fully classify existing users into roles, so user/role classification and policy reconciliation is not an Hitachi ID Identity Manager pre-requisite.

Search tags are attached to templates and roles in Hitachi ID Identity Manager, to make them easier to find by end-users. Search tags include type and location. Resources such as templates, roles and managed groups also are associated with authorizers.

Consolidated and Delegated Security Administration

Delegated user administration makes it possible to grant limited security privileges to departmental or regional staff. For example, an IT administrator at a business unit may be allowed to create new users in that business unit, and manage the user profiles and access privileges of local users. The same IT administrator would be unable to access user profiles for staff working in other business units and may only be able to perform certain types of updates, on certain systems.

Delegated user administration is implemented in the same manner as consolidated user administration, but with the addition of access controls, as is illustrated in Figure [link].

    Consolidated and Delegated User Administration Console (4)

The scope of authority of a given security administrator can be limited to certain users, certain systems, certain groups or certain OUs. Access controls are normally implemented using business logic, which accesses information about both the IT administrator and intended recipients of security changes, to dynamically determine what kinds of updates are allowed.

Enterprise-wide Security Reporting

All data in Hitachi ID Identity Manager is available via SQL or ODBC and accessible using standard analytical tools (Crystal Reports, MS-Access, MS-Excel, SQL queries, etc).

The schema is well documented and is available to all product licensees and evaluators under NDA. The current release schema documentation is about 127 pages long, and includes detailed descriptions of every field, table, relation, value constraint, etc.

Data available through Hitachi ID Identity Manager includes:

• A list of IDs per user.
• A list of IDs per system.
• A list of IDs per group.
• Allocation of login IDs to user profiles.
• Full detail of transaction history.
• Additional user attributes (e.g., roles, employee ID) for users who were created using Hitachi ID Identity Manager.
• Select user attributes drawn from target systems -- such as last login time/date, account enabled/disabled, etc.

Hitachi ID Identity Manager includes a number of standard reports, available through a web user interface, from the command-line, or by e-mail:

• Orphan and dormant accounts.
• Users who have accounts on specific systems.
• Templates and roles that a particular user has been assigned.
• User groups available on target systems.
• Membership of users in user groups on target systems.
• Transaction history per time period.
• Authorizer actions.
• Delegations (current and pending).
• Implementer definitions.
• Physical inventory availability.
• Requests, by status, state and result.
• Request statistics.
• User attributes, by user and by system.
• Past Reports.

Advantages of the reporting subsystem in Hitachi ID Identity Manager include:

• The Hitachi ID Identity Manager schema is a simple, relational, ODBC-accessible database. This makes it open to reports by third party programs, such as Crystal. In comparison, some competing products store all their data in opaque XML blobs, and are therefore not accessible by third party reporting software.
• A rich set of built-in reports, including lists of users, accounts, group memberships, workflow requests, etc.
• Dual-format output (HTML, CSV) in all reports.
• Asynchronous report generation -- i.e,. generate a report, and display it as the data is produced.
• Availability of all reports both from the web console and command-line, where they can be scheduled for automatic execution.
• Availability of full schema documentation, which is guaranteed correct, as it is automatically generated from the same source files as the database tables themselves.
• Full access to raw data by any 3rd party reporting tools.

Web Services Flexibility

An API (application programming interface) is exposed by Hitachi ID Identity Manager, supporting features such as creating or deleting users on target systems, modifying user membership in security groups, modifying user attributes, submitting workflow requests, looking up resource information and approving or rejecting open requests.

The API (application programming interface) is accessed using SOAP and includes a WSDL specification.

The Hitachi ID Identity Manager API (application programming interface) is particularly useful for extending meta directories to manage new types of target systems and for enabling custom-written and third-party workflow engines to complete a user provisioning operation with actual updates to target systems, rather than with instructions to a human security administrator.

Hitachi ID Identity Manager Technology

Network Architecture

Hitachi ID Identity Manager is designed for:

• Security:

  Hitachi ID Identity Manager is installed on hardened servers. All sensitive data is encrypted in storage and transit. Strong authentication and access controls protect business processes.

• Scalability:

  Multiple Hitachi ID Identity Manager servers can be installed, using a built-in data replication facility. Workload can be distributed using any load-balancing technology (IP, DNS, etc.).

• Openness:

  Open standards are used for inbound integration (SOAP) and outbound communications (SOAP, SMTP, HTTP, etc.).

• Flexibility:

  Both the Hitachi ID Identity Manager user interface and all functionality can be customized to meet enterprise requirements.

• Low TCO:

  Hitachi ID Identity Manager is easy to set up and requires minimal ongoing administration.

    Network architecture diagram (5)

Figure (_label_fig:combined-net-arch) illustrates the Hitachi ID Identity Manager network architecture:

• Users normally access Hitachi ID Identity Manager using HTTPS from a web browser.

• Multiple Hitachi ID Identity Manager servers may be load balanced using either an IP-level device (e.g., Cisco Local Director, F5 Big/IP) or simply using DNS round-robin distribution.

• Native password changes on some systems ([link]) may trigger transparent password synchronization. A password change interceptor DLL, library or exit may capture such changes and initiate transparent password synchronization.

• Users may call an IVR (interactive voice response) system with a telephone and be authenticated either using touch-tone input of personal information or using a voice print. Authenticated users may initiate a password reset.

• Hitachi ID Identity Manager connects to most target systems using their native APIs (application programming interfaces) and protocols and thus requires no software to be installed locally on those systems.

• Local agents are provided and recommended for Unix servers and z/OS mainframes. Use of these agents improves transaction security, speed and concurrency.

• A local agent is mandatory on RSA SecurID servers.

• Where target systems are remote and communication with them is slow, insecure or both, a Hitachi ID Identity Manager proxy server may be co-located with the target system in the remote location. In this case, servers in the main Hitachi ID Identity Manager server cluster initiate fast, secure connections to the remote proxies, which decode these transactions and forward them to target systems locally, using native, slow and/or insecure protocols.

• Hitachi ID Identity Manager can look up and update user profile data in an existing system, including HR databases (ODBC), directories (LDAP) and meta-directories (e.g., WMI to Microsoft ILM).

• Hitachi ID Identity Manager can send e-mails to users asking them to register or to notify them of events impacting their profiles. Over 163 events can trigger e-mail notification.

• Hitachi ID Identity Manager can send write tickets to most common help desk systems, either recording completed activity or requesting assistance (security events, user service follow-up, etc.). Over 163 events can trigger ticket integration. Binary integrations are available for 16 help desk applications and open integration is possible using mail, ODBC, SQL and web services.

Supported Target Platforms

Hitachi ID Identity Manager has built-in integration for many common types of systems, plus programmable agents that can be readily adapted to manage IDs and passwords on applications and hosted services.

The supported platforms may be summarized as follows:

(6)

Directories	File/print	Mainframes
LDAP (any), Active Directory, Windows NT domains, Novell eDirectory, Novell NDS, Unix NIS and NIS+, Kerberos/DCE (any)	Windows NT/2000/2003/2008, Novell NetWare, OS2 LanManager, Samba	z/OS, RACF, CA-ACF2, CA-TopSecret, VM/ESA, Siemens BS2000, Tandem NonStop, Unisys MCP
Unix	Midrange	Database
AIX, DGUX, Digital Unix, HPUX, IRIX, Linux, NCR, OSF4, SCO OS, Solaris, SunOS, Tru64, UnixWare, Unisys, passwd, shadow, Trusted Computing Base	HP MPE, OS/400/iSeries, OpenVMS	DB2/UDB, Informix, MSSQL, ODBC, Oracle, Sybase
ERP	Messaging	WebSSO
SAP R/3 4.0+, PeopleSoft 7.5+, Oracle Applications 11i+, JDE OneWorld	MS Exchange 5.5, MS Exchange 2000/03/07, Novell GroupWise, Lotus Domino/HTTP, Lotus Notes/ID files, HP OpenMail	IBM TAM, RSA ClearTrust, Entrust getAccess, CA SiteMinder, Oracle COREid, SAP portal
Flexible agents	Hardware tokens and Smartcards	Miscellaneous
API (application programming interface) integration, LDAP attributes, MQ Series, SQL commands, Telnet/TN3270/TN5250 sessions, Unix/Windows cmd-line integration, web forms, web services (SOAP, XML)	RSA SecurID, Secure Computing SafeWord, Vasco Digipass, GemPlus, Precise Biometrics	BMC Service Desk Express, Clarify eFrontOffice, Connected Backup, IBM OLAP, IBM Tivoli Access Manager, Local and cached Windows passwords, HP Service Manager, RADIUS (various), BMC Remedy ARS and Tivoli ADSM,

 

(7)Hitachi ID Identity Manager includes a number of flexible agents, each of which is programmable (and thus can be said to embody an SDK (software development kit)). These agents allow organizations to quickly and with a minimum of programming or scripting, integrate Hitachi ID Identity Manager with custom and vertical market applications.

Flexible agents expose a number of processes, including:

• Binding to an existing management API (application programming interface) (Java, Win32, Unix, COM, etc.).
• Screen-scraping Telnet, TN3270, TN5250, SSH and raw TCP socket connections.
• Navigating through web-based administration user interfaces over HTTP and HTTPS, with support for cookies, form parsing, redirects, etc.
• Executing arbitrary SQL code on Oracle, Sybase, MSSQL, DB2/UDB, Informix and other (ODBC) types of databases.
• Executing command-line administration programs on Unix (via local agent) and Win32 (on the Hitachi ID Identity Manager server).
• Manipulating arbitrary attributes in an LDAP directory.
• Posting updates to a web service (SOAP or other XML dialect over HTTP or HTTPS).
• Sending messages using MQ Series.

Organizations that wish to write a completely new agent to a custom or vertical market application may do so using whatever development environment they prefer (J2EE, .NET, Perl, etc.) and invoke it as a command-line or web service target using the appropriate Hitachi ID Identity Manager flexible agent.

An effort of between four hours to four days is typically required to integrate Hitachi ID Identity Manager with a custom or vertical market application. This compares favorably with competitive products, where a custom Java or other 3GL connector must be written from scratch, taking weeks or months and requiring the Hitachi ID Identity Manager administrator to have significant programming experience and the ability to quickly learn how to use a new framework and API.

In most cases, Hitachi ID Identity Manager does not require the installation of local agent software on target systems. The only exceptions to this are two applications which do not publish a remote administration facility at all: RSA Authentication Manager servers and Entrust getAccess servers.

Hitachi ID Identity Manager does include local agents for deployment on Unix and z/OS servers. While users and passwords on these systems can be managed without a local agent -- by emulating a terminal session of Telnet, TN3270 or using SSH -- such terminal connections are slower, less reliable and (except for SSH) less secure than what is possible with a local agent.

Ultimately, Hitachi ID Systems customer must decide whether reduced change control or more secure, fast and reliable administration are more important on Unix and z/OS systems and therefore make a determination about whether local agents will be installed on these systems.

In no case do the provided local agents interfere with the target system's normal operation -- the login process on each target system remains the same and no significant CPU or other load is placed on target systems.

Process Integration

Identity management is integral to an organization's business processes, and Hitachi ID Identity Manager is designed to integrate with existing processes and systems:

• Monitoring authoritative directories / rules-based user provisioning

  Hitachi ID Identity Manager can monitor an existing system of reference, and create or delete accounts on managed systems based on changes. This works with HR systems, LDAP directories or simple text file extracts.

• Routing requests

  By default, change requests are routed based on the resources specified. For example, all requests for accounts payable access go to one or more authorizers attached to that account type.

  The list of authorizers required to approve a request may be adjusted based on other variables:

  • The identity of the requester (e.g., Executives submitting requests may not require approval; others may require approval by someone in their management chain.)
  • The identity of the recipient.
  • Other attributes of the request (location, department code, etc.).

  To maximize flexibility, the process of adjusting the list of authorizers is implemented with a plugin architecture.

• Assigning new, standard login IDs

  Login IDs for new accounts can be assigned manually by a designated approver, or automatically by a plugin program that implements site-specific logic (for example, rules such as first initial + last name + unique digit).

• Escalating requests for authority

  Hitachi ID Identity Manager supports many features to ensure that requests for authorization are satisfied quickly:

  • Grouping authorizers, and only requiring approval from a subset of each group.
  • Temporarily delegating authority, so that authorizers can safely leave for holidays and other absences.
  • Sending reminders to unresponsive authorizers.
  • Automatically escalating unfulfilled requests for approval.

• Acting on behalf of existing processes

  Some organizations already have a working, automated process to submit, route and approve change requests. What these organizations require is automation to act on approved requests.

  Hitachi ID Identity Manager exposes both a web service and library-level RPCs to enable existing workflow processes to trigger administration actions, such as creating new accounts and updating or deactivating existing ones, on managed systems.

Scalability

Scalability in a combined system for user provisioning, access management and password management is primarily relevant to the password management component:

• User provisioning is uniform over time -- change requests and administrative actions may take place on any day, at any hour. In other words, users may be hired, moved or terminated at any time.
• In contrast, password management is bursty. Most password changes happen at login time in the morning with the largest spikes occurring directly after a weekend or holiday.
• Password management and in particular password synchronization, is needed periodically by all users, not just those being hired, moved or terminated.

Typical peak transaction rates for a 10,000 person organization are 10 events/hour for provisioning and 5,000 events/hour for password synchronization.

Accordingly, the following discussion focuses on Hitachi ID Password Manager (formerly P-Synch), since password management requires extreme scalability, which account provisioning does not. Hitachi ID Identity Manager is built on the same scalable architecture, but simply does not require the same benefits.

(8) Hitachi ID Password Manager has been deployed by very large corporations. Examples of large deployments include:

• Organizations with over 250,000 Hitachi ID Password Manager users managing passwords on a single Hitachi ID Password Manager instance, load balanced between just two servers.
• Users distributed over six continents.
• A single Hitachi ID Password Manager instance, running on a single server, managing passwords on over 500 password systems.
• Deployment of 20 Hitachi ID Password Manager servers, with real-time data replication between them, to allow users to access the system even in the face of network outages.

Hitachi ID Password Manager features that support scalability include:

• The ability to install multiple instances per server.
• The ability of instances to span multiple servers, where each server in a group is functionally identical; supporting the same users, systems and features.
• A built-in, high-performance identity cache, which includes server-to-server data replication in real time.

  This engine has been benchmarked at millions of record updates per second on Windows/Intel servers. The database uses standard, open-format files (xBase/DBF) to ensure compatibility with existing reporting and analytical tools.

• Built-in services to monitor server health and dynamically update DNS records; for example to remove a malfunctioning server from load balancing rotation.

In addition, Hitachi ID Password Manager incorporates many features that, while not directly performance-related, are required by large organizations:

• The ability to operate across firewalls: between the user and Hitachi ID Password Manager, as well as between Hitachi ID Password Manager and managed systems.
• Inclusion of a proxy service, which allows a Hitachi ID Password Manager server in one location to manage passwords elsewhere, across slow and/or insecure WANs.
• Support for multiple user interfaces and UI languages per server instance.
• Auto-discovery of user IDs on managed systems, to eliminate ongoing manual administration and to minimize initial configuration effort.
• The ability to support self-service password reset for users who forgot their initial NOS login password without having to deploy desktop software (secure kiosk account).
• Support for 21 user interface languages.

Security

Hitachi ID Identity Manager improves the security of user access administration by establishing the following processes:

• When users leave the organization, their systems access is terminated promptly and reliably.
• All access changes are subject to a rigorous, globally-enforced approvals process.
• Audit reports listing accounts per user and access privileges for users across systems can be generated easily and used to identify and remove inappropriate access privileges.
• Access change history, including who submitted each request, who approved it and the change details, are logged and available as an audit trail.
• Orphan and dormant accounts are easily identified and are subsequently deactivated and deleted.
• New accounts are created in compliance with security policy and standards.
• Initial passwords are never set to default, guessable values and are never transmitted in plaintext e-mail.

Hitachi ID Identity Manager is designed to be secure. It is protected using a multi-layered security architecture, which includes running on a hardened OS, using file system ACLs, providing strong application-level user authentication, filtering user inputs, encrypting sensitive data, enforcing application-level ACLs, and storing log data indefinitely.

Hitachi ID Identity Manager never requires plaintext passwords to be stored in configuration files or scripts and does not store plaintext passwords anywhere. Hitachi ID Identity Manager does not ship with a default administrator password -- one must be typed in at installation time.

These security measures are illustrated in Figure [link].

    Network architecture security diagram (9)

Rapid Deployment

Hitachi ID Systems solutions are optimized for rapid deployment -- this is a core design characteristic across all products in the Hitachi ID Management Suite. Features such as a dynamic workflow, an architecture which does not depend on role engineering, auto-discovery of users on target systems and self-service login ID reconciliation are all designed to eliminate costly deployment steps and minimize ongoing administration.

Hitachi ID Identity Manager is designed for rapid deployment:

• Single, Dynamic Workflow for Change Authorization

  Simplifies configuration and maintenance of authorization processes. A single flow-chart (state diagram) is used to authorize all requests in the Hitachi ID Identity Manager workflow engine. The Hitachi ID Identity Manager workflow engine supports:

  • Parallel change authorization.
  • Authorizers who can reroute or rewrite change requests.
  • Multiple groups of multiple authorizers.
  • Automatic reminders to unresponsive authorizers.
  • Automatic escalation, when authorizers continue to be unresponsive.
  • Delegation -- for example, when authorizers take extended leaves of absence.
  • Authorizers with veto power over some or all of a request.

  Using a single, dynamic workflow, enterprises can focus on the key questions in an identity management workflow system:

  • Is the change request syntactically correct and appropriate in its business context?
  • Whose authority is required before the request can be implemented?

  This eliminates the need to define hundreds of flow-charts for various kinds of change requests.

• No requirement for role engineering

  Hitachi ID Identity Manager works without a formal model of user privileges, which may take years to develop. Automation can provision coarse-grained access for new users, and terminate all access for departed staff, without a detailed model of rights for each job code.

  Workflow addresses the need to provision users with more fine-grained privileges using a request/approval/audit process, which requires very little work to setup.

• Cloning model users

  Hitachi ID Identity Manager creates new users by cloning existing ones, which have been identified by the Hitachi ID Identity Manager administrator as "models." This eliminates the need for Hitachi ID Identity Manager administrators and platform administrators to collaborate in fully specifying the configuration of all new users.

(10) Hitachi ID Password Manager is designed for rapid deployment:

• No client software required, even for access to self-service password reset from the workstation login prompt.

• Automated discovery of every login ID on every managed system, nightly.

• Self-service login ID reconciliation where login IDs on different systems are different and there is no pre-existing correlation data.

• A built-in identity cache that captures user profile data and eliminates the need to install or manage a database or directory before installing Hitachi ID Identity Manager.

• Pre-built agents for 70+ systems eliminating the need for customers to develop their own connectors to common, off-the-shelf target systems.

• Remote agents mean that Hitachi ID Identity Manager can manage users and passwords on systems without requiring the installation of intrusive local software on each target system.

• Flexible agents enable organizations to integrate Hitachi ID Identity Manager with custom applications, vertical market software, application service providers (ASPs) and service bureaus quickly -- taking just 2 hours to 4 days per new target system.

Return on Investment

Hitachi ID Identity Manager realizes cost savings for security administrators and enhanced productivity for users through:

• User Productivity: Users get new and changed access more quickly.

  New hires can be provisioned in hours rather than days or weeks. Staff with changed responsibilities get updated access privileges immediately, rather than waiting for changes to be approved and implemented.

• Reduced Administration Transaction Volume: Security administrators are freed from routine tasks.

  Routine tasks, such as setting up standard systems access for new users, deactivating access after routine terminations and making changes to user attributes or group memberships can be handled by automated processes and self service. Security administrators are freed to focus on more valuable tasks.

• Improved administrator efficiency: Administrators can manage user access to multiple systems from a single console.

  A consolidated web console allows both global and regional / departmental security administrators to manage any user's access to any combination of systems from a single point. This reduces time wasted switching between native administration programs, duplicate input and platform-specific training.

---

Summary

Efficient and reliable user provisioning yields better productivity for users, reduced administration overhead, and better security.

Hitachi ID Identity Manager allows organizations to streamline their user provisioning, access management and termination processes through:

• Automation / Change Propagation:
  Changes to user profiles on authoritative systems (e.g., HR or contractor management) trigger automatic updates to the same users' profiles on managed systems.
• Self service / Workflow:
  Users or automatic processes submit change requests -- to provision new access, change existing user profiles or deactivate users. Requests are automatically routed to business users with suitable authority, who approve or reject them. Approved changes are applied to managed systems.
• Consolidation:
  Security administrators with an enterprise-wide scope of authority update user access to multiple managed systems from a single security administration console, that creates a consolidated view of multiple security databases.
• Delegation:
  Regional or departmental security administrators are granted limited access to manage some users, on some systems, through the consolidated security administration console.
• Fulfillment:
  This is not so much a process, rather the ability of one user management system to implement changes initiated on another system.

Hitachi ID Identity Manager is designed to be scalable, secure and easy to deploy.

---

Appendix: Hitachi ID Management Suite Overview

(11)

Hitachi ID Management Suite is a complete identity management solution that enables organizations to more securely and efficiently manage the user lifecycle across enterprise applications and systems.

Hitachi ID Management Suite combines the power of Hitachi ID Systems flagship technologies, Hitachi ID Identity Manager for user provisioning and Hitachi ID Password Manager for password management with more targeted products including Hitachi ID Group Manager (formerly ID-Access) to manage user access rights, Hitachi ID Access Certifier (formerly ID-Certify) to review user rights and clean up stale privileges and Hitachi ID Privileged Password Manager (formerly ID-Archive) to securely manage privileged passwords.

Hitachi ID Management Suite creates real business value by increasing productivity for users, reducing IT overhead, strengthening network security and providing internal controls to support compliance with privacy protection and corporate governance regulations.

Hitachi ID Management Suite is designed as identity management middleware, in the sense that it presents a uniform user interface and a consolidated set of business processes to manage user objects, identity attributes, security rights and authentication factors across multiple systems and platforms. This is illustrated in Figure [link].

    Hitachi ID Management Suite Overview: Identity Middleware (12)

Hitachi ID Management Suite includes several functional identity management modules:

• Hitachi ID Identity Manager -- Automated Onboarding, Synchronization and Deactivation.
  • Automated propagation of changes to user profiles, from systems of record to target systems.
  • Self-service workflow, for security change requests.
  • Consolidated and delegated user administration.
  • Federated user administration, through a SOAP API (application programming interface) to a user provisioning fulfillment engine.
  • Consolidated access reporting.

• Hitachi ID Access Certifier -- Periodic Review and Privilege Cleanup.
  • Delegated access reviews, with roll-up of audit results and certification to the top of the management structure.

• Hitachi ID Password Manager -- Synchronization and Self-Service Password Reset.
  • Password synchronization.
  • Self-service and assisted password reset.
  • Enrollment and management of other authentication factors, including Q-A (Question-and-Answer) profiles, hardware tokens, biometric samples and PKI certificates.

• Hitachi ID Group Manager -- Self-Service AD Group Management.
  • Self-service and delegated administration of group membership in Active Directory groups and Exchange 2000/2003/2007 mail distribution lists.

• Hitachi ID Org Manager (formerly ID-Org) -- Distributed Relationship Management.
  • Self-service construction and maintenance of data about lines of reporting in an organization.

• Hitachi ID Privileged Password Manager -- Administrator and Service Account Security.
  • Periodically randomize privileged passwords.
  • Ensure that IT staff access to privileged passwords is authenticated, authorized and logged.

• Hitachi ID Login Manager (formerly P-Synch/SSO) -- Automated Application Login.
  • Automatically sign users into systems and applications.
  • Eliminate the need to build and maintain a credential repository, using a combination of password synchronization and artificial intelligence.

• Hitachi ID Phone Password Manager (formerly ID-Telephony) -- Telephone Self Service.
  • Turn-key telephony-enabled password reset, including account unlock and RSA SecurID token management.
  • Numeric Q&A or voice-print authentication.
  • Support for multiple languages.

The relationships between Hitachi ID Management Suite components is illustrated in Figure [link].

    Components of Hitachi ID Management Suite (13)

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