Menu
Putting Liberty to good use

Putting Liberty to good use

Online consumers and corporate end users burdened with dozens of online identities, as well as the IT administrators who must manage all of their passwords and access privileges on the back end, may soon see relief in the form of e-commerce-oriented identity management systems.

Sun Microsystems recently released Sun ONE Identity Server 6.0, a system that manages not only the identity and authentication mechanism of users on large, disparate enterprise networks, but also addresses end user log-in headaches via federated identity management based on a specification released by the Liberty Alliance Project last July.

This means that Identity Server can be configured in two basic ways: first as an authentic­ation service for use on large, heterogeneous corporate networks, and second as a Liberty-enabled federation management service.

In corporate mode, users or applications attempting to access resources anywhere on the network must first pass through Identity Server’s Authentication Service, typically via a log-in Web page, although this can be routed towards a custom GUI interface via additional programming tools.

Once the user has provided the required information, the Authentication Service either grants or denies access. Although this sounds similar to what we already have, Identity Server can manage access across domains and operating systems, as well as many existing authentication systems and directory services.

The Liberty-enabled configuration is intended to allow Web users to sign in to a Web site or Internet resource that is part of a Liberty authentic­ation domain — basically a conglomerate of resources operating in a trusted environment, all managed by the Liberty Alliance’s federated authentication service. Thereafter, that user can roam to any Web site within that authentication domain and access resources without having to be re-authenticated.

What’s nice about the Liberty implementation is that it’s cross-platform via Java and XML, and doesn’t require user authentication information to be stored in a central repository.

Sun ONE Identity Server is not a standalone product. It comprises several Sun ONE agents, service technologies, and servers. Digging into an Identity Server box, you’ll find that you’ve purchased a number of Sun ONE technologies, including Sun ONE Directory Server 5.1, Identity Server Policy and Management Service, the Identity Server Console, Identity Server Schema, the Cross-Domain Single Sign-On component, and Common Domain Services.

Although you can download the base software in demo mode, as we did, actual customers will work with Sun on both a hardware and software basis.

Sources say Sun will most likely sell the software in two turnkey configurations, Enterprise Edition and Internet Edition. The Enterprise Edition is intended to manage up to 50,000 user identities within firewall bound­aries and will include a hardware configuration equivalent to two Sun Fire 280R UltraSPARC III servers and a 72GB Sun StorEdge D2 storage array.

The Internet Edition is designed for a heavier load of up to 5 million identities and to operate outside a firewall. This configuration will be similar to the Enterprise Edition, but with a meatier server platform, approximating two more Sun Fire 280R UltraSPARC III servers and a StorEdge containing 150GB of storage or more.

We couldn’t get Sun to send us a million dollars worth of preconfigured hardware, so we had to install our version of Sun ONE Identity Server 6.0 on a Sun Ultra 10 (UltraSPARC IIi 300MHz) with 512MB of RAM and dual Ultra SCSI 18.3GB hard disks running Solaris 9 with Apache’s 32-bit Web server installed.

We installed Sun ONE Directory Server on a Netra T1405 running four UltraSPARC II 440MHz CPUs with 1GB of RAM and dual 18GB SCSI hard disks. Needless to say, though all our components worked just fine — your performance is likely to vary dramatically.

Because we had no Liberty authentication domain to access, we chose to set up Identity Server in its enterprise mode. That meant connecting our Sun server to a workstation running Solaris 8, a Compaq Proliant 1600 running Windows NT Server 4.0 in a separate domain, and a Compaq Proliant 800 running Novell Netware 5, also running in its own domain and configured with an NDS tree. It also meant paying attention to four core Identity Server services — authentication, logging, single sign-on, and session services — as well as whether to build a directory service from scratch or configure Identity Server against an existing Sun ONE Directory Server installation.

Identity Server’s authentication service is just what you’d expect, aimed at verifying the identity of users trying to access network resources.

These services use a number of pluggable modules, depending on your network configuration and the authentication mechanisms you plan to employ.

It gets interesting during implementation with SSO. This service uses tokens to move authentication information between trusted applications.

You’ll find Sun has provided Java validation APIs, agents to allow authentication with a variety of application server platforms, and several identity management services.

All these default services are defined via XML and require varying degrees of configuration during implementation. We chose to enable administration, core, LDAP, membership, Unix, and NT services, while ignoring anonymous, certificate-based, SafeWord, and RADIUS services.

We also paid special attention to the policy configuration, client detection, platform, naming, and logging services.

Our testing stumbled in places, but was quite successful on the whole. Though we were able to authenticate users from the Windows NT domain with little trouble, performing the same operation with the NDS-registered users via Sun ONE’s LDAP service was only intermittently successful, though whether this was our Sun implementation or our Novell configuration was never fully determined.


Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments