Extranet Identity Management: Process and Architecture


Published on

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:

- A comparison of Enterprise IDM with Extranet IDM requirements.

- An overview of business process and technical requirements that arise in Extranet IDM, and suggestions for best practices.

- An overview of business process and technical requirements.

- Proposed solutions, using a combination of Hitachi ID products, third party software and custom software development, as appropriate.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Extranet Identity Management: Process and Architecture

  1. 1. Extranet Identity Management: Process and Architecture © 2014 Hitachi ID Systems, Inc. All rights reserved.
  2. 2. 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
  3. 3. 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
  4. 4. Extranet Identity Management: Process and Architecture 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 defined 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 fit 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 2
  5. 5. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 3
  6. 6. Extranet Identity Management: Process and Architecture 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: © 2014 Hitachi ID Systems, Inc.. All rights reserved. 4
  7. 7. Extranet Identity Management: Process and Architecture 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 profile was 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. 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 5
  8. 8. Extranet Identity Management: Process and Architecture 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 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 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 6
  9. 9. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 7
  10. 10. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 8
  11. 11. Extranet Identity Management: Process and Architecture 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 if possible, to simplify load balancing and server distribution. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 9
  12. 12. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 10
  13. 13. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 11
  14. 14. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 12
  15. 15. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 13
  16. 16. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 14
  17. 17. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 15
  18. 18. Extranet Identity Management: Process and Architecture APPENDICES © 2014 Hitachi ID Systems, Inc.. All rights reserved. 16
  19. 19. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 17
  20. 20. Extranet Identity Management: Process and Architecture – 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 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 © 2014 Hitachi ID Systems, Inc.. All rights reserved. 18
  21. 21. Extranet Identity Management: Process and Architecture 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 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 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 19
  22. 22. Extranet Identity Management: Process and Architecture • 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 © 2014 Hitachi ID Systems, Inc.. All rights reserved. 20
  23. 23. Extranet Identity Management: Process and Architecture 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 21
  24. 24. Extranet Identity Management: Process and Architecture 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