iChain builds trust

FOR BUSINESS relationships to work, the parties involved must trust one another. They don’t have to be allies; competitors do business with one another all the time. But regardless of how cordial or tense the relationship may be, trust is all-important.

As more businesses use the Web to deliver services, manage content, and provide a public face, and as the services being delivered increase in sophistication, it becomes clear that effective Web authentication is crucial to establishing and maintaining trust between companies.

Too often, Web authentication systems are maintained separately from an enterprise’s main authentication scheme. This is not a problem with a user base in the hundreds, or perhaps the low thousands, but achievement of the possible economies of scale rarely happens with such a small population. Scaling to larger numbers requires a robust and proven user repository, however, and preferably one that operates in a variety of server environments.

Novell is touting its eDirectory directory service (a.k.a. NDS or Novell Directory Services) as being particularly well-suited to the role of user repository, and we’re inclined to agree, given the relatively large number of platforms it supports. But that’s not enough to do the job of authentication in a b-to-b or a b-to-c Web services environment. This is where iChain 2.0, Novell’s authentication product for portals, Web applications, and Web-based content steps into the picture, with its newly added support for XML-based single sign-on.

One of iChain’s most interesting features is its proxy-accelerator architecture, which is built around the Novell Internet Caching Server. The proxy architecture adds an additional security layer to a corporate network. The extra security results from the proxy server’s role as the public side of a corporate Web site; to penetrate the corporate Web server, an attacker must first compromise the proxy server.

On top of that, iChain’s use of an eDirectory-based authentication server makes user management a breeze, especially for shops that have used NetWare for years and that have staff who are familiar with the care and feeding of NDS.

Generally, iChain will use a separate NDS tree from the main corporate tree; these can be synchronized between themselves using native NDS tools or with other databases and directories using Novell’s DirXML product. Remember that NDS servers can present themselves to applications that use LDAP as if they were LDAP Version 3 servers, so applications don’t have to be written — or rewritten — for use with iChain.

iChain 2.0 features improved performance and scalability; iChain servers can now be linked together to provide an effective load-balancing environment that potentially supports millions of authentication requests, according to Novell. Support is also included via NMAS (Novell Modular Authentication Services) for token-based authentication, which joins certificates, smart cards, and the ubiquitous user ID and password method.

XML junkies will really appreciate the new XML Form Fill feature. This allows just about any Web-based application to support single sign-on without any programming changes or cumbersome plug-ins. There are exceptions, of course: For example, it doesn’t support list boxes, so a log-in page that uses a drop-down list won’t be accessible with XML Form Fill.

Although the new management wizards can make iChain’s installation a matter of only a couple of hours, we managed to stretch the installation time much longer, mostly by not exactly following directions, if we’re to be honest. For example, we’ve become too used to assuming that our browser will always supply the “http://” prefix to our URLs where appropriate, but we found that the management URL won’t work without it. We also wish that the list of supported hardware configurations included a broader selection of network interfaces. Currently, only a few Intel NICs (network interface cards) are listed as tested and verified, although we were able to obtain acceptable results using 3Com cards.

Having addressed our unique installation issues, we found it easy to configure our proxy server’s network connections via our Web browser and to install the iChain authentication server on a NetWare 6 server to host the iChain directory tree. The tree, like any other NDS tree, is managed through ConsoleOne, a simple but powerful tool for user and group management. Now in Version 1.3, ConsoleOne offers noticeable performance improvements over previous releases.

Unfortunately, the release notes document a number of issues with browser support and the proxy server itself. Some of these are fairly trivial, but other browser issues requiring repeated page loads or window resizing strike us as unworthy of a final release.

We can understand why there might be difficulties with older or the very newest browsers, but we really have to ask what problems exist with the Java support in Netscape browsers that aren’t present in Internet Explorer and why that makes a difference for managing the proxy server.

Although it appears to us that iChain 2.0 still needs some fit-and-finish work, the basic concept of mating a robust directory service and a solid acceleration and proxy server is sound and worthy of serious consideration.

We expect that many of the issues that affect the proxy server and iChain’s browser support — both from a management and an end-user perspective — will be fixed in future releases, although no public time frame for iChain’s future is available. Until the browser issues in particular are addressed, we don’t see iChain being the product to manage mass b-to-c relationships because of the wide variety of browsers likely to be used in a consumer environment.

In corporate situations, it’s much easier to ensure that a single standard browser is used, and therefore we can advise companies developing b-to-b or b-to-c services to consider iChain for authentication. After all, even trust is an imperfect quality.