extranet identity management: process and architecture

Extranet Identity Management:

Process and Architecture

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

http://Hitachi-ID.com/

http://Hitachi.com/

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 Definition: Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2 Definition: 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 insome 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 orB2B) scenarios:

Characteristic Enterprise IAM (typical) Extranet IAM (typical)

Number of users under 1 million over 1 million

Number of systems anddirectories

2 – 10,000 1 – 2

Users defined before IAMsystem is deployed

Thousands Frequently only new users

Login ID reconciliation Existing accounts may havedifferent IDs on differentsystems.

Single, consistent ID per user.

Data quality Orphan and dormant accountsare common. Datainconsistencies betweensystems.

Single or few objects per user.Consistent data. Dormantaccounts often a problem.

User diversity Many users have uniquerequirements.

Users fit into just a fewcategories.

In short, Enterprise IAM has fewer but more complex users. Extranet IAM has more users and highertransaction 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 howto identify them.

If an organization has a pre-existing relationship with the user community, then a pre-existing identifier canand 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.

BESTPRACTICE

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 identifierwill 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.

BESTPRACTICE

E-mail addresses are recommended identifiers for users new to theorganization, 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 loggingthe user inn.

BESTPRACTICE

Whenever sending a user an e-mail, include the e-mail address in the body ofthe e-mail, not just in the To: mail header. Users often have mail redirectorsand 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 bestpractices regarding user enrollment:

BESTPRACTICE

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.

BESTPRACTICE

Protect the privacy of collected data, and publish a privacy statementdescribing the protections.

BESTPRACTICE

Hash or encrypt data wherever feasible.

Consider using JavaScript to perform hash functions on the user’s web browser, to eliminate the possibilityof ever being in possession of sensitive data. For example, social security numbers or credit card numbersmight be used to connect different user profiles to their individual owners, but since this data is sensitive, itmakes 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 costnothing 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 systemrepresents significant business risk.

Passwords are intended to reliably establish a user’s identity. The extent to which they are reliable is directlyproportional to the difficulty of guessing them, so it makes sense to require long passwords, block use ofdictionary words, require periodic changes, require both letters and digits, etc.

BESTPRACTICE

The strength of the password policy should be based on the business risk ofthe Extranet application. Passwords to a bank site represent more risk andshould 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.

BESTPRACTICE

It is always better to ask users to choose their own passwords.

BADIDEA

System-assigned passwords are much harder to remember and consequentlycause support problems.

BESTPRACTICE

The system should require users to choose passwords that comply with thepassword policy.

BESTPRACTICE

The password policy should be displayed to the user whenever a user isasked to choose a new (or initial) password. In the event that a user choosesa weak password, the error message should explain what was wrong with thepassword, 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 theproblem 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 choosea 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 profilewas first 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. Thismay be more secure than a normal e-mail, as it asks the user to demonstrate possession of aphysical item (the phone), rather than just of an electronic account (the e-mail address).

BADIDEA

Storing passwords increases the security vulnerability of a system, and shouldbe avoided. Consequently, the “send the user his old password” option is abad idea.



BADIDEA

Randomly generated passwords create new user support problems so shouldbe 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 specific 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 theneed for a central help desk.

Self-service web forms are subject to abuse by robots, so it is important to incorporate a “Captcha” todifferentiate between human visitors and malicious software agents.



BESTPRACTICE

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 identifierrelated to an association the user has with the organization, or the user’se-mail address.

3. Collect a minimal amount of personal information from the user, some ofwhich 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, forpurposes 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 thesite and never return. Alternately, users may change their e-mail addresses and be unable to login, or maycreate multiple user profiles on the site.

In any of these scenarios, orphan accounts remain on the Extranet directory, and over time these cause thedirectory to grow and become increasingly costly to maintain.

It makes sense to remove old accounts, to keep the directory “clean:”

BESTPRACTICE

Record a time stamp whenever a user successfully logs into the system.

This makes it possible to distinguish between active and inactive users.

BESTPRACTICE

Send inactive users a warning e-mail.

This allows them to refresh their account and provides a reason for marketing to contact users.

BESTPRACTICE

Use a long timeout interval – for example, a year of inactivity.

This avoids unnecessary nuisance for infrequent users.



BESTPRACTICE

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 thesystem.

BESTPRACTICE

Always provide a mechanism whereby users can remove their accounts fromthe 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

BESTPRACTICE

Users should be able to change their passwords at any time, afterauthentication.

Users may want to change passwords because they believe there has been a compromise, or simply tomake them harder to attack.

If the Extranet application represents sufficient business risk, users should be automatically reminded, andperhaps 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 calla central help desk for human (i.e., not self-service) assistance. In these cases, the following must beconsidered:

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 profile changes at any time.

4. Reliability in the event of a local network outage.

These requirements lead to some specific 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 ifpossible, 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 profiledata.

• The extranet Application(s) authenticate users against this directory (a simple LDAP bind is all that’srequired).

• 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 throughsome 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 afternotifying 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, asdescribed in Section C on Page 22.

• Hitachi ID Password Manager supports both initial and ongoing management of user passwords andprofiles:

– 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 answeringpersonal challenge/response questions.

– Users can be authenticated with a two-factor approach, using their SMS-enabled cell phone inplace 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 typicallyrequire 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 whatevertools 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 aproduct.



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

UserLoad Balancer Load

Balancer

Firewall

Firewall

FirewallFirewall

Firewall

Workstation

ExtranetApp

OnboardingWeb App

LDAP UserDirectory

CustomerRecords

Legacyapps

Middleware tolegacy apps

OutboundMail System

AB

C

E

G

D

H

I

J

F

K

Hitachi IDPassword 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 identitymanagement infrastructure from Internet-origin attacks. Typically only HTTP and HTTPS to specificIP 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, toillustrate 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 andpassword are validated by binding to this directory.

E is a customized web application used to onboard new users. The business logic of this application willdepend heavily on the requirements of the Extranet application(s). Since this will inevitably be a verysimple application, there is no economic advantage to building this form on top of a user provisioningor 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). Thechoice 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-existingpopulation of users, as described in Subsection 3.1 on Page 3, then some form of middleware willlikely be required to enable the applications shown in E to access existing user profile data shown inJ.

H is an optional component – a set of load balancers which might distribute directory queries acrossLDAP 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, Intranetsystems, it might do so through this firewall.

J is an optional component. If the Extranet web application requires access to pre-existing, Intranetsystems, this block represents those systems.

K is in most cases a required component. It is an e-mail system used to send various communicationsto Extranet users, including enrollment invitations, notifications of upcoming password expiry, notifi-cations of completed password changes, alerts related to failed authentications, etc. Given the factthat mail delivered outbound but not accessed by end users, this should be a secure, high-throughputSMTP service. A good example is Postfix on Linux. This e-mail system should not include support forrich 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 customersessions.

• The Application DMZ network segment is shielded from the Internet by a firewall, and hosts all webuser interface components.

• All web-facing servers have a second set of network interfaces, attached to the Directory DMZ. Thereshould 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 whatis meant by access management. This section is intended to clarify what each term means and how thetwo technologies are inter-related.

5.1 Definition: Identity Management

Identity management and access governance is defined as a shared platform and consistent processes formanaging 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 consolidateor strengthen user authentication processes (i.e., single, strong sign-on) and may enforce authorizationpolicies 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 increasinglyusing 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-enteredcredentials, to authenticate users.

2. If there are multiple web applications and if single sign-on is required between them, then an additionalcomponent can be added to the Application DMZ, also connected to the Directory DMZ, to externalizeuser authentication from individual applications. This component is called a Web Single Sign-onproduct and one example is RSA Access Manager.



3. Alternately, if there are multiple web applications and if the applications run on IIS, then ADFS (ActiveDirectory 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 credentialsacross systems and applications. Organizations deploy the Management Suite to strengthen controls, meetregulatory and audit requirements, improve IT service and reduce IT operating cost.

Management Suite includes Hitachi ID Identity Manager to create, manage and deactivate user identitiesand entitlements; Hitachi ID Password Manager to manage all user credentials and Hitachi ID PrivilegedAccess Manager to secure access to privileged accounts.

The Management Suite is designed as identity management and access governance middleware, in thesense that it presents a uniform user interface and a consolidated set of business processes to manageuser objects, identity attributes, security rights and credentials across multiple systems and platforms. Thisis 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./PropagationRequest/AuthorizationDelegated AdministrationConsolidated Reporting

User Objects

AttributesPasswordsPrivileges

Related Objects

Home DirectoriesMail BoxesPKI 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 certificates.

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 artificial intelligence.

– Hitachi ID Telephone Password Manager – Telephone self service for passwords and tokens.

* Turn-key telephony-enabled password reset, including account unlock and RSA SecurIDtoken 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 thosecredentials 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 emergencyrecovery 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 triggerhas been installed, the new password is subjected to an extra password policy and, if accepted, ischanged 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. Thepassword policy is clearly explained on-screen and enforced interactively.

Using an interactive web page to change passwords has educational benefits 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 Managerusing other types of credentials and resolve their own problem. Non-password authentication optionsinclude security questions, voice biometrics, smart cards, hardware tokens and random PINs sent toa user’s mobile phone using SMS.

Access to self-service is available from a PC web browser, from the Windows login screen, using atelephone 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 meansthat 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 resettheir own PIN using an ActiveX control embedded in a web browser – launched from their Windowsdesktop 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 unlockstheir computer prior to OS startup, can unlock their hard disk using a self-service process accessedvia telephone.

Password Manager includes a turn-key integrated voice response (IVR) system designed to automatepassword resets, PIN resets and unlock of encrypted filesystems via a self-service phone call. Itships with connectors for popular full disk encryption products from McAfee, CheckPoint, Symantecand Microsoft.

• Enterprise single sign-on:

Hitachi ID Login Manager client software can be installed on Windows PCs to capture login IDs andpasswords 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 passwordinto 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’sprofile, authenticate the caller by keying in answers to security questions and reset one or morepasswords. 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 policiesenforced on each system and application. This policy ensures that passwords accepted by PasswordManager 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, todiscourage users from changing passwords right before leaving work and subsequently forgetting thenew password.

Benefits:

Password Manager improves the security of passwords through enforcement of a robust, global policy thatrequires 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 callerprior to any security-related help desk call and by reducing the number of IT support staff who need elevatedprivileges to assist users who need help with an intruder lockout, forgotten password or PIN or locked-outhard 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 problemsexperienced by users and by enabling users to resolve a variety of authentication-related problems on theirown.



C Microsoft ADAM

Hitachi ID Systems has no financial incentive to recommend any particular directory product, so we considerourselves to be impartial in this regard. Moreover, Hitachi ID Systems tends to favour Unix and Linux hostedsolutions, so our natural bias would be against AD/ADAM, which are hosted strictly on Windows/Intel. Thatsaid, 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 failgracefully 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 limitedscalability.

4. The Sun/iPlanet/Netscape and IBM directory products share a source code heritage and unfortunatelythat old source code is quite buggy. We have seen serious stability problems with Sun, iPlanet andIBM 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 directoryservers 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 concurrentlyactive and replicated directory servers – far more scalable and robust, especially in the event ofnetwork 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 groupmemberships) mean that it’s too expensive to evaluate queries like “what groups is this user a memberof?” or to cope with environments that have thousands of groups or that have groups containingthousands 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 productsare 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 buyingSuSe), Novell has the most closed directory product on the market. Hitachi ID Systems cannot, ingood 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: [email protected]

File: /pub/wp/documents/extranet-arch/extranet-idm-arch-2.texDate: 2008-05-12

http://Hitachi-ID.com/

extranet identity management: process and architecture

Technology

users new

extranet identity management

users dened

complex users

users dont

users t

hitachi id systems

ancillary user data