Beware of the CAS ISAPI filters that exist... They don't terminate headers correctly and Chrome will complain and not continue.
UC Davis had the best one out there (IMO), but aren't able to support it anymore. If the IIS version is high enough (7 and 8, I believe), you can use the .net CAS client to perform the authentication. I did this on a test server and was in the process of convincing the vendor to try it, but they were able to switch to use ezproxy. There is some documentation on jasig on how to make this work. -John From: John Gasper [mailto:[email protected]] Sent: Wednesday, September 10, 2014 10:39 AM To: [email protected] Subject: Re: [cas-user] CAS ISAPI filter configuration Hi Paul, I haven't specifically worked with the CAS ISAPI filter, but in general ISAPI filters intercept all calls to a web application before the actual page gets hit. (This is very much like how the .NET Client works). It could be that you can set the service url to be whatever you want CAS Server to redirect the browser back to. Based on the age of the filter I wouldn't be surprised that it doesn't dynamically generate the service url. Just my completely uniformed thoughts. -J- --- John Gasper IAM Consultant Unicon, Inc. PGP/GPG Key: 0xbafee3ef On 9/9/14 7:25 PM, Paul B. Henson wrote: One of my colleagues has an application that runs under IIS that he would like to use central authentication for. Unfortunately, the company is not interested in integrating CAS support into their application. However, it does currently support delegating authentication to IIS and integrating into Windows domain authentication. Based on my limited understanding of that infrastructure, I thought we should be able to use the CAS ISAPI filter to make this application use CAS rather than Windows domain authentication (with a caveat; I assume the application is looking for the standard remote_user header, the application would need to either need to be modified to support looking for the authenticated username in a custom header, or we would need to binary edit it to change the header it currently looks for). He has it installed and mostly configured, but he is not sure what to set the "Service URL" to, and neither am I. In a CAS transaction, the service URL is where the CAS server sends a browser after it gives out a service ticket after successful authentication, and that URL is then responsible for consuming the service ticket, validating it with CAS, and then providing access to the underlying application. But given in this case the application has no idea it is using CAS, shouldn't the "Service URL" functionality be handled by the CAS ISAPI filter itself somehow? Or am I misunderstanding how the CAS ISAPI filter is supposed to work? Any hints on how to appropriately configure this would be much appreciated. Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [email protected]<mailto:[email protected]> California State Polytechnic University | Pomona CA 91768 -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
