Single Sign-On

Give customers access to all their information
through a single portal website

A stated business objective for many organizations is to construct a capability for a user to access all of their accounts / information through a single login.

This paper relates Customer experiences with architectures in which a login server controls access to relevant applications and websites. It begins with a case study, which sets the stage for the general discussion that follows. Figure 1. illustrates an example of a login server architecture.

Figure 1. High-level architecture for single sign-on capability

Case study - A growing Internet service provider:

HP implemented a login server with single sign-on capability for a major U.S. Internet service provider (ISP) facing rapid growth. This ISP's. subscribers were spending more time online, resulting in higher revenues for subscriptions, advertising, and product sales. In response to market growth, the ISP defined strong growth requirements of its infrastructure as follows:

• Expand servers according to the business demand without outages for forklift upgrades.
• Expand databases with the business, without expensive replications.
• Let servers expand applications transparently without expensive reconfigurations.
• Expand without allowing planned outages for growing capacity.

In addition, with tens of millions of subscribers, high rates of peak concurrent use, and millions of sessions per day, the ISP was extremely sensitive to server performance and manageability requirements for key customer-facing applications. Given these growth requirements, the ISP adopted an architecture based on the HP NonStop™ Himalaya™server platform as the basis for its login service, following a short proof-of-concept test. The decision was based on several unique advantages of this platform, including

• The highest level of system and application availability in the industry
• The highest level of system scalability to cater to the increased transaction volumes with future growth at the least possible cost and with the least system disruption
• A unique single system image (SSI) capability

By utilizing the technology of this platform for its critical application, the ISP was able to provide a fully fault-tolerant infrastructure for access to Internet-based services. This ensured the highest possible customer service levels. The SSI capability enabled the organization to physically distribute system components while operating the entire network as a single logical application.

Login service architecture

Figure 2 presents a high-level view of the architecture for a general login service. The service includes both authorization and billing components, both of which must be executed reliably to enable user access to other applications. The architecture uses a lightweight login service that relies on the billing server being fault-tolerant to avoid complex logic at login. The login service is similar to the stand-in processor of an automated teller machine: It needs a read-only authorization data file, which must be streamlined for high-volume use.

The authorization file is updated on a regular basis, with an exception method available for interim crisis updates. The login server also generates alerts programmatically via SNMTP (or JMAIL, for example) to notify operators of unusual circumstances.

The login service maintains the customer state in the billing database. Therefore, this database must be transactionally oriented and available on a 24 x 7 basis. The use of three copies of the database provides extra security for disaster recovery and for offline accounting and reporting functions. The primary database is the only one transactionally protected. The others are near real-time copies of the database, trickle fed from the primary server.

Login server requirements

A single sign-on login server requires a few conditions, including

• Availability
• Scalability
• Manageability

For single sign-on to be successful, the service must be available continuously. Even planned downtime is unacceptable. Given the global nature of many banks, there is no good time to take the service offline.

If the service is successful, then the number of hits is likely to increase by orders of magnitude, as customers are enrolled and become comfortable with the facility. The service must be capable of adding capacity in a planned fashion without requiring outages or serious reprogramming. To limit growth in the cost of operations as the scale and complexity of the service increases, the entire service must be manageable and auditable as a single, stable configuration.

Components of a login server

The major components of a login server for single sign-on include

• Web server
• Java applet and servlet support
• Security authorization application
• Security audit logging capability
• Validation repository (database)

Figure 3 illustrates a server with these components. The architecture could also integrate Wireless Application Protocol (WAP) and the tracking of customer usage data for customer relationship management (CRM) purposes. The login server validates the customer login using an applet for the secure dialogue. Once validated, the customer is presented with a menu of available choices (using a Java servlet application running on the login server). Using typical Web technologies, the server redirects the customer to the already constructed website chosen with the addition of a security authorization token that identifies the user to the website application. In addition to providing the authorization token and directing the user traffic, the menu servlet application maintains a security audit log for internal use.

HP solutions

HP offers three server families as potential solutions for a login server:

