Novell Home

Using iChain Single Sign-on with Microsoft Outlook Web Access

Novell Cool Solutions: Feature
By Harold Moore, Rick Meredith, Shane Johns

Digg This - Slashdot This

Posted: 12 Nov 2001
 

Products: iChain, Novell Account Management, and DirXML

Using the steps outlined here we will explain how to simplify, secure and accelerate the clumsy, unsecured double login process Microsoft Exchange users perform when using Outlook Web Access Server.

Without using a iChain Solution, a typical Outlook Web Access (OWA) login process is:

Microsoft Standard Login Process

The user enters in the Log On Box "hmoore" and hits Enter.

Another login box appears(above) and the user is required to enter his "username" again and "password" to gain access to the Mailbox (below).

Novell iChain Login Process

Using the iChain Solution, we begin by typing the URL for the Outlook Web Access. We are prompted to accept a site certificate.

iChain provides the SSLizer (secure exchange) to maintain data confidentiality information is transferred over the Internet. The SSLizer not only simplifies the delivery of secured content over the Internet, it also removes the requirement to encrypt data at the web server, allowing the web server to perform its designed function to deliver web content as fast as possible to the user. We accept the certificate and are presented with a customizable iChain login screen.

Note: Most Outlook Web Access Servers run mostly unprotected (without SSL) because adding SSL to the Web Server results in slower performance.

We are presented with a custom login screen(below).

We enter our username and password into the iChain login screen and iChain handles the clumsy Outlook Web Access double login process for you. Leaving you in your mailbox Easier, Faster and more Secure (128 bit SSL) than before.

Under the Hood

Single Sign-On

In order to understand single sign-on it is critical to know how a web application is expecting to receive the user's credentials. Some web applications require that the user's credentials be passed in the query string, others require the user name and password to be in the HTTP authentication header, and some require both. For example, if a web application presents a form to allow users to enter their credentials they are expecting the user's credentials to be passed in the query string. If a dialog box is presented then they are expecting the HTTP authentication header to contain the user's credentials. In the case of Microsoft's Outlook Web Access both the query string and the HTTP authentication header are being used.

For web applications that require Basic HTTP Authentication, iChain performs single sign-on by populating the HTTP authentication header with the user's credentials. If a server requires the user's credentials in a query string iChain will populate the query string with the appropriate name value pair.

By enabling "Forward authentication information to the web server" under the web accelerator's authentication option, the HTTP authentication header will be populated with the user's credentials and sent to the web server. By default, iChain will send the user's distinguished name and password. For example, if I login to iChain as "hmoore" who's context and password is "nyc.americas.novell" and "novell" then the HTTP authentication header will be populated with the base 64 encoding of "cn=hmoore,ou=nyc,ou=americas,o=novell:novell". This is fine if we are accelerating an application that is expecting the full distinguished name. The problem with this is that most web application are not expecting the user ID in this format, such as OWA. They are just expecting the username and password, "hmoore:novell".

By enabling iChain's Object Level Access Control (OLAC) technology we are able to modify the user's credentials that are being passed in the HTTP authentication header and populate the query string with the user's information.

Two pre-defined parameter names exist, which instruct iChain to modify the user's credentials before populating the HTTP authentication header. The two parameters are "iChain_UID" and "iChain_PWD" which specifies the user name (iChain_UID) and password (iChain_UID). If "iChain_UID" nor "iChain_PWD" are specified then the parameter name will be sent in the query string with the value specified.

When "iChain_UID" is specified iChain substitutes the distinguished name of the user with the specified LDAP value, such as "cn" (common name), which can be used by non-context aware web servers to authenticate the user.

iChain injects common name of user into HTTP Header based on iChain_UID setting

As iChain_UID and iChain_PWD are built from LDAP values, iChain single sign-on can even support web servers where the user's authentication credentials are different than those used to authenticate to iChain.

CREATE ACCELERATOR

