Indiana University has produced a CAS ISAPI filter for IIS. This can be found in the contrib/ directory of the CAS Client Distribution.
Below are some gotchas spotted by Phil Sladen that will hopefully help if you're trying to deploy the CAS ISAPI filter.
- The filter will not work for an initial authentication request with request parameters. The presence of request parameters yields a horrible infinite loop of login validation failures. (Validation fails to properly consider the request parameters, and then its failure modality is to retry obtaining a service ticket. Ticket acquisition and validation do not agree on handling of the parameters and so inifinite loop of failure.
- I believe security has been tightened on this platform so that validation of the ticket now fails unless the quality of the HTTPS connection appears to be 100%. This means that if using a self-signed certificate, the certificate must be imported into the root authority keystore of the client that is trying to do the validation (for IIS, you have to run 'mmc' and import the certificate into the 'Trusted root certification authority' folder under the certificate tree. For Java (Tomcat), you need to import the certificate into it's 'cacerts' keystore). Also, this way means you don't need to add code to the Java side to accept a poorer quality connection
- Make absolutely sure the access control permissions on the filter DLL and config file are the same as other files in the 'inetsvr' folder, or the filter will quietly not initialise.
- Don't expect much debug from the filter even if you use 255 in the '<loggingMask>' tag!
- In the filter configuration file, the '<serviceParamName>' tag should be set to 'service' and the '<ticketParamName>' tag should be set to 'ticket' to match what the server expects. I don't think the '<appParamName>' and '<appCode>' tags really need to be set to anything in particular.
- Consider instead the CCCI ISAPI filter implementation.