Hitachi ID Solution Components
A logical architecture showing the components of identity management in an Extranet environment is illustrated in Figure [link].
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.
The logical components are mapped to products in Figure [link].
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
- 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
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.
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 application 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 Password Manager software, used to manage user passwords and
profiles, as described in (_label_psynch-functions).
- G: is an optional component -- middleware that enables the
onboarding business logic to verify the identities of existing
customers. If an organization is deploying an Extranet
application to a pre-existing population of users, as
described in (_label_existing-users), 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
- 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, notifications 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 (Screenshot:extranet-arch-network), 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 infrastructure,
using a private network segment.
- If access to the corporate Intranet is required, it should be protected by another firewall -- I.