Putting Liberty to work

Sun Microsystems has 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 authentication 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 authentication 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 it doesn’t require user authentication information to be stored in a central repository.

Thus, a user could have basic username and password information stored on one server while having credit card information stored on another, yet still allow another application within the authentication domain to access both sets of data when needed. This means no single entity will have control over all user information, and no impediments to businesses retaining the information they need for effective customer relationship management.

Sun ONE Identity Server is not a stand-alone product, but is comprised of 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 boundaries, and will include a hardware configuration equivalent to two Sun Fire 280R UltraSPARC III servers and a 72GB Sun StorEdge D2 storage array. Software will be preconfigured and include the pieces listed above as well as Solaris 8 or 9.

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 which authentication mechanisms you plan to employ.

The logging service is also what you’d expect, writing information to individual log files or to a log database for central administration. This data is then used by the Identity Server as well as by administrators via the Identity Server administration console. Session services are basically engine services designed to manage sessions and validity times; this data is used to manage SSO (Single Sign-On) tokens.

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. And while we didn’t get a chance to look at it, developers will be especially interested in the SAML (Security Assertion Markup Language) service, which is used to define the framework for communication between authentication services.

Manoeuvring within Identity Server 6.0 is surprisingly straightforward. Most tasks are handled by an administration console broken down into four tabs: Identity Management, Service Configurations, Current Sessions, and Federated Management.

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. It’s important to note, however, that actual customers of Identity Server 6.0 won’t encounter such problems because Sun is selling this product preconfigured and with a set number of on-site consulting hours to work out the kinks of the sort we encountered.

We also used Identity Server’s policy agents to implement authentication rules within Sun ONE Directory Server, relegating access based on IP address and usage time. We set up our policy on a per-domain and per-user basis, but you can also configure such rules based on roles, groups, or applications. However, we could only manage role- or group-based policies if the roles and groups were configured within Sun ONE Directory Server. Roles defined under our NDS tree had trouble accepting Sun ONE policy management. But again, this is a hurdle most customers will iron out during a Sun-supervised implementation.

Overall, Sun ONE Identity Server 6.0 was truly impressive, both in its feature-set as well as the breadth of its effectiveness across corporate technology boundaries. Although proper implementation will take months in most cases, the proper hooks exist to layer Identity Server onto most heterogeneous enterprise networks.

The price tag makes as big an impression as the technology, but the ability to centralise large numbers of corporate identities as well as implement a new level of service to e-commerce customers seems well worth the investment. w

Join the newsletter!

Or
Error: Please check your email address.

More about ApacheCompaqLiberty AllianceNDSNovellSun Microsystems

Show Comments