• NonStop Himalaya servers
• HP Tru64™ UNIX on AlphaServer™ system clusters
• ProLiant™servers running the Microsoft Windows NT Server or Windows 2000 operating systems

HP also offers all of the components needed to construct a login server, using any of these server families or a combination of them. Each server has its unique strengths.

NonStop Himalaya servers offer the highest availability at the application and database level, including database and application management, which position them for high-volume front-end services. As discussed, a major U.S. ISP uses this family of servers as its front-end login platform with a custom application.

Tru64 UNIX on AlphaServer system clusters provide high availability with the highest performance characteristics, leveraging the RISC-based HP Alpha™microprocessor, while supporting a wide range of industry-standard middleware and applications. Many banks already use AlphaServer systems with Oracle databases for fast response applications.

ProLiant servers offer the lowest entry cost with a vast array of tools and components available. Many application service providers (ASPs) have adopted ProLiant servers as their Web-facing front-end systems.

Solution components on NonStop Himalaya servers

The NonStop Himalaya platform and components fully meet the requirements of a login server. It has a long and venerable track record in applications that have the same availability, scalability, and manageability requirements. Telecommunications companies, ISPs, stock exchanges, and major money center banks, for example, share such requirements. Databases on the NonStop Himalaya system support a mixed workload environment with predictable service levels. That is, they consistently sustain transactional inserts, batch extracts, online transaction processing, and massively parallel queries against the same tables concurrently without degrading service levels.

Single sign-on solutions built with NonStop Himalaya servers include the following components:

• HP iTP WebServer software
• NonStop Enterprise Application Server software (for Enterprise JavaBeans capability)
• eBOSS security application software
• Enscribe logging database and validation repository
• Scalable Security Services, the first server version of Entrust File and Session toolkits, which includes HP MultiPrime™ technology for key management

Solution components for Tru64 UNIX on AlphaServer systems

Tru64 UNIX on AlphaServer systems support the requirements of a login server by virtue of the single file system clustering approach. This allows individual servers to be down without bringing down the entire cluster. In addition, the Java Virtual Machine (JVM)  for the Tru64 UNIX operating system has been benchmarked as the fastest performer in the industry.

Reliable Transaction Router (RTR) is fault-tolerant transactional messaging middleware used to implement large, distributed applications. The Tru64 UNIX operating system with RTR has often been implemented in banking for high availability.

Single sign-on solutions built with Tru64 UNIX on AlphaServer systems include the following components:

• Netscape Web server and Lightweight Directory Access Protocol (LDAP) validation repository
• JVM
• Oracle relational database
• RTR application integration middleware

Solution components on ProLiant servers

ProLiant servers provide a substantial measure of support for the requirements of login servers, especially with a Distributed Internet Server Architecture (DISA) approach. In DISA, multiple Web servers are used in a round-robin fashion to achieve high availability and scalability. Further separating functional layers in a DISA array offers additional modularity and scalability. The HP Insight Manager™XE application provides a basis for managing the complex DISA server array in a cost-effective fashion.

A single sign-on solution built with ProLiant servers includes the following components:

• Microsoft Internet Information Server (IIS) and BizTalk integration middleware
• TIBCO, NEON, and Brokat application integration middleware
• Oracle or Microsoft SQL relational database
• BEA WebLogic Server

eBOSS Software

eBOSS Software provides access control, security management, and auditing of applications in an open architecture. This heterogeneous access control product is the extension of the BOSS security product for the NonStop Himalaya platform. Figure 4 depicts the architecture for a portal constructed with eBOSS on NonStop Himalaya servers.

eBOSS allows access from a Web browser to a variety of target systems and applications that could reside on platforms such as mainframes or systems running Windows 2000,Windows NT, UNIX, or Linux operating systems. eBOSS still uses the NonStop Himalaya platform as the secure, fault-tolerant platform “glue ”that holds all of this open architecture together. Product highlights include:

