Ticket mechanism for distributed security

Enterprise systems dedicated to serving a large number of users typically require some form of distributed security. An enterprise system may require distributed security, for instance, to support features such as load balancing, stateless environments, or transfer of trust (the ability to allow another component to act on behalf of the user).

Crystal Enterprise addresses distributed security by implementing a ticket mechanism (one that is similar to the Kerberos ticket mechanism). The APS grants tickets that authorize components to perform actions on behalf of a particular user. In Crystal Enterprise, the ticket is referred to as the logon token.

This logon token is most commonly used over the Web. When a user is first authenticated by Crystal Enterprise, he or she receives a logon token from the APS. The user's web browser caches this logon token. When the user makes a new request, other Crystal Enterprise components can read the logon token from the user's web browser.

This use of the logon token provides the distributed security that is required for load balancing to be implemented in conjunction with effective fault-protection. For instance, suppose that you are running one web server and two Web Component Servers, and each of the three components is running on a separate machine. The Web Connector is installed on the web server, so as to direct all Crystal Enterprise requests to the Web Component Servers. By default, the Web Connector balances all Crystal Enterprise traffic across the two Web Component Servers: when a user first connects to Crystal Enterprise, the Web Connector passes the logon request to whichever Web Component Server has the most resources available. If the log on is successful, the user is granted a logon token and an active identity on the system.

The user's active identity is stored as a session variable on the Web Component Server that processed the request; consequently, the user's active identity is not immediately accessible by the other Web Component Server. For this reason, the Web Connector uses the user's logon token to route all of the user's requests to the Web Component Server that is storing the user's session. By doing so, the Web Connector maintains security while providing optimal performance: the user's identity is verified, but the system does not have to repeatedly prompt the user for his or her credentials; in addition, the user is prevented from unnecessarily consuming resources on both Web Component Servers.

If the Web Component Server that is storing the user's active session is taken offline, the logon token again serves a critical purpose. If one Web Component Server ceases to respond to a user's requests, ePortfolio and the CMC are designed such that the Web Connector is instructed to redirect the request to the remaining Web Component Server. The client application logs the user on with the valid logon token, and the remaining Web Component Server is able to authenticate the user and create a new, active session without prompting the user for his or her credentials. The remaining Web Component Server can then authorize and carry out the user's request. In this way, the logon token enables the system's load-balancing and fault-tolerance mechanisms to maintain a secure environment without affecting the user's experience.

In this scenario, when the original Web Component Server is brought back online, the Web Connector automatically resumes its load-balancing responsibilities by routing each subsequent request to the least used Web Component Server.

Note:    Crystal Enterprise supports implementations of the Secure Sockets Layer (SSL) protocol that rely upon affinity or "sticky connections." However, in these scenarios, the Web Connector may be prevented from automatically load balancing across WCS machines.