PDF

swipe to navigate

Hitachi ID Solution Components

Logical Architecture

A logical architecture showing the components of identity management in an Extranet environment is illustrated in Figure [link].

Logical Architecture

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.

Product Mix

The logical components are mapped to products in Figure [link].

Mapping Logical Architecture to Products

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 [link].

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

Network Architecture

The products described in Figure (Screenshot:extranet-arch-products) are mapped to a typical network architecture in Figure [link].

Network architecture

Network architecture

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

PDF

Comment via LinkedIn