Create an accelerator for the Outlook Webaccess Server (see iChain user guide) with SSL enabled.

  1. Create a protected resource.
    This protected resource should be the exchange server (Eg. http://www.YourCompany.com/)
  2. Specify restricted access.
  3. Enable Forward Authentication information to Web Server:
    • Option must be enabled in GUI Cache ->Web accelerator->Authentication Options (after enabling authentication)-> "Forward Authentication information to Web Server".
    • Enable and Configure OLAC on the protected Resource.
    • Add the following parameters based on your Outlook Web Access server:

CASE 1:

For Outlook Web Access Servers configured to take the NT-Account Name

Name: iChain_UID mailbox
DataSource: LDAP LDAP
Value Cn cn

CASE 2:

For Outlook Web Access Servers configured to take the E-mail Address Property

Name: iChain_UID mailbox
DataSource: LDAP LDAP
Value cn mail

TESTING iChain OLAC CONFIGURATION

On the iChain AUTH SERVER CD in the TOOLS subdirectory locate the iChainAuthOLAC.ASP. For more information read the iChainTools.txt.

Copy the iChainAuthOLAC.ASP into the Microsoft Internet Information Server's directory where the Outlook Web Access DEFAULT.ASP and DEFAULT.HTM files reside.

Point your URL to the file "http://YourCompany/iChainAuthOLAC.ASP". Authenticate through iChain. Based on the configured OLAC parameters this file will display and decode the header and display it on the screen. Verifying parameters are mapped and displayed properly.

MICROSOFT OUTLOOK WEBACCESS SPECFIC SERVER MODIFICATIONS

Normally customers who configure Microsoft Outlook Web Access Server configure the URL to the following.

www.YourCompany.com/exchange or http://ipaddress/exchange

That calls a DEFAULT.ASP which redirects to the user to LOGIN.ASP. The LOGIN.ASP is the file that collects the first user name credential (yellow screen).

After you enter the Log On name and hit enter, a gray dialog box comes up and you enter your username and password. LOGIN.ASP(yellow screen) builds the first part login to pass to LOGONFRM.ASP (gray login box)which completes the login and passes it to the domain for authentication.

Example of URL Outlook Web Access needs for login:

http://hmoore:novell@IPADDRESS/exchange/logonFrm.asp?mailbox=hmoore

?mailbox=hmoore comes from yellow screen
hmoore:novell from gray pop up login box

The domain needs the login information in the form to read correctly and process.

Simply use this structure and enter into any URL without iChain, replacing username:password and ?mailbox= with valid id's to build this login and Single-sign you in.

CASE 1 form

http://hmoore:novell@IPADDRESS/exchange/logonFrm.asp?mailbox=hmoore

CASE 2 form

http://hmoore:novell@IPADDRESS/exchange/logonFrm.asp?mailbox=hmoore@YourCompany.org

Using iChain Single-sign on the user's information is gathered and sent it to the web server in one step. Instead of Microsoft's Outlook Web Access two step login.

ASP CHANGES:

With iChain in place there is no need to go to the LOGIN.ASP page. Change the DEFAULT.ASP and DEFAULT.HTM. So it no longer calls the LOGIN.ASP. Replace LOGIN.ASP with LOGONFRM.ASP

MODIFYING LOGONFRM.ASP

You will need to edit the this file.

When the iChain box receives a content length of zero from a web server it will close the connection to the browser. When accelerating the login page of Outlook Web Access, in the same response the web server tries to set a cookie and do a redirect. This response has a content length of zero. Since iChain closes the connection to the browser, the cookie gets set but the browser doesn't do the redirect and the web browser appears to be hung.

To remedy the problem you must modify the LOGONFRM.ASP file. Under the MainLogon section it is necessary to comment out the line of code "Response.end". This will prevent the web server from sending a response with a content length of zero. This is the part of the code that got modified:

Session(CURRENT_MAILBOX) = bstrMailbox

Response.Buffer = TRUE

Response.Status = ("401 Unauthorized")

' Response.end

End If

Conclusion

As demonstrated in this paper, iChain is a robust, scalable security architecture that can simplify net security, accelerate content, and provide personalization. Most importantly, it provides an infrastructure than can accelerate the rate at which your organization can provide new services on the Net, and create One Net.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell