Novell is now a part of Micro Focus

Understanding Novell's iChain: A Technical Overview

Articles and Tips: article

David Doering
Senior Analyst
TechVoice
dave@techvoice.com

Bob O'Dell
Product Manager
Novell Business Portal Services
rodell@novell.com
Special thanks to Paul MacKay of Novell for his assistance with this AppNote.

01 Feb 2001


Despite recent improvements in hardware and vertical market software, it remains difficult to construct an effective Business-to-Business (B2B) solution that appeals to both administrators and to corporate and general consumers. With the introduction of Novell's iChain solution, network designers can now develop a single-sign-on Web site that is both easy to use and easy to manage. This AppNote explains the architectural concepts behind the iChain system and looks at the data flow and processes within the system.

Introduction

Creating and managing an effective e-commerce or extranet site is a complex and challenging task. Yet it is a critical one, as market forces are demanding more and more from Web sites. In the past, the first-generation sites (principally just online billboards) and second-generation sites (generic online shopping carts) were adequate. Now, however, the need is to retain users with a pleasant, productive, and interactive site. The demands of eBusiness require significant personalization and heightened security if external partners and suppliers are to be granted access to specific corporate information. Despite the many challenges involved in business-to-business interaction, it is a task that few can afford to put off much longer. The question isn't 2B or not 2B . . . it is "How soon will you B2B?"

For example, a typical B2B scenario is a supplier needing up-to-the-minute inventory numbers to ensure prompt delivery of new stock as required. Past practices used proprietary mainframe systems that discouraged, rather than encouraged, use. Another hurdle was the parochial, rather than agnostic, approach taken by most software offerings. Moreover, access to such systems was not universal. A browser-based solution would be ideal to counter this limitation, but what about the back-end pieces of the B2B puzzle?

Novell's iChain platform addresses the demands of B2B systems in a way that greatly simplifies their deployment and usability, especially in a multivendor environment. Novell iChain 1.5 is an integrated solution designed to securely link all the disparate elements of your network into one secure infrastructure. The iChain solution leverages Novell's Internet Caching System (ICS) to provide secure access to company information and databases. On the back end, iChain leverages NDS eDirectory to serve as a single repository of users' authentication information and access control privileges.

As a foundation for eBusiness solutions, iChain provides these core services:

  • Installation services

  • Proxy services

  • Authentication services

  • Authorization services

  • Web Single Sign-On services

  • Management services

  • Community services

The iChain ICS component provides the installation, proxy, authentication, and authorization services. Web Single Sign-On services are provided through iChain ICS and the Authorization Server. The iChain Authorization Server also handles management services. Community services will be available through Novell Consulting.

Overview of the iChain Architecture

As described above, business-to-business communication requires secure, personalized access on a scalable platform. This section provides an overview of the iChain architecture and demonstrates how it fulfills these B2B requirements.

Simple Web Site

Using Web servers and database management systems (DBMSs) that are readily available today, we could construct a simple Web site such as the one shown in Figure 1. It features a single DBMS application at the back end, with a single Web server at the front end.

A simplistic single-server, single-application Web site.

In this basic scenario, access control could be handled through a single security mechanism, either in the Web server itself or in the DBMS. While this simple design provides for easier management, it is neither flexible nor scalable enough to handle the demands of B2B.

Real-World Web Site

Figure 2 illustrates the type of Web site that is common to many businesses today. It features a "farm" of Web servers at the front end, supporting multiple DBMS and application servers at the back end.

This real-world scenario presents many challenges to network designers and Web developers:

  • Configuring access to multiple Web sites and back-end applications

  • Updating this access as users' needs change

  • Requiring multiple passwords for users to authenticate to each service

  • Scaling access to tens- and hundreds-of-thousands of users

  • Enhancing security to prevent hacking or unauthorized access

A more typical Web site implementation with multiple application servers and Web servers.

Another significant challenge is to do the above in a heterogeneous environment. A proprietary solution based on a single vendor's products might work, but this limits your flexibility in choosing additional components as your site grows. Yet having components from multiple vendors returns us to the piecemeal management picture we want to avoid. What we need is a solution, not multiple management tools and separate directories.

The iChain Solution

The iChain architecture, shown in Figure 3, provides an eBusiness solution for users, administrators, and developers.

At the center of this architecture is the iChain Proxy Server, which is based on an enhanced version of Novell's Internet Caching System. This component is the primary access point that controls user access to all network resources. It uses ICS's reverse proxy technology to accelerate system performance, as well as Novell's SSLizer technology to provide secure browser-to-proxy server communication.

A contemporary Web site with Novell iChain installed.

The iChain Proxy Server intercepts requests made from the browser (client) to the company's Web servers. It supports multi-homing, using a single public IP address to handle requests to multiple back-end Web servers. The Proxy Server also provides interfaces to iChain's authentication and authorization services.

The only requirement for the iChain Proxy Server is that is be ICS-configured hardware from a Novell-approved vendor (for a list of approved vendors, see http://www.novell.com/products/ics). The NDS eDirectory Server can be any hardware platform supported by eDirectory 8.5: NetWare 5.1, Windows NT, Solaris, or Linux.

The mail server could be a server running Novell GroupWise, Microsoft Exchange, a Linux-based mail service, and so on. Once the system is set up, a user can simply click on a Mail button on a Web page, and iChain would provide the user's ID and password to retrieve mail from any of these services.

During the access control process, iChain supports LDAP calls to third-party directory services, such as an Active Directory server with an SQL back-end application. This is a unique capability of iChain which is not available with any other solution.

Benefits of iChain

The "Novell iChain 1.5 Detailed View" document (which you can access on the Web at http://www.novell.com/products/ichain) lists six main benefits of the iChain architecture. Following is a quick summary of these benefits.

Secure Data with Access Control Lists

Access control lists (ACLs) are the foundation of directory-based security. An ACL can be associated with any object in the directory. The ACL contains a list of who has rights to do certain things to the object. For instance, a network administrator can define an ACL that allows only people from a certain department to view a particular object in an NDS tree. That definition can be further refined so that only some people within that department can make changes to the object. ACLs are impossible to bypass: if access rights are not in the list, access is not granted.

Protect Your Network with Authentication Technologies

To guard against unauthorized users, iChain support a number of authentication methods, including user identifiers (name, e-mail address, LDAP attributes), passwords, and X.509 digital certificates. iChain also supports multi-factor authentication, which combines authentication methods to produce an even higher level of security.

In addition, iChain's proxy services include the SSLizer, which offloads Secure Sockets Layer (SSL) encryption tasks from the Web server. Besides freeing the server from the processor-intensive task of encoding and decoding SSL protocols, the SSLizer also adds another layer of security between the Internet and your network. Before users authenticate themselves, iChain establishes an SSL session with the users' browsers so that passwords and other authentication credentials cannot be intercepted. An included certificate server lets you create and manage digital certificates of your own or import certificates from third parties.

Give Users the Convenience of Web Single Sign-On

An innovative service made possible by the iChain package is Web Single Sign-On. Thanks to this service, a user needs to log in only once to gain access to multiple applications and platforms. Single Sign-On is possible because iChain authenticates the user from a centralized NDS profile. When the user requests access to a specific server, iChain acts on the user's behalf by transparently submitting the username and password (or employee ID and password) to that server. The user sees no login requests, only the end result: access is either granted or denied.

Centralize Management and Administrative Duties

Web services often run on different platforms, and access is typically managed on a server-by-server basis. If servers are scattered across the country, management becomes expensive and impractical. iChain solves this problem by centralizing all administrative tasks. Changes can be made through ConsoleOne, a single utility that affects all of the servers involved, regardless of the platform any individual element of the network is running. Moreover, this utility can be run from any workstation on the network. Control is thus simplified without the costly upgrades and retrofits that would otherwise be needed to unify all the elements of the network.

Build Customer Loyalty with Digital Communities

One way to attract users is to offer a personalized Web experience, adapting the content of a Web site to the individual user. iChain enables this experience with digital communities. A digital community is a group of users whose membership is defined by rules. Rights and contents are customized for each community. An example would be a community called "Customers," whose members would be able to see a product catalog, whereas members of the "Preferred Customers" community would see special offers not available to members of any other community.

The Community object that iChain creates in eDirectory is a new, unique class of object. Membership in a conventional NDS group is determined manually; the network administrator must set up the ACL for the Group object to allow access for a particular user. Membership in an Community object, however, is governed by the rules established for that community.

Integrate Applications from Third-Party Vendors

The concept behind iChain is integration-bringing together all the elements from different vendors. To facilitate this integration, iChain supports Novell's DirXML, an Extensible Markup Language (XML) solution that synchronizes databases and directories from various applications and vendors.

The iChain package also supports Lightweight Directory Access Protocol (LDAP) and includes a number of application programming interfaces (APIs) that allow developers to customize applications as needed to ensure a smooth fit within your network.

iChain Benefits Example

To illustrate the benefits of the iChain architecture, imagine a health care provider site to which three key user groups need quite distinct access: the insured, medical suppliers, and doctors. Each group requires a high degree of security-not just for IT's benefit, but because of federal law. Rather than create three sites and maintain three separate directories, iChain allows the creation of one health care site with three kinds of access, tailored specifically for each group. The medical records server application could actually be on DB2 running on a mainframe, while the supplies and inventory database could be on SQL Server. Whatever the Web server or application platform, iChain can address each one in a secure framework.

Data Flow and Processes in iChain

Now that we have a basic understanding of the iChain architecture and benefits, let's follow the flow of data through the various processes within a typical iChain system. Throughout this discussion, we'll refer to the NetWare Loadable Module (NLM) components that are installed with iChain. These include:

  • PROXY.NLM, which accepts client requests and processes client interaction

  • AUTHCHK.NLM, which verifies authentication and maintains the client table

  • ACLCHECK.NLM, which handles client access privileges

  • OACINT.NLM, which responds to requests for object-level access control (OLAC) parameters

Initial User Authentication

User interaction with an iChain-enhanced Web site is deceptively simple. Instead of having to enter multiple URLs and undergo multiple logins, the user simply logs in once at the start of the session. Once that is done, content appears-some of which may be personalized for that user. As the user clicks on various buttons, the appropriate resources appear or open according to the user's access privileges.

While this interaction appears simple to the user, a considerable amount of activity occurs in the background to support this clean approach. The steps involved in the authentication process are illustrated in Figure 4 and explained in more detail below.

  1. The client browses to a URL, such as http://www.demosite.com, which resolves to the iChain Proxy Server's IP address. (The company's firewall provides further access control for client entry to this point.)

  2. The iChain PROXY.NLM accepts the request from the client.

  3. PROXY.NLM sends a request for the site's iChain authentication cookie stored on the client's workstation.

  4. If the cookie is present, the client sends it back to PROXY.NLM.

  5. PROXY.NLM performs a lookup in iChain's AUTHCHK.NLM table to verify that the client is an authenticated user.

  6. Note: The AUTHCHK authentication table is dynamically generated and stored in RAM cache. When the iChain server is first started, the table is blank. AUTHCHK adds to it as the iChain system is used.

  7. If the client is authenticated, the flow passes to ACLCHECK.NLM, which determines the client's access privileges: public (as a "Guest user" in NDS parlance) or restricted.

The authentication process between the iChain server and the client workstation.

Clients can authenticate to iChain using any of these authentication schemes:

  • Username and password over HTTPS (can be LDAP userid, e-mail address, or any LDAP field)

  • One-time passwords (within the same DNS domain)

  • X.509 certificates

For even higher levels of security, multi-factor authentication can be provided by combining the above methods. For example, a company may require a username and password as well as a certificate before granting access to a user.

Future integration of iChain with Novell Modular Authentication Services (NMAS) will provide additional forms of authentication such as SmartCards, tokens, and biometrics.

Variations on Authentication

Suppose that PROXY.NLM does not find an iChain cookie on the client workstation, or that the client is not authenticated. In these cases, the data flow proceeds as illustrated in Figure 5.

If the client isn't authenticated or has no iChain cookie, iChain checks the AUTHCHK access flag.

  1. PROXY.NLM looks in the AUTHCHK table for a flag called "Authenticated when accessing a restricted page."

  2. AUTHCHK.NLM checks this flag setting to see if it is ON or OFF. If the flag is OFF and the client is not authenticated, iChain establishes an SSL connection with the client.

  3. If the flag is ON, PROXY.NLM calls ACLCHECK.NLM to determine what access privileges the user has.

  4. If the user has public/guest access, no authentication is required and ACLCHECK responds with the access privileges of Guest (which are stored in NDS eDirectory).

  5. If ACLCHECK.NLM determines that this client has restricted access, it will check a local cache of access rules to determine this client's privileges.

At this point, PROXY.NLM verifies if the administrator has enabled authentication via certificate (mutual authentication). If the client verifies this certificate authentication, PROXY.NLM will update AUTHCHK.NLM's client table with this new client's entry. If the administrator has not enabled authentication via certificate, or if the certificate authentication fails, PROXY.NLM sends a login page to the client. This HTML login form requests the client to authenticate using an LDAP username and password.

Once the client successfully authenticates to PROXY.NLM, PROXY.NLM again updates AUTHCHK's table with the client's entry, which includes the following contents:

  • A new iChain cookie

  • An HTTP authorization header for the user

PROXY.NLM retrieves the cookie from AUTHCHK's table and sends it to the client's browser. It then closes the SSL connection with that client and redirects the user back to the HTTP port (80). At this point, the client will again perform the cookie verification outlined above. This time it should pass, since the appropriate cookie is now present.

Once the client workstation has been verified, ACLCHECK.NLM sends an LDAP query to NDS eDirectory to authenticate the userid. ACLCHECK.NLM retrieves any applicable ACL Rules objects for this user from eDirectory and verifies access. (ACL Rules objects are an extension to eDirectory added during the iChain install process.) It then returns this information to PROXY.NLM.

Web Page Retrieval

Now that the client's access privileges have been verified, the client can proceed to request Web pages. This process is illustrated in Figure 6, and the steps are explained in detail below.

  1. The client makes a Web page request, which is received by PROXY.NLM.

  2. PROXY.NLM will either determine to display the page based on the user's rights, or return an error that the user cannot open the page.

  3. If the privileges allow access, PROXY.NLM checks to see if the requested page is in cache memory. If so, it responds with the page.

  4. If the page isn't in the cache, it will need to be retrieved from the origin Web server. To do this, PROXY.NLM verifies if the user is authenticated with some level of restricted access or with guest access. If the user is authenticated with restricted access, PROXY.NLM retrieves the user's HTTP authorization header from AUTHCHK's table. If Guest, it will retrieve Guest's authorization header. (PROXY.NLM will attach this header to the Web page request to the origin Web server.)

  5. The Web page retrieval process varies if the page is in cache on the proxy or if it is one that has to be called from the origin Web server.

  6. PROXY.NLM asks ACLCHECK.NLM to see if the user's page request requires any object-level access control (OLAC) parameters. If it does, PROXY.NLM goes to the AUTHCHK table. If the table has the parameters, PROXY.NLM retrieves them and attaches them to the Web server request as part of the HTTP header.

OLAC Parameter Requests

The iChain Proxy Server can forward a user's login name and password in the Authentication section of the HTTP header. Any Web server using basic authentication can accept these credentials and authenticate the user. The use of object-level access control (OLAC) provides an option to use different login credentials. OLAC is a Java-based extensible framework used to send administrator-defined attributes to a Web server.

For example, in a health care provider scenario, OLAC parameters might be used to retrieve a health group number, a subscriber number, and a PIN number to be passed on to a Web server. This information can be retrieved from any LDAP directory or data source where there is an OLAC provider.

OLAC information is sent in the HTTP header as a sequence of parameters added to the URL query string. The parameters take the form of "parameter=value" pairs. For example, a request containing OLAC parameters could look like this:

www.demosite.com?var1=xxx&var2=yyy . . .

The process of checking for OLAC parameters is illustrated in Figure 7. The steps are explained following the figure.

PROXY NLM can retrieve OLAC information from eDirectory or from another data source.

  1. PROXY.NLM uses the process described above to determine whether the client requires OLAC parameters.

  2. If OLAC parameters are required, ACLCHECK.NLM requests them from AUTHCHK.NLM.

  3. AUTHCHK.NLM looks up the parameters in its table in memory.If the AUTHCHK table does not have the required parameters, PROXY.NLM calls OACINT.NLM to obtain them.

  4. OACINT.NLM uses an LDAP request to obtain the parameters from NDS eDirectory (or from a custom data source such as a Netscape directory, Active Directory, or any source supporting LDAP).

  5. Once OACINT.NLM retrieves the parameters, it passes them to AUTHCHK.NLM to cache them in its table for subsequent page requests. PROXY.NLM retrieves the parameters to insert them into the page request to the origin Web server.

If the request doesn't require any OLAC parameters, or if PROXY.NLM has already retrieved the parameters, PROXY.NLM sends the completed page request with the HTTP authorization header to the origin Web server for processing. The origin Web server receives the HTTP request and is responsible for parsing the header and using its own internal logic for handling the OLAC parameters in dynamic page creation. The Web server then responds to the iChain Proxy Server's request by returning the appropriately generated page. At this point, the iChain Proxy Server delivers the page to the client.

iChain Digital Communities

As mentioned earlier, iChain provides the option to create digital communities via the Community object in eDirectory. Communities allow the Web site designer to create an automated way to configure portals, deliver pages, or extract other pertinent information from the Web server. In some ways they act like user groups in NetWare, only in a Web context. In fact, iChain communities take advantage of the NDS eDirectory Group object's capabilities and inheritance.

Communities are implemented using standards-based Java servlet code to enable such things as user self-registration, profile editing, and community portal customization.

Figure 8 shows how the processes and data flow described above change when iChain community servlets are included on the server.

Communities in iChain allow for customized Web delivery for a group of users.

  1. PROXY.NLM sends a request to the Web server for a page.

  2. When the Web server receives the page request, these servlets decode the username from the incoming page request. They then request the user's community membership information from eDirectory.

  3. Based on this membership information, the servlets locate and process the appropriate Web page template. The servlets then determine if any iChain directives exist in the template. The iChain directives do one of two things: look up community content (such as a list of updates for a given community) or perform an action on the user's behalf (such as deleting a document.)

  4. The community servlets take the results of either or both of these operations and format them into the Web page template. Then they send this generated page back to the iChain Proxy Server for delivery to the client.

Note: Because these servlets require NDAP support, they currently run only on NetWare- and NT-based Web servers, not on UNIX-based Web servers. The NT boxes will need to have the Novell Client loaded to provide this support.

Managing the iChain System

One of the most compelling advantages of the iChain system is its manageability. This section briefly discusses some of the management features of iChain.

Simplified Access Control

With iChain, configuring access to multiple Web servers and to DBMS or other controlled-access resources is greatly simplified. This is handled through the browser-based ICS console, which is used to configure access control parameters, authentication profiles, the LDAP Server, and other aspects of the iChain Proxy Server such as reverse proxy acceleration and SSLizer functions. With iChain's user self-registration option, users themselves can further reduce the administrative burden as well.

Updates are easily handled in the same way. Leveraging the inheritance capability of NDS eDirectory, administrators can authorize B2B partners to act as sub-administrators for their specific users as those users change or require different access privileges.

Management Tools

Currently, management of iChain objects is done through Novell's ConsoleOne utility. Since iChain extends the NDS eDirectory schema, the iChain install process includes the appropriate ConsoleOne snap-ins to support the additional iChain objects and attributes. In the future, management will include browser-based tools as well to allow the Web support staff to maintain iChain with a conventional browser interface.

By using DirXML, the iChain management tool can synchronize information between the various Web services that a site may have, regardless of which DBMS system they are based upon. This allows Web servers and back-end applications that maintain their own security directories to be updated within the iChain environment. Administrators do not have to maintain those directories independently of iChain.

Note: The iChain platform supports either single or multiple NDS eDirectory trees. For sites with separate Web and internal IT management teams, it is advisable to have separate trees-one for corporate users and one for iChain users. This design consideration allows the Web staff to maintain access to their resources independent of the internal staff.

Conclusion

With the release of iChain, Novell provides administrators and developers with unique tools they need to create an effective B2B site. The platform significantly reduces the hassles associated with user password and access control management. Users need only authenticate once to gain access to all their relevant information. This further heightens security by reducing the number of IDs and passwords a user must track.

As the user information repository for iChain, NDS eDirectory provides the scalability to handle a site's growth from hundreds to tens-of-thousands of users or more. Using NDS eDirectory, iChain unifies contemporary heterogeneous network environments with a single point of administration. By leveraging the ICS platform, iChain greatly heightens security with a reverse proxy server. As users have no direct access to the site's Web servers, they cannot interfere with them. As a bonus, ICS also provides a performance boost as it retrieves cached pages internally without calling on the Web servers.

In the near future, Novell will release an upgrade pack for existing ICS users. This pack will install the appropriate iChain NLMs to the ICS server from a workstation. The install will also add the appropriate plug-ins to the ICS management tool to handle the new iChain services.

As the iChain platform allows for considerable customization, Novell Consulting provides the primary access to using iChain. In fact, Novell iChain is currently available only through Novell Consulting or from Novell Authorized Channel Partners. These are listed at http://www.novell.com/products/ichain/partners. All iChain orders made through a Novell Authorized Channel Partner must include the name of a Novell Authorized Consulting Services Integrator (CSI) partner or Novell Consulting Services representative.For further information on iChain, see the product Web site at:

http://www.novell.com/products/ichain

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates