To allow for the appearance of CAS authentication into Outlook Web Access two ISAPI filters were created. The first ISAPI filter performs CAS authentication for all content below its container. Specifically the ISAPI filter redirects traffic to the CAS login page where the user is either validated by their CAS TGT, or by providing a username and password. The filter then verifies the Service Ticket returned as a parameter from CAS. The Filter then strips the ticket from the request URL and sets a session cookie named IISCAS with a value equal to the authenticated user’s username. If this cookie is already present, the CASIsapi filter immediately returns a valid response and allows access.
The second ISAPI filter (cas2owa) requires the IISCAS cookie before providing access to content below its container. Cas2owa is programmed to only validate for OWA relative urls (i.e. /exchange, /exchweb). After verifying the IISCAS cookie and that a request is being made to an OWA url the filter then inserts an Authorization header into the http request. The username and password for this Authorization is hard coded into the filter. In this manner all CAS authenticated users are “proxied” to a specific OWA user. This OWA user has administrative level access to OWA and may perform operations on any mailbox. To prevent misuse, the cas2owa filter compares the CAS username with the requested url. An attempt to access another users mailbox results in a redirect to the inbox of the CAS authenticated user. For instance: In order for jsmith to access his mail though OWA he must go to the following url: http://owa.server.com/exchange/jsmith. If he were to attempt to go to http://owa.server.com/exchange/jdoe, the cas2owa filter would redirect his request back to http://owa.server.com/exchange/jsmith.