• Context checking (regardless of application)
• Ability of the BOSS Manager to allow or disallow access to any application on the BOSS Menu to a set of users
• Ability to completely deny users ’ability to visit a website outside of what they are allowed via the eBOSS Menu
• Complete audit trails
• Secure access to applications that run on Windows 2000, Windows NT, Sun, Linux, and UNIX (including Tru64 UNIX) operating systems; the Internet (HTTP applications); and website authorizations
• Secure access to applications running on a NonStop Himalaya server from a user’s Web browser by way of the Internet

NonStop Data Transformation Engine software

NonStop Data Transformation Engine (DTE) software provides a high-performance and cost-effective alternative to writing or generating programs that translate diverse data models used by different applications into a common data format. Typically a component of the HP Zero Latency Enterprise (ZLE) framework, this product can also be employed in a single sign-on architecture on the NonStop Himalaya platform. It can be useful in providing login integration to shield an application from the user or in defining a new application that integrates services from diverse applications behind the login server.

NonStop DTE software is based on Mercator technology, which is recognized in the industry as being best of breed in the category of data transformation products. Mercator worked closely with HP to customize the Mercator Enterprise Broker software and deliver powerful data transformation technology across a heterogeneous business environment. NonStop DTE software consists of Design Studio, Platform API, adapters, and servers. Figure 5 shows how these component groups are interrelated.

NonStop DTE software is a powerful data integration tool that has the ability to grasp the structure, content, and semantics of any application data, as well as completely transform the data, without the need for programming. It is a complete data integration offering, including automatic data transformation tools and more than 100 predefined rules for dynamically acting on the content of data input and output. NonStop DTE software can be deployed as either a NonStop Tuxedo server module or a NonStop CORBA object. The NonStop Himalaya system cluster provides scalability, high availability, and load balancing. This ensures that real-time translation of data does not become a bottleneck in online, integrated application environments.

NonStop DTE software consists of mapping tools and repositories used to create data integration maps, along with the actual engine, which performs the transformation, taking maps as input. The development process is easy and includes three steps.

1. The first step is to create transformation maps by associating input data with a type tree.
2. The second step is to map input data to output data. Optional input data processing (for example, validation rules) can be specified. Rules can be combined and nested in ways that provide robust retry, restart, and recovery capabilities when bad data is encountered.
3. The third step is executing integration maps. During this step, the engine dynamically retrieves the map for incoming data, performs the transformation, and sends the translated data to the receiving applications.

A map object can represent either a simple transformation (common to many applications) or a full mapping solution. With transformation rules, you can go beyond simple reformatting and construct an entirely new business object. You can also create rules to route newly formed business objects to appropriate targets based on the data content. When dealing with complex objects, you can develop rules to filter, scrub, calculate, validate, parse, substitute, expand, change character set, or otherwise convert data from multiple input to multiple output.  You can compute data, look up something in a database, sort, extract, merge, or use any of dozens of predefined functions to create output.

You can also map an output to another output. For example, you can map an output that was generated at the top of an output, to the bottom of an output, supporting the need to summarize, tally, or validate what has been created. You can also map an output that was generated in one output, to another output. For example, you can generate a message as one output and archive it as another output.

Multiple input sources and output targets can be used in a single map to provide any-to-any mapping in terms of content. Support is designed for any-to-many, many-to-any, and many-to-many data sources and targets.

The role of the ZLE framework in single login solutions

In addition to the architecture described, HP’s ZLE framework may also leverage the single login solution by enhancing and extending legacy systems and processes without re- engineering to maintain a virtual company structure while providing a real-time unified customer view. This view may be extended beyond existing systems and processes to address new business opportunities as well. For example, in the initial phase of an ongoing project, one HP client implemented a ZLE framework to integrate existing point solutions that address 22 distinct, critical data sources to provide a single real-time view across all customer touchpoints.

The single login solution could be augmented by the addition of application integration adapters to capture and maintain bankwide transaction data in high- performance operational data stores (ODSs). The ZLE framework is noninvasive. Existing applications and systems continue, with the framework providing a parallel and continually available information source that is up-to-date, with all customer events from all customer touchpoints. Applications continue to process work as usual while a copy of the transaction or event would be captured in real time and updated to the ODS.