Novell is now a part of Micro Focus

Novell e-Login: A single identity for Internet customers

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 5 Jun 2001

Problem - Too many unique logins

As Novell's external websites evolved and increased in complexity, it became necessary to restrict access to specialized content. This typically occurred for one of two reasons: either because Novell wanted to restrict access to generic premium content, or wanted to provide content customized for the individual. Business units began solving the problem for their particular customer populations, and today Novell has various databases of individuals and organizations that contain anywhere from a few hundred to several hundred thousand records to meet the specific needs of each business unit.

Most Novell customers deal with more than one internal business unit. By creating separate islands for entitlement to each group's specialized content, Novell perpetuated a fragmented experience for its customers that potentially threatened credibility as the directory company. In short, the problem is:

  • Customers do not have a single set of credentials when doing business with Novell on the web.
  • Depending on Novell's relationship with an individual or an organization, several different unlinked digital identities could be required to authenticate when doing business online.

The following example illustrates a possible scenario a current customer could experience.

Let's suppose John Doe is studying to become a Novell Certified Engineer while employed in a technical position with one of our MLA customers. It is conceivable that John could perform the following activities on just one visit to in the course of any particular day.

  • John checks the details of his CNE certification information on the Education Web Site
  • John connects to the Premium Support area of the NTS web site to review a currently logged problem he is having on one of his systems at his company
  • John then decides to visit ShopNovell to order a Novell Press book
  • He then connects to the MLA Web Ordering System to order some software as part of his company's MLA contract
  • John finally connects to the DeveloperNet site to download the latest NDK.

In order for John to complete these separate functions while attached to, he would have to type in four separate user IDs and passwords -- three for him as an individual and one for his company. In addition, he would have to re-key his credit card and address information for the book he ordered on ShopNovell because his identity is not tracked there. It is almost as if John had visited four different companies instead of just one. This is a poor way to provide customers with a personalized user experience while visiting Novell electronically.

This problem is not unique to Novell. Many large companies have a similar problem in instances where their various web initiatives evolved separately. As a leading provider of Net Services software, Novell should provide a leadership role in the complete solution to this problem as the company aligns with strategic initiatives related to the eDirectory.

Solution - eLogin

Today there are more than one million separate digital identities in over a dozen different relational databases that are accessed by hundreds of applications to support the online authorization and authentication needs of It would be next to impossible to migrate those databases to a common Web Identity and Profile in a single cutover. Novell needed a way to begin working towards a common Web Identity and Profile that could be migrated over time but that would still provide value to the end user and to the corporation. In short, the solution is to:

  • Map the core components of each of the separate entitlement systems into a common Web Identity and Profile to be stored in Novell's eDirectory.
  • Deploy an environment that will allow each of the disparate systems that comprise the ability to consume this new common Web Identity and Profile to provide both a single identity and single sign-on.
  • Provide a framework for web application developers to migrate from their existing identity systems to the common Web Identity and Profile.

The following needed to occur in order to deliver a complete solution to this problem:

Storing the Data - eDirectory

  • Establish a common eDirectory schema for the storage and retrieval of customer profile information for use on the Web.
  • Enable the capturing of information needed to facilitate access to legacy systems.
  • Create an eDirectory tree design to facilitate the scalability and performance of Novell's web-based applications globally.
  • Design replication for load balancing and fault tolerance.

Web Security - iChain

  • Establish a web architecture that simplifies, accelerates, and secures user credentials.
  • Design an architecture that enabled load balancing and fault tolerance.

Tying it all Together - Application Code

  • Target key applications that will be migrated in the first phase to the new common Web Identity and Profile (WebIDUser). The WebIDUser was created to be a thin object that holds application-related information, as opposed to the standard NDS user object which was created as a LAN/WAN user that is part of the company.
  • Create a self-registration process that will allow customers to create a WebIDUser and associate with legacy entitlement systems that have been made WebIDUser aware.
  • Ensure that applications that are made WebIDUser aware will support both the legacy ID and the new common WebIDUser until all of their users are migrated
  • Provide single sign-on among the separate systems in that are made WebIDUser aware.

Referencing the example above, by implementing the eLogin solution to this problem John's user experience would be dramatically simplified and improved. He would need to authenticate only once and the "system" would pass information about him to each back-end application he wanted to visit. His experience would feel personalized due to the fact that each application would "recognize" him as John Doe.

The following pages discuss in detail the process flow, eDirectory, iChain, and Self-Registration components that make up Novell's e-Login solution.

System Overview

The following diagram illustrates the process flow for Novell's e-Login solution.

Storing the Data - eDirectory

In order to implement a world-class solution, Novell considered key functional areas where the directory is superior to other forms of data storage. The following is a discussion around those considerations.

Scalability and Redundancy

The directory must scale well to handle rapid and constant growth. Not only will the directory need to scale to millions of users, but it must be able to handle thousands and potentially tens of thousands of hits per minute. The directory must be redundant and be able to load balance in order to provide near-zero wait time response.

The system must have redundant fail-over capability so that there is no single point of failure. Each instance of the directory around the world must have similar redundancy, as the system must be available at all times. There cannot be a single point of failure once the system is running in a production environment.

LDAP is the access protocol that will communicate to eDirectory. It can also be used for management purposes. It enables the simplest form of directory management for disparate data stores. It is industry standard and Novell is a strong supporter of the directory protocol.


Novell created a custom NDS object called WebIDUser that uses customer-built NDS objects as AUX classes to hold credential data for the legacy applications. A WebIDUser may or may not have AUX classes associated with their user. Using AUX classes allows for flexibility in managing the data stored in the directory. The system has references from the WebIDUser to the AUX classes for each of the entitlement systems that maintains its own user data store.

Some applications cannot rely on eDirectory for all profile information and will maintain their own data store in addition to what is stored in eDirectory. If the data in one data store, or the other, is modified by the user and is accessible by each data store, it will need to be synchronized. DirXML drivers were written in order to synchronize user data stores with legacy applications. This allows event driven synchronization to go one way or bi-directionally. When a user performs self-management on profile information (e.g. home address, e-mail address, etc.), the information propagates to the entitlement systems that require synchronization. Novell used event triggers to capture modifications in the application's data store, and the DirXML connectors are the best tools to use for this level of synchronization.

Web Security - iChain

To identify users and to verify their access privileges, i-Chain provides a variety of authentication mechanisms. To secure access to Novell's website, the iChain Authentication Proxy functions as the primary access point. When a user tries to authenticate to Novell's website, the Authentication Proxy checks the eDirectory policies defined for that user and determines the user's access rights. Based on the user's profile and access rights, the iChain Authentication Proxy then authenticates the user to all of the web servers and web applications that the user is authorized to use.

iChain incorporates several security mechanisms that ensure the privacy of data sent over the Internet; for example, iChain supports the use of Secure Sockets Layer (SSL) to ensure privacy when data is transmitted between the web site and the browser.

Because the iChain Authentication Proxy supports today's most popular web servers and applications, Novell could integrate its existing web infrastructure and present users with a cohesive unified web experience. By logging in with one username and password, a user can automatically access protected web sites and applications that previously required authentication. The main iChain infrastructure consists of Novell eDirectory 8.5, the iChain Authorization Server, and the iChain Internet Caching Server, or iChain ICS for short.

Novell iChain Internet Caching System Server

The Novell iChain Internet Caching System server operates only in reverse proxy mode (also called accelerator mode). A reverse proxy accepts requests for web site data from external users and delivers most of that data from its own cache. The proxy contacts the web server hosting that data only when the data in its own cache is out of date or when additional processing, such as a database lookup, is required.

Most reverse proxies interact with a single web server, but the Novell iChain Internet Caching System server has multihoming capabilities. As a result, Novell uses a single public IP address from the iChain Internet Caching System server to front-end multiple backend web servers. iChain protects the company's web servers by rendering them essentially invisible: All outbound information appears to originate from the Novell iChain Internet Caching System server.

Novell iChain Authentication Service

The Novell iChain Internet Caching System server interfaces with the Novell iChain Authentication service. This service enables users to use one or both of two authentication methods, which are reflected in the eDirectory as the Lightweight Directory Access Protocol (LDAP) Authentication profile and the Secure Sockets Layer (SSL) Mutual Authentication profile.

The LDAP Authentication profile enables users to use a loginID and password pair to authenticate to the Novell iChain Internet Caching System server. The SSL Mutual Authentication profile enables users to use an X.509 certificate to authenticate to the Novell iChain Authentication server. The LDAP Authentication Profile object has several attributes, one of which is the LDAP Login Name Format attribute. By default, the Login Name Format is a user's distinguished NDS name. Novell chose an alternative method; namely, enabling the LDAP Field Name parameter. The LDAP Field Name parameter allows Novell to specify any LDAP attribute which users can then use as their login name.

