Extranet Identity Management: Process and Architecture

Extranet Identity Management:
Process and Architecture
© 2014 Hitachi ID Systems, Inc. All rights reserved.

Contents
1 Introduction 1
2 Background 2
3 Business Process and Technical Requirements 3
3.1 User Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Ancillary User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Password Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Password Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5 Password Reset vs Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6 Onboarding / User Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7 Directory Scrubbing / User Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.8 Password Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.9 Help Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.10 Scalability and Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Hitachi ID Solution Components 10
4.1 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Product Mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Identity Management vs. Access Management 14
5.1 Deﬁnition: Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Deﬁnition: Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Practical Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
APPENDICES 16
A Hitachi ID Management Suite Overview 17
B Hitachi ID Password Manager Overview 19
C Microsoft ADAM 22
i

Extranet Identity Management: Process and Architecture
1 Introduction
This document is an overview of the identity management requirements that arise in an Extranet portal,
where a corporation provides services to a large number of external users – typically consumers and in
some cases partners.
The remainder of this document covers:
1. A comparison of Enterprise IDM with Extranet IDM requirements.
2. An overview of business process and technical requirements that arise in Extranet IDM, and sugges-
tions for best practices.
3. An overview of business process and technical requirements.
4. Proposed solutions, using a combination of Hitachi ID products, third party software and custom soft-
ware development, as appropriate.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

2 Background
Enterprise IAM presents different challenges than identity and access management in Extranet (B2C or
B2B) scenarios:
Characteristic Enterprise IAM (typical) Extranet IAM (typical)
Number of users under 1 million over 1 million
Number of systems and
directories
2 – 10,000 1 – 2
Users deﬁned before IAM
system is deployed
Thousands Frequently only new users
Login ID reconciliation Existing accounts may have
different IDs on different
systems.
Single, consistent ID per user.
Data quality Orphan and dormant accounts
are common. Data
inconsistencies between
systems.
Single or few objects per user.
Consistent data. Dormant
accounts often a problem.
User diversity Many users have unique
requirements.
Users ﬁt into just a few
categories.
In short, Enterprise IAM has fewer but more complex users. Extranet IAM has more users and higher
transaction rates, but less complexity.

3 Business Process and Technical Requirements
3.1 User Namespace
The first question that should be addressed when considering a system for managing external users is how
to identify them.
If an organization has a pre-existing relationship with the user community, then a pre-existing identifier can
and should be used. Examples of this scenario include:
1. A government providing e-services to tax payers.
2. A University providing services to students.
3. Airline passengers accessing frequent flyer programs.
4. Bank customers accessing their accounts.
BEST
PRACTICE
Use existing identifiers if the users are already known.
Where an organization is enrolling new users, with whom there is no pre-existing relationship, an identifier
will have to be issued to each user. The best identifier is typically the user’s own, pre-existing e-mail address,
for reasons that will be discussed below. Examples of this scenario include:
1. Consumers registering to get technical support from a manufacturer.
2. Buyers enrolling for services with an online store.
BEST
PRACTICE
E-mail addresses are recommended identifiers for users new to the
organization, for several reasons:
1. Users already know them, and are unlikely to forget them.
2. A fully qualified SMTP address is guaranteed to be unique.
3. The user’s login ID can be used to contact the user in addition to logging
the user inn.
BEST
PRACTICE
Whenever sending a user an e-mail, include the e-mail address in the body of
the e-mail, not just in the To: mail header. Users often have mail redirectors
and may not know which of their addresses is their login ID.

