Single Sign-On Application Architecture and Design

Single Sign-on Application Architecture and Design

The subject matter of this paper is the integration of single sign-on based web architecture in place of the current design that provides multiple sites for company employees. Currently, employees wishing to access company related information are required to access approximately eight different websites and maintain records for different user names and passwords for each site. This paper will outline the design specifics that will be necessary for full integration and user functionality of the new web-based portal.

One of the initial design considerations when looking at this project was the overall network architecture that the new layout would require. Currently, users have the option to access seven of websites over a regular internet connection. The preferred browser that is used by users is Microsoft Internet Explorer. Users simply enter in the web URL and provide the required username and password when prompted. The other website is accessed via corporate VPN over a secured (https) internet connection. As with the other sites, the employees will be prompted for a username and password and then are granted access to the corporate intranet.

Since all facilities have active internet connections, the overall communications architecture is already in place for office users. As long as users are able to access a secured internet connection (https) then there should be no issue connecting to the VPN.

Once the new application architecture is implemented, employees will be required to run an internet browser (preferably IE6) with a minimum of 128-bit encryption. User will then browse to a secured URL through their web browser to establish a secure connection with the corporate VPN. This will require that each location's firewall be configured to pass all secured traffic over port 443. Once a secured connection is established, users will be prompted to login with either their username or clock number and their chosen password.

After successful authentication to the website, employees will be taken to the main graphical user interface. This interface is where the majority of user interaction will occur and intranet websites can be accessed. The layout will be composed of links to the eight websites to which users have access. Since authentication to the main corporate VPN has already taken place, each site will no longer require a separate username and password combination. Each website that the user browses to will host all information related to that site. Users will have the ease of returning to the main VPN homepage at anytime by clicking on the "home" tab that will be displayed on all pages. This will allow for easy navigation throughout all corporate intranet sites.

The web systems and sites will be hosted out of corporate headquarters and operate off clustered server suites running Microsoft IIS (Internet Information Services). A clustered environment will provide the fault tolerance and failover capabilities required to maintain product efficiency as well as provide the processing power required to handle large amounts of user activity simultaneously. According to http://www.microsoft.com, "...if one of the nodes in a cluster becomes unavailable as a result of failure or maintenance, another node immediately begins providing service, a process known as failover. Users who are accessing the service continue to access the service, and are unaware that it is now being provided from a different server (node)" (What's New in Clustering Technologies, 2004). This solution is necessary to maintain the projected uptime of near 99%. In addition, with redundant server capabilities, this will allow IT personnel to perform maintenance tasks on server related systems and applications with no noticeable impact on site users.

Single sign-on will be provided through a central authentication service (CAS) server located at corporate headquarters. This server is the main system that will allow users access to multiple sites under one username and password combination. The CAS is designed with a few goals in mind:

* To facilitate single-sign-on across multiple web applications, as well as to core services that aren't necessarily web-based but have web front end

* To simplify procedures that applications need to follow in order to perform authentication

* To localize actual "primary" authentication to a single web application, which makes it easier for users to safeguard their password and lets [corporate headquarters] change authentication logic if necessary without having to change numerous applications

Below is a diagram (http://www.yale.edu/tp/auth/cas10.html) that outlines the basic input/output requirements for authentication through single sign-on authentication server:

So how does CAS work? "When...[the user]...logs into CAS, a cookie is saved in your browser. This cookie contains a unique ticket number that identifies you to the CAS server. Every time you access the site after you are logged in, your browser automatically transmits this cookie to the web server. CAS reads the cookie, looks up the ticket in its database, and identifies you" (Szorc, 2005). The central authentication server that is used in the organization will have tie-ins to the main Active Directory tree that is used by the organization. Since the organization is already running in a forest/domain model, the Active Directory database already takes advantage of secure updates and site replication.