The code above should be placed somewhere in the target application's domain. The code takes in query string parameters and writes them to the browser as cookies. It then opens a window to the target system. Since the cookies are in the browser, the session has been maintained and all is well. The only thing we need to do now is modify our original code to call this file passing the cookies instead of writing them to the browser. The format of the request is http://testsingle sign-on.com/setCookies.html?cookie=values;path=/&cookie=value;path=/. Therefore we need to take out the code that writes the cookies to the browser in our original example and add the following code:

<cfset cookieString="">
<cfloop collection="#cookieStruct#" item="key">
<cfset cookieString=cookieString & "#key#%3d#cookieStruct[key]#;path%3d/&">
</cfloop>

<cfoutput>
<script language="javascript">
window.open('testsso.com/setCookies.html?#cookieString#',
'SelectWindow','width=800,height=300');
</script>
</cfoutput>

The first chunk of code formats the cookies so that they are ready to be passed via the URL. We need to strip out "=" and replace it with the HEX equivalent, namely, "%3d". The next chunk opens a new window that points to the HTML page that sets our cookies and we pass the cookies in the URL. The setCookies.html file then writes the cookies to the browser, and then redirects the user to the target application...game...set...match. The obvious drawback to this approach is that you must have permission or access to set the setCookies.html file on the target domain. That completes SSO 101. Next we'll look more at East Carolina University's specific implementation.

The possibilities of implementing an SSO solution are nearly endless. We have chosen to extend our implementation with the addition of a managed password "store" database. This database contains all the userID and password combinations for each user for each externally accessible system or application (don't worry, the data is encrypted). When a user logs into our portal, after all the authentication sequence is completed, the information related to that user in the password store database for SSO purposes is retrieved and stored in session. This method reduces the amount of database activity, providing better performance while also making this information available to internal functions of the portal as well as internal software applications.

In addition to a managed password store database, we have also developed standard XML configuration files for each system we access via SSO. Obviously, as this article states, there are bits of information you need from the external system to allow the SSO process to work. What are the names of the input fields for the userID and password? What is the URL of the external system? Our standard, proprietary XML configuration file defines all the elements needed for the external system to be accessed. The power of this feature is that it is extensible enough to offer access to multiple systems. Need access to another system? No problem. Simply create the XML configuration file. Much like the authentication information mentioned previously, all XML configuration files are read and stored in an application-scoped variable managed by the portal.

With the addition of the managed password store and the XML configuration files, we are dangerously close to a robust SSO solution. We are currently adding an administrative tool or "wizard" to step users through the process of creating the XML configuration file, allowing SSO access to external systems and applications. This "wizard" will not require any knowledge of XML, only that the user knows the URL and a few basic elements of the external system. Remember all that coffee and late nights sleeping on the floor at work making our office seem more like a hotel than a workplace (confused? see our previous article in CFDJ)? Here we go again...

As your organization progresses through the evolutionary life cycle of implementing Web-based applications, keep single sign-on and Web application portals in mind. You can save yourself much time and many headaches by starting your Web application portal while you still have only a few applications. Then, for those systems that cannot be moved into the portal, implement a single sign-on solution. Users can be freed from remembering multiple passwords for each system as well as the URLs. By combining a Web application portal with a single sign-on solution, any organization can provide a single point of access for all Web applications enterprise wide. This can increase security for the organization and provide convenience to users. After all, isn't convenience for our customers the ultimate goal? Enough said.