3.2 Ancillary User Data
In addition to assigning unique identifiers to all users, typically additional information is required.
Each application will have its own requirements in this regard, but it is important to consider some best
practices regarding user enrollment:
BEST
PRACTICE
Collect only the data required and nothing more.
• Users don’t like to fill in forms.
• A minimal data set reduces the attractiveness of the system to intruders.
BEST
PRACTICE
Protect the privacy of collected data, and publish a privacy statement
describing the protections.
BEST
PRACTICE
Hash or encrypt data wherever feasible.
Consider using JavaScript to perform hash functions on the user’s web browser, to eliminate the possibility
of ever being in possession of sensitive data. For example, social security numbers or credit card numbers
might be used to connect different user profiles to their individual owners, but since this data is sensitive, it
makes sense to hash it on the user’s browser, and store and compare hashes, not useful numbers.
3.3 Password Policy
Most Extranet applications use passwords to authenticate users. Passwords are chosen because they cost
nothing to provision and relatively little to support. Stronger authentication technologies, such as tokens,
smart cards and biometrics, rarely make sense in Extranet deployments, unless compromise of the system
represents significant business risk.
Passwords are intended to reliably establish a user’s identity. The extent to which they are reliable is directly
proportional to the difficulty of guessing them, so it makes sense to require long passwords, block use of
dictionary words, require periodic changes, require both letters and digits, etc.
BEST
PRACTICE
The strength of the password policy should be based on the business risk of
the Extranet application. Passwords to a bank site represent more risk and
should be more complex than passwords on a Internet photo sharing site.
3.4 Password Initialization
There are two options to providing initial user passwords:

1. Assign a random password.
2. Ask the user to choose a password.
BEST
PRACTICE
It is always better to ask users to choose their own passwords.
BAD
IDEA
System-assigned passwords are much harder to remember and consequently
cause support problems.
BEST
PRACTICE
The system should require users to choose passwords that comply with the
password policy.
BEST
PRACTICE
The password policy should be displayed to the user whenever a user is
asked to choose a new (or initial) password. In the event that a user chooses
a weak password, the error message should explain what was wrong with the
password, not just say that it was unacceptable.
3.5 Password Reset vs Retrieval
Inevitably, users will forget their passwords. When this happens, it is important to enable them to repair the
problem using self-service, since human customer support for large user populations is very expensive.
There are several options for supporting users who forget their passwords:
1. Send them their original password by e-mail.
2. Send them a new, random password by e-mail.
3. Send them a randomized URL by e-mail which they can click to access a form where they can choose
a new password.
4. Authenticate the user directly on the web site and then enable the user to choose a password. Au-
thentication may use a number of methods:
(a) Ask the use to answer personal questions, answers to which were enrolled when the user proﬁle
was ﬁrst setup.
(b) Send a random number to the user’s e-mail address and ask the user to type it in.
(c) Send a random number to the user’s SMS cell phone address and ask the user to type it in. This
may be more secure than a normal e-mail, as it asks the user to demonstrate possession of a
physical item (the phone), rather than just of an electronic account (the e-mail address).
BAD
IDEA
Storing passwords increases the security vulnerability of a system, and should
be avoided. Consequently, the “send the user his old password” option is a
bad idea.

BAD
IDEA
Randomly generated passwords create new user support problems so should
be avoided.
Each of these options has an impact on user enrollment:
1. An e-mail address is generally required (preferably as the primary ID, as described above).
2. Personal questions and answers.
3. An SMS-enabled cell phone number, from a vendor that provides an e-mail-to-SMS gateway.
3.6 Onboarding / User Registration
There are basically just two forms of onboarding processes in Extranet applications:
1. Provisioning users that are already represented in a pre-existing system or application.
2. Provisioning brand new users, who are not already known to the organization.
The business process in either case is likely to be:
1. Relatively simple:
• Typically a single web form.
• Some form of identity validation may be required.
2. Very speciﬁc to the needs of the organization:
• Contrast enrollment of a bank customer with signing up a new user at an online retailer.
In general, onboarding is performed using self-service, to lower the cost of the process by eliminating the
need for a central help desk.
Self-service web forms are subject to abuse by robots, so it is important to incorporate a “Captcha” to
differentiate between human visitors and malicious software agents.

BEST
PRACTICE
Combining the above information, onboarding should proceed as follows:
1. Verify that the prospective new user is a human being, using a Captcha.
2. Ask the new user for a login ID. This will either be an existing identifier
related to an association the user has with the organization, or the user’s
e-mail address.
3. Collect a minimal amount of personal information from the user, some of
which will be hashed or encrypted, possibly in the user’s web browser.
4. If required, validate the identifier and other data provided by the user.
5. Get an initial password from the user.
6. Collect any ancillary authentication information from the user, for
purposes of authentication in the event that a password reset is required.
7. Create a new user object in the Extranet’s directory.
3.7 Directory Scrubbing / User Deactivation
Extranet applications may attract large numbers of registrants and over time users may lose interest in the
site and never return. Alternately, users may change their e-mail addresses and be unable to login, or may
create multiple user profiles on the site.
In any of these scenarios, orphan accounts remain on the Extranet directory, and over time these cause the
directory to grow and become increasingly costly to maintain.
It makes sense to remove old accounts, to keep the directory “clean:”
BEST
PRACTICE
Record a time stamp whenever a user successfully logs into the system.
This makes it possible to distinguish between active and inactive users.
BEST
PRACTICE
Send inactive users a warning e-mail.
This allows them to refresh their account and provides a reason for marketing to contact users.
BEST
PRACTICE
Use a long timeout interval – for example, a year of inactivity.
This avoids unnecessary nuisance for infrequent users.

BEST
PRACTICE
Remove accounts that have been inactive for a long time.
In addition to automated directory scrubbing, users should be allowed to remove their accounts from the
system.
BEST
PRACTICE
Always provide a mechanism whereby users can remove their accounts from
the Extranet directory.
A common complaint of visitors to web sites is that once they sign up, they cannot remove themselves.
Failure to provide an unsubscription option can create a small but vocal community of irate users.
3.8 Password Change
BEST
PRACTICE
Users should be able to change their passwords at any time, after
authentication.
Users may want to change passwords because they believe there has been a compromise, or simply to
make them harder to attack.
If the Extranet application represents sufficient business risk, users should be automatically reminded, and
perhaps forced to change passwords regularly (example: every 90 days).
3.9 Help Desk
In some applications, it makes business sense to allow users who have difficulty with the system to call
a central help desk for human (i.e., not self-service) assistance. In these cases, the following must be
considered:
1. How will the help desk staff authenticate themselves to a support application?
2. How will the help desk authenticate the caller? (Example: challenge/response).
3. What will the help desk staff be able to see and do? (Examples: lookup user profiles, reset passwords,
change profile data).
4. Will support actions be logged, and if so will the logging be manual or automated?
3.10 Scalability and Reliability
Extranet applications typically must support:
1. 24x7 operation.

2. Millions of users.
3. Enrollment and identity / authentication proﬁle changes at any time.
4. Reliability in the event of a local network outage.
These requirements lead to some speciﬁc technical requirements:
1. No single point of failure.
2. Support for geographically distributed components.
3. Ability to add and load balance servers as usage grows.
Application components of the Extranet, including identity management components, should be stateless if
possible, to simplify load balancing and server distribution.

4 Hitachi ID Solution Components
4.1 Logical Architecture
A logical architecture showing the components of identity management in an Extranet environment is illus-
trated in Figure 1.
Figure 1: Logical Architecture
In the logical architecture:
• The Extranet User Directory houses all extranet users, including their IDs, passwords and other profile
data.
• The extranet Application(s) authenticate users against this directory (a simple LDAP bind is all that’s
required).
• An onboarding process – principally a self-service web form – is used to add users to the directory.
This process may connect to an existing system to validate already-known users, possibly through
some middleware appropriate to the existing system.
• Users manage their passwords and update personal information using a self-service web app (labeled
“Manage Profiles, Passwords”).
• A batch process is used to periodically find stale user objects and clean them up, typically after
notifying users and giving them a chance to fix the problem.
4.2 Product Mix
The logical components are mapped to products in Figure 2.

Figure 2: Mapping Logical Architecture to Products
Products are chosen for the reasons described below:
• ADAM is a preferred LDAP directory for reasons of low cost and excellent scalability and reliability, as
described in Section C on Page 22.
• Hitachi ID Password Manager supports both initial and ongoing management of user passwords and
profiles:
– Users can fill out their initial profiles, including challenge/response data.
– Users can reset forgotten passwords, using either an e-mailed activation URL or by answering
personal challenge/response questions.
– Users can be authenticated with a two-factor approach, using their SMS-enabled cell phone in
place of a purchased token.
– Users can make routine password changes.
– Users can make updates or corrections to their profile.
• Since the onboarding process is unique to each organization, is relatively simple and will typically
require 20–50 days to develop/configure even if a commercial identity management product is used,
Hitachi ID recommends simple custom development for onboarding.
There is no preference for a software development environment here. The idea is to use whatever
tools an organization is already familiar with, be they ASP.NET, J2EE, PHP, LAMP, etc.
• The data scrubber is nothing more than a simple shell script, and again does not warrant licensing a
product.