The iChain Authentication process works as follows:

  1. When a user makes a request for web site data, the iChain Internet Caching System server checks its authentication table to determine if this user is already authenticated.
  2. Assuming the user is not authenticated, the iChain Internet Caching System server consults the eDirectory for the authentication policy, which the eDirectory promptly returns. The iChain Internet Caching System server then switches to an HTTPS port and sends a request for authentication to the user.
  3. The user enters authentication credentials, and the iChain Internet Caching System server authenticates the user (assuming, of course, the user's credentials are valid).
  4. The iChain Internet Caching System server also sends a session cookie to the user's browser, which the browser stores in memory.

Novell iChain Authorization Service

After a user is authenticated, the iChain Authorization service ensures that users do not access any data except the data they are authorized to access. The iChain Authorization service authorizes access requests based on rules that Novell created and stored as eDirectory objects. The iChain Internet Caching System server stores these objects in its cache for improved performance.

Novell lists the various protected URLs within the Access Rule objects. Being able to control access based on the URL enables Novell to control access right down to specific pages; however, this doesn't mean every page requiring access control must be listed. The Access Rule objects also include wildcard options, enabling Novell to can grant access to broader areas of the web site without having to specify the URL to each page within an area. For example, a rule that includes an asterisk (*) in the URL, as in*, grants users associated with this rule access to all pages under

All users associated with a particular Access Rule object can access the URLs listed within that object. Access Rule objects also have an exception list, which allows additional security by disallowing access to users listed as exceptions. By default, all access is denied through the Novell iChain Internet Caching System server; however, for Novell's public website a public access policy was created to allow access to public areas without requiring authentication.

Application Code

Self Registration

Novell determined that it was not efficient to create the user object from the legacy application data and try to combine the duplicates, and therefore determined to allow the user to create their identity, map themselves to their application credentials, and prove authenticity through the use of self-registration. Self-registration is the simplest and quickest way to populate the eDirectory with any sort of accuracy. The legacy entitlement systems require different credentials that must be captured by self-registration. These credentials will be tested prior to initial inclusion in the eDirectory.

The customer has visual contact to the results of e-Login in three key areas:

  1. Self-registration - Customers will be allowed to self-register over the course of about 6 months in order to participate in single point authentication of the eDirectory. Self-registration consists of a web form designed by Novell, which captures required profile information and authentication credentials for entitlement systems to which the user has been granted access. Self-registration validates authentication credentials prior to storing them in the eDirectory as part of the user's WebIDUser. It also allows adding authentication credentials to the eDirectory in situations where the user has been granted new access to an application that he/she did not previously have when the WebIDUser was originally created. Self-registration allows users to change their identity information and application credentials, and allows for forgotten username, forgotten password, and change password functionality with out having to contact Novell.
  2. Login - Customers will be prompted to login to the eDirectory whenever a participating entitlement system is accessed on a per-session basis, or they can login upon accessing the website and be taken to the Welcome Back page to view the links to the systems to which they are entitled. The login form will prompt for eDirectory authentication credentials which the user selected during self-registration.
  3. Updating profile information - Customers will be allowed to modify select profile attributes of his/her WebIDUser such as password, address, and so forth.

Customers will no longer experience the disparate login systems once authenticated to the eDirectory.

The following rules were considered for user management within the Self-Registration code:

  1. User must be able to modify password.
  2. User must be able to submit changes to remaining WebIDUser fields.
  3. User interface for password modification must be simple.
  4. User must be able to get their user name via e-mail and change their password if they know their username and challenge string answer.
  5. User must have access to some form of help, electronic, help button, live, etc.

Legacy Applications

The following rules were considered for deciding which legacy applications become WebIDUser aware:

  1. Developers on staff to make modifications to accept authentication credentials
  2. Developers on staff to export profile information to desired format. This will allow for easier tree population.
  3. Each group has direct access to the web interface.
  4. Application can accept name value pair, or application can query DS for the authentication credentials it needs.
  5. User creation, modification, and deletion functions fall within scope of eDirectory functionality.
  6. Application owners have testing staff available to validate implementation.

The following diagram illustrates the layers of custom self-registration code.


The following is a short list of considerations used when planning to deploy e-Login at Novell. As with any custom implementation, other deployments may vary by size and complexity.

  • Deployment planning: A development eDirectory tree should be created on which most testing will take place. Separate hardware will be used for the pilot and live implementations.
  • Data conversion: The eDirectory will store user and profile data necessary to uniquely and unambiguously identify an authorized user. This data will come from existing web application databases, and be linked to eDirectory by user self registration.
  • Technical training and learning: This project is an more of and architecture and implementation project than a product distribution project. As such, Novell's IT department will own the management and implementation of the project. Information will be provided to web publishers to enable them to make their applications WebIDUser aware.
  • Full product utilization: Customers who elect to self register for single point authentication to the eDirectory will immediately notice full product utilization in the realm of access to which they currently have authentication or entitlement rights. As an ongoing project, new applications should utilize the e-Login infrastructure for user validation, and users of those applications will be able to become part of the eDirectory as authenticated users.
  • Product deployment: Will be rolled out in phases; e.g., run the pilot, then modify applications to become WebIDUser aware including the exporting of user profile information. Finally, the self-registration modules will come on-line to allow customers to create their own WebIDUser and associate it with entitlement systems to which they currently have access rights.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates