SSO: Keepin’ IT Real
While new technologies are making enterprise single sign-on projects feasible today, there are both “gotchas” and important planning considerations that, if skipped, can kill an SSO project in its infancy. For one, legacy system integration is the largest single concern to any SSO project. Even software that’s relatively modern by today’s standards often contains proprietary logon mechanisms.

This only gets more inflexible the older the legacy package under consideration. While identity management platforms and toolkits often promise ‘customization capabilities’ that are able to deal with the legacy tools, IT administrators often don’t examine the necessary steps – or at least don’t examine them closely enough. Often these involve working not just with custom code, but also with code specific to a certain identity management product or technology platform. That means specialized consulting, which can drive implementation costs into the stratosphere if administrators aren’t careful.

Properly costing an SSO initiative is both critical and complicated. General guidelines would include:

• A thorough investigation into all SSO endpoints required
• Full understanding of all the technologies and customizations required for each endpoint
• No short shrift given to hosted and Web-only applications
• A full accounting not just of new infrastructure requirements, but also of ancillary charges such as administrator training

While that does paint a pricey picture, an SSO proposal can have several mitigating cost factors to tip the scales the other way:

• Reduced help-desk costs
• Reduced security emergency response costs
• Reduced user training
• Even reduced administrative training in some areas

The more thorough the planning, the more easily these pro/con budgetary questions will be answered. The important thing to remember is to be completely realistic when it comes to technology expectations. For example, SSO may provide a single point of entry for users, but that hardly means it will provide a single point of management for IT administrators. This is especially true when it comes to the burgeoning world of hosted and software-as-a-service (SaaS) applications.

Authenticating the Web
SSO is certainly feasible even for applications whose servers aren’t in the enterprise data center and are being administered by a separate organization. The principles sound fairly simple: an HTTP authentication redirect to a central and redundant authentication server, another HTTP redirect to the actual application once authentication is successful, and a mechanism for propagating authentication credentials (cookies, tokens, etc.).

There are several proprietary and open standard platforms aimed at managing this complex process. To service our customers engaged in SSO implementations, Unisys has thrown its weight behind the proposed SSO specification from the Open Solutions Alliance (OSA), which is centered largely on Central Authentication Service (CAS).

The OSA has defined an attractively flexible framework based on open source and hopes to use it to gel some level of standardization onto the enterprise SSO landscape. The OSA is a vendor-neutral consortium of companies with the goal of driving the adoption of comprehensive open solutions, and SSO is at the top of its project development list.

Although most think of single sign-on as simply authentication, the Alliance plans to add much more than that. The OSA’s SSO framework project is to provide login and logout interfaces along with both user credential and token-based authentication that provide users with the capability to launch applications without concern for location. This framework will most likely be based on three open source applications: Acegi (a security technology based on the Java/J2EE Spring framework), LAM (Lightweight Authentication Module), and CAS.

CAS is an open source central authentication service originally built by and for the higher education community. It is used by hundreds of open source applications including uPortal, Sakai, TikiWiki, Mule, and Moodle through community-supported CAS client libraries. For the OSA framework, CAS will provide the login page and authentication integration with LDAP or Active Directory, as well as provide the capability to issue tickets per logged-in user and then validate the ticket during the launch of the application.

It’s this ticket-based mechanism that makes CAS so potentially attractive for wide enterprise deployment. Because the use of opaque authentication tickets means that actual passwords need never be transmitted to application servers, CAS is essentially an n-tier SSO platform out of the box. That’s a huge deployment advantage to any enterprise. Certainly, there’s a software development cost, but because CAS is based on standard Java libraries, there is no need to contract high-cost specialist programming talent. This helps keep deployment costs under control.

Java orientation also means easy integration with Acegi and its Java Spring Framework-based roots. Using Acegi, SSO deployment gets an extra boost of ease, because the framework makes it relatively simple to design application-specific containers, such as those for Tomcat and Apache.

For Web applications even further out in cyberspace, LAM’s language-neutral API will allow SSO across diverse platforms, including ultra-new Perl or PHP Web applications all the way down to yesterday’s C++ client/server and Cobol behemoths. LAM will allow Acegi-like capabilities without requiring the use of Spring in an application. With all three standards implemented in the OSA’s specification, an SSO server could achieve back-end or forward-end integration with practically any authentication database currently in use, including Active Directory, LDAP, NIS, X509, even NT flat files and more. It’s an exciting project that has great potential for any enterprise engaged in software portfolio modernization.

Unisys and other organizations have used the OSA SSO model and technologies to achieve some impressive SSO results. That includes implementations across a variety of applications, networks, and back-end data resources from a common landing page with consistent user experience no matter what application type or access is required. It also includes real-time synchronization of data in multi-vendor application scenarios using a simple communication mechanism that can be implemented across a wide variety of platforms.

Limits But No Need to Wait
There are, however, limitations including several technology hurdles still to overcome. The framework must be extended to cover not just authentication, but access provisioning as well. Fault-tolerance and load-balancing measures for heavy traffic scenarios must be defined and there’s even a need for a single sign-off mechanism for clean user exits.

But this landscape will change rapidly because the community behind the framework is growing to encompass integrators, software providers and other organizations, including Unisys, with the experience and expertise to make this framework a reality for enterprise open source. Plus, the nature of the framework is one that allows for early implementation as long as enterprises make a concerted effort to stick with open standards.

For enterprises looking to engage in SSO efforts within the next year, adopting the OSA’s framework process can be a great step in IT infrastructure integration as they transition to a more fully standards-based interoperable environment. Additional information can be found at http://www.opensolutionsalliance.org.