4.3 Network Architecture
The products described in Figure 2 are mapped to a typical network architecture in Figure 3.
Public Internet
Application DMZ
Directory DMZ
Internal
Corporate Network
User
Load
Balancer Load
Balancer
Firewall
Firewall
FirewallFirewall
Firewall
Workstation
Extranet
App
Onboarding
Web App
LDAP User
Directory
Customer
Records
Legacy
apps
Middleware to
legacy apps
Outbound
Mail System
A
B
C
E
G
D
H
I
J
F
K
Hitachi ID
Password Manager
Figure 3: Network architecture diagram
In this figure:
A is a redundant pair of firewalls, used to protect the Extranet web application and supporting identity
management infrastructure from Internet-origin attacks. Typically only HTTP and HTTPS to specific
IP addresses will be allowed in from the Internet.
B is a redundant pair of load balancers, used to distribute incoming web sessions across all web appli-
cation components on the DMZ.
C is the Extranet web application. The details of this application are beyond the scope of this document,
but in general it might be any application, running on any platform. Multiple servers are shown, to
illustrate that a high-availability, high-throughput application is likely, leveraging the load balancers
(B).
D is the Extranet directory. When registered users sign into the Extranet application, their user ID and
password are validated by binding to this directory.
E is a customized web application used to onboard new users. The business logic of this application will
depend heavily on the requirements of the Extranet application(s). Since this will inevitably be a very
simple application, there is no economic advantage to building this form on top of a user provisioning
or other identity management product – it’s just one or two forms, after all.

As mentioned earlier, Hitachi ID does not recommend a particular application platform for (E). The
choice of platforms should be based on what is already present in the organization.
F is the Hitachi ID Password Manager software, used to manage user passwords and profiles, as de-
scribed in Figure 4.2 on Page 11.
G is an optional component – middleware that enables the onboarding business logic to verify the iden-
tities of existing customers. If an organization is deploying an Extranet application to a pre-existing
population of users, as described in Subsection 3.1 on Page 3, then some form of middleware will
likely be required to enable the applications shown in E to access existing user profile data shown in
J.
H is an optional component – a set of load balancers which might distribute directory queries across
LDAP servers (D), and might distribute middleware accesses from (E) across
I is an optional component. If the Extranet web application requires access to pre-existing, Intranet
systems, it might do so through this firewall.
J is an optional component. If the Extranet web application requires access to pre-existing, Intranet
systems, this block represents those systems.
K is in most cases a required component. It is an e-mail system used to send various communications
to Extranet users, including enrollment invitations, notifications of upcoming password expiry, notifi-
cations of completed password changes, alerts related to failed authentications, etc. Given the fact
that mail delivered outbound but not accessed by end users, this should be a secure, high-throughput
SMTP service. A good example is Postfix on Linux. This e-mail system should not include support for
rich clients, such as Exchange or an IMAP service, since it is intended for outbound use only.
Also in Figure 3, the infrastructure is distributed across multiple network segments, to create security layers:
• The Public Internet is assumed to be insecure and hostile, but is also the origin of all customer
sessions.
• The Application DMZ network segment is shielded from the Internet by a firewall, and hosts all web
user interface components.
• All web-facing servers have a second set of network interfaces, attached to the Directory DMZ. There
should not be a network route for packets to pass from the Application DMZ to the Directory DMZ.
Instead, application servers can make directory queries, and optionally access a middleware infras-
tructure, using a private network segment.
• If access to the corporate Intranet is required, it should be protected by another firewall – I.

5 Identity Management vs. Access Management
There is sometimes confusion between what is meant by identity management and how that relates to what
is meant by access management. This section is intended to clarify what each term means and how the
two technologies are inter-related.
5.1 Definition: Identity Management
Identity management and access governance is defined as a shared platform and consistent processes for
managing information about users: who they are, how they are authenticated and what they can access.
5.2 Definition: Access Management
Identity management systems are closely related to access management systems, which may consolidate
or strengthen user authentication processes (i.e., single, strong sign-on) and may enforce authorization
policies at run-time. These include:
• Strong authentication, using smart cards, tokens and biometrics.
• Web single sign-on (Web-SSO), typically using cookies to maintain session state, but increasingly
using federation protocols such as SAML and WS-Security.
• Web access management (Web-AM), typically integrated with Web-SSO, which enforce runtime deci-
sions about whether users should be allowed to access specific servers, URLs or application features.
5.3 Practical Impact
In the context of the systems described in this document, identity management components are the follow-
ing:
1. The customer directory (Typically ADAM, shown as D in Figure 3).
2. The user onboarding web application (E in Figure 3).
3. The Hitachi ID Password Manager password and profile management application (F in Figure 3).
Access management may consist of:
1. Logic in the Extranet web application (C in Figure 3) to attempt an LDAP bind with user-entered
credentials, to authenticate users.
2. If there are multiple web applications and if single sign-on is required between them, then an additional
component can be added to the Application DMZ, also connected to the Directory DMZ, to externalize
user authentication from individual applications. This component is called a Web Single Sign-on
product and one example is RSA Access Manager.

3. Alternately, if there are multiple web applications and if the applications run on IIS, then ADFS (Active
Directory Federation Services) can be used, eliminating the need to purchase more software.

APPENDICES

A Management Suite Overview
The Hitachi ID Management Suite is an integrated solution for identity administration and access gover-
nance. It streamlines and secures the management of identities, security entitlements and credentials
across systems and applications. Organizations deploy the Management Suite to strengthen controls, meet
regulatory and audit requirements, improve IT service and reduce IT operating cost.
Management Suite includes Hitachi ID Identity Manager to create, manage and deactivate user identities
and entitlements; Hitachi ID Password Manager to manage all user credentials and Hitachi ID Privileged
Access Manager to secure access to privileged accounts.
The Management Suite is designed as identity management and access governance 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 credentials across multiple systems and platforms. This
is illustrated in Figure 4.
Figure 4: Management Suite Overview: Identity Middleware
Employees, contractors,
customers, and partners
Users Hitachi ID
Management Suite
Target Systems
Business processes
Synch./Propagation
Request/Authorization
Delegated Administration
Consolidated Reporting
User Objects
Attributes
Passwords
Privileges
Related Objects
Home Directories
Mail Boxes
PKI Certs.
The Management Suite includes several functional identity management and access governance modules:
• Identity Manager – User provisioning, RBAC, SoD and access certification.
– Automated propagation of changes to user profiles, from systems of record to target systems.
– Workflow, to validate, authorize and log all security change requests.
– Automated, self-service and policy-driven user and entitlement management.
– Federated user administration, through a SOAP API (application programming interface) to a
user provisioning fulfillment engine.
– Consolidated access reporting.
Identity Manager includes the following additional features, at no extra charge:
– Hitachi ID Access Certifier – Periodic review and cleanup of security entitlements.
* Delegated audits of user entitlements, with certification by individual managers and applica-
tion owners, roll-up of results to top management and cleanup of rejected security rights.
– Hitachi ID Group Manager – Self service management of security group membership.
* Self-service and delegated management of user membership in Active Directory groups.
– Hitachi ID Org Manager – Delegated constuction and maintenance of Orgchart data.
* Self-service construction and maintenance of data about lines of reporting in an organization.
• Password Manager – Self service management of passwords, PINs and encryption keys.

– Password synchronization.
– Self-service and assisted password reset.
– Enrollment and management of other authentication factors, including security questions, hard-
ware tokens, biometric samples and PKI certiﬁcates.
Password Manager includes the following additional features, at no extra charge:
– Hitachi ID Login Manager – Automated application logins.
* Automatically sign users into systems and applications.
* Eliminate the need to build and maintain a credential repository, using a combination of
password synchronization and artiﬁcial intelligence.
– Hitachi ID Telephone Password Manager – Telephone self service for passwords and tokens.
* Turn-key telephony-enabled password reset, including account unlock and RSA SecurID
token management.
* Numeric challenge/response or voice print authentication.
* Support for multiple languages.
• Privileged Access Manager – Control and audit access to privileged accounts.
– Periodically randomize privileged passwords.
– Ensure that IT staff access to privileged accounts is authenticated, authorized and logged.
• Group Manager is available both as a stand-alone product and as a component of Identity Manager.
The relationships between the Management Suite components is illustrated in Figure 5 on Page 18.
Figure 5: Components of the Management Suite

B Password Manager Overview
Overview:
Hitachi ID Password Manager is an integrated solution for managing user credentials, across multiple sys-
tems and applications. Organizations depend on Password Manager to simplify the management of those
credentials for users, to reduce IT support cost and to improve the security of login processes.
Password Manager includes password synchronization, self-service password reset, enterprise single sign-
on, PIN resets for tokens and smart cards, enrollment of security questions and biometrics and emergency
recovery of full disk encryption keys.
Features:
Password Manager streamlines the management of passwords and other login credentials:
• Transparent password synchronization:
When users change their password natively on a system where a password synchronization trigger
has been installed, the new password is subjected to an extra password policy and, if accepted, is
changed both locally and on other systems where the user has accounts.
Password Manager includes password synchronization triggers for Windows server or Active Directory
(32-bit, 64-bit), Sun LDAP, IBM LDAP, Oracle Internet Directory, Unix (various), z/OS and iSeries
(AS/400).
Using a familiar and mandatory password change process guarantees 100% user adoption.
• Web-based password synchronization:
Users can change some or all of their passwords using a Password Manager web interface. The
password policy is clearly explained on-screen and enforced interactively.
Using an interactive web page to change passwords has educational beneﬁts but requires user aware-
ness and cooperation.
• Self-service password reset:
Users who have forgotten a password or triggered an intruder lockout can sign into Password Manager
using other types of credentials and resolve their own problem. Non-password authentication options
include security questions, voice biometrics, smart cards, hardware tokens and random PINs sent to
a user’s mobile phone using SMS.
Access to self-service is available from a PC web browser, from the Windows login screen, using a
telephone or using the mini web browser on a smart phone.
• Many built-in connectors:
Password Manager ships with built-in integrations for over 110 systems and applications. That means
that it can manage passwords, PINs, smart cards and other login credentials on most servers, direc-
tories, network devices, databases and applications without customization.

• Token and smart card PIN reset:
Users with a token who have forgotten their PIN or need an emergency pass code can access self-
service PIN reset with a web portal or using a telephone. Users with a smart card can also reset
their own PIN using an ActiveX control embedded in a web browser – launched from their Windows
desktop or login screen.
• Self-service unlock of a computer with full disk encryption:
Users with full disk encryption software on their PC, who have forgotten the password that unlocks
their computer prior to OS startup, can unlock their hard disk using a self-service process accessed
via telephone.
Password Manager includes a turn-key integrated voice response (IVR) system designed to automate
password resets, PIN resets and unlock of encrypted filesystems via a self-service phone call. It
ships with connectors for popular full disk encryption products from McAfee, CheckPoint, Symantec
and Microsoft.
• Enterprise single sign-on:
Hitachi ID Login Manager client software can be installed on Windows PCs to capture login IDs and
passwords from the Windows login screen and automatically insert these same credentials into appli-
cation login prompts. This eliminates the need for users to repeatedly type their login ID and password
into applications whose credentials are consolidated or synchronized with Windows / Active Directory.
• Assisted password reset:
Authorized IT support staff can sign into a Password Manager web user interface to look up a caller’s
profile, authenticate the caller by keying in answers to security questions and reset one or more
passwords. A ticket is then automatically submitted to the help desk incident management system.
• Password policy enforcement:
Password Manager normally enforces a global password policy to supplement the various policies
enforced on each system and application. This policy ensures that passwords accepted by Password
Manager will work on every system.
The built-in policy engine includes over 50 built-in rules regarding length, mixed-case, digits, dictio-
nary words and more. Regular expressions and plug-ins enable organizations to define new rules.
Password history is infinite by default.
• Password change notification / early warning:
Password Manager can invite users to change their passwords with a web portal before they expire.
These invitations can be sent via e-mail or launched in a web browser when users sign into their PCs.
Users can even be forced to change passwords by launching a kiosk-mode web browser at login time.
Password change notices are normally only sent at the start of users’ work day and work week, to
discourage users from changing passwords right before leaving work and subsequently forgetting the
new password.
Benefits:
Password Manager improves the security of passwords through enforcement of a robust, global policy that
requires passwords to be complex, to be changed periodically and to never be reused. It improves the

security of IT support processes by requiring strong authentication of both the support analyst and caller
prior to any security-related help desk call and by reducing the number of IT support staff who need elevated
privileges to assist users who need help with an intruder lockout, forgotten password or PIN or locked-out
hard disk.
Password Manager improves user service by reducing the number of passwords users must remember,
by automatically populating IDs and passwords into application login prompts and by providing a single,
friendly user interface where users regularly change their passwords.
Password Manager lowers the cost of IT support by reducing the frequency of password-related problems
experienced by users and by enabling users to resolve a variety of authentication-related problems on their
own.

C Microsoft ADAM
Hitachi ID Systems has no financial incentive to recommend any particular directory product, so we consider
ourselves to be impartial in this regard. Moreover, Hitachi ID Systems tends to favour Unix and Linux hosted
solutions, so our natural bias would be against AD/ADAM, which are hosted strictly on Windows/Intel. That
said, we think that AD and ADAM are significantly better than alternative LDAP directories:
1. AD and ADAM scale to about 2,000,000,000,000 objects (this has been empirically tested) and fail
gracefully with reasonable error messages beyond this scale.
2. ADAM is relatively inexpensive, costing nothing beyond a Windows Server operating system license:
(a) Windows Server runs on inexpensive x86 servers.
(b) There is no per-object license fee.
3. OpenLDAP is clean and robust, but does not support multiple master directory servers, so has limited
scalability.
4. The Sun/iPlanet/Netscape and IBM directory products share a source code heritage and unfortunately
that old source code is quite buggy. We have seen serious stability problems with Sun, iPlanet and
IBM directory servers at many of our customer deployments, especially to do with multi-master de-
ployments, insertion of attribute pre- and post-filters, etc. Basically, the Sun, iPlanet and IBM directory
servers are not as reliable as they should be.
5. Only two vendors have large production experience with massively multi-master directories: Microsoft
(AD/ADAM) and Novell (eDirectory). They each have customers with more than 1000 concurrently
active and replicated directory servers – far more scalable and robust, especially in the event of
network outages – than other vendors.
6. Only two vendors have a working group membership infrastructure in their directories – again, Mi-
crosoft and Novell.
Groups in Sun and IBM LDAP directories, in particular, are almost useless. The unidirectional schema
(group objects contain a multi-valued attribute listing users, but user objects do not enumerate group
memberships) mean that it’s too expensive to evaluate queries like “what groups is this user a member
of?” or to cope with environments that have thousands of groups or that have groups containing
thousands of users.
Strong group infrastructure is present in AD and eDirectory because of their vendors’ respective net-
work OS heritage. Conversely, weak group infrastructure mean that Sun and IBM directory products
are useless as a back end to a NOS and support only fairly simplistic access control models.
7. Openness and standards-compliance are important in a directory product. Oddly (despite buying
SuSe), Novell has the most closed directory product on the market. Hitachi ID Systems cannot, in
good conscience, recommend eDirectory for this reason.
8. Support for nested groups is often a useful strategy for constructing a complex authorization infras-
tructure. Only Active Directory and ADAM support nested groups.
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/extranet-arch/extranet-idm-arch-2.tex
Date: 2008-05-12

Extranet Identity Management: Process and Architecture

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

More from Hitachi ID Systems, Inc.

More from Hitachi ID Systems, Inc. (20)

Recently uploaded

Recently uploaded (20)

Extranet Identity Management: Process and Architecture