Thank you for the clarification on the workflow. I was wrongly under the impressions that the cas cookie should pass onto the .NET application.
Going thru the steps below and in debugging the .Net client, I realized the app is actually failing on the 3rd step, validating the CAS ticket. The exception trace showed that "trust relationship could not be established because the remote server could not be trusted." I thought had created/imported the certs successfully but it turns out that it's not just enough to import certificates into the CA root using IE but it has to also be done using MMC and for the local computer group as well since that's the process by which IIS runs. Copying the cert from the current user group over to the local computer group did the trick. This link greatly helped: http://blogs.msdn.com/b/jpsanders/archive/2009/09/16/troubleshooting-asp-net -the-remote-certificate-is-invalid-according-to-the-validation-procedure.asp x Thanks again for your feedback. Misagh -----Original Message----- From: Scott M. Holodak [mailto:[email protected]] Sent: Tuesday, November 01, 2011 8:04 AM To: [email protected] Subject: RE: [cas-user] Setting up ExampleWebsite - Too many redirects & no cookie? Hi, As Scott Battaglia pointed out, the cookies generated by the CAS server are unrelated to the cookies responsible for authentication within your .NET application. You should be able to verify this behavior using Firebug or Fiddler2. For lower-level troubleshooting, enable the diagnostic tracing (detailed in the 'Configure Diagnostic Tracing' section here: https://wiki.jasig.org/display/CASC/.Net+Cas+Client). This will give you more insight into what the CasAuthenticationModule is doing. Here is the basic workflow: - An anonymous user hits a page on your ASP.NET application that requires authentication/authorization. The FormsAuthenticationModule redirects the request to the loginUrl (defined in web.config @ configuration/system.web/authentication/forms). With CAS setup & configured properly, this is the CAS server's login action: https://casserver.example.com/cas/login?service=https%3a%2f%2fappserver.exam ple.com%2fexample%2fdefault.aspx - The user authenticates against CAS. CAS creates a service ticket and redirects the user back to the service url above with a service ticket in the URL that is only meaningful to the CAS server. (https%3a%2f%2fappserver.example.com%2fexample%2fdefault.aspx --> https://appserver.example.com/example/default.aspx?ticket=ST-2f48-c6LfeZDfZm CiKPaNaPfy-fed06). Before it redirects back to the application, it sets a cookie that is scoped to casserver, but this is unrelated to the .NET workflow. - The CasAuthenticationModule detects the ticket (ST-2f48-c6LfeZDfZmCiKPaNaPfy-fed06) in the request for /example/default.aspx and attempts to validate it behind-the-scenes. (https://casserver.example.com/cas/serviceValidate?service=https%3a%2f%2fapp server%2fexample%2fdefault.aspx&ticket=ST-2f48-c6LfeZDfZmCiKPaNaPfy-fed06). If the validation succeeds, the CasAuthenticationModule treats the currently requested page as authenticated and drops a standard FormsAuthenticationCookie on the client. - If redirectAfterValidation is true, the CasAuthenticationModule redirects from https://appserver.example.com/example/default.aspx?ticket=ST-2f48-c6LfeZDfZm CiKPaNaPfy-fed06 to https://appserver.example.com/example/default.aspx (cosmetic). Because of the presence of the FormsAuthenticationCookie, this request is already authenticated by the FormsAuthenticationModule. - All subsequent requests are authenticated by the FormsAuthenticationModule provided the FormsAuthenticationCookie is valid. The CAS module doesn't play a role for that user anymore until the cookie expires/after logout. In the example above, the relevant configuration sections might look like this: <casClientConfig casServerLoginUrl="https://casserver.example.com/cas/login"; casServerUrlPrefix="https://casserver.example.com/cas/"; serverName="https://appserver.example.com"; notAuthorizedUrl="~/NotAuthorized.aspx" cookiesRequiredUrl="~/CookiesRequired.aspx" redirectAfterValidation="true" renew="false" singleSignOut="true" ticketValidatorName="Cas20" serviceTicketManager="CacheServiceTicketManager" /> <authentication mode="Forms"> <forms loginUrl="https://casserver.example.com/cas/login"; timeout="30" defaultUrl="~/Default.aspx" cookieless="UseCookies" slidingExpiration="true" path="/example/" /> </authentication> You may want to use path="/" to have the FormsAuthenticationCookie scoped to your entire server rather than just the /example/ website. If you leave this as /example/ but your example web site isn't located there, CAS authentication will not work & you will run into redirection issues. Aside from that, the most common problems you will run into are related to SSL and certificate trust between your CAS server and your app server. That is, if casserver.example.com doesn't trust appserver.example.com's SSL certificate, validation will generally fail, particularly if you are using a serviceTicketManager and proxyTicketManager (single-sign-out and proxy authentication). See here for more details on configuration options for Forms Authentication. I don't think the .NET CAS client supports the cookieless option (never tested). Aside from that, the domain, name, path, protection, requireSSL, slidingExpiration, and timeout are all supported, but keep in mind that you can break things by tampering with domain & path, and requireSSL. See here for more details on Forms Authentication configuration: http://www.asp.net/security/tutorials/forms-authentication-configuration-and -advanced-topics-cs -ScottH -----Original Message----- From: Misagh Moayyed [mailto:[email protected]] Sent: Monday, October 31, 2011 7:40 PM To: [email protected] Subject: RE: [cas-user] Setting up ExampleWebsite - Too many redirects & no cookie? After a little bit of digging around using Chrome's dev tools, I noticed that as soon as I hit the login button, response headers and the cookies for the login action are there with path of the cookie being set to "/cas". However, once the redirect moves onto the final page "default.aspx" cookies are vanished. All suggestions are welcome. -----Original Message----- From: Misagh Moayyed [mailto:[email protected]] Sent: Monday, October 31, 2011 12:27 PM To: [email protected] Subject: RE: [cas-user] Setting up ExampleWebsite - Too many redirects & no cookie? The serverName is set to the full computer name and it is definitely accessible on the browser. I have tried it without the port # and the result has been the same. Also, I tried to follow your suggestion and reset the redirectAfterValidation property value to false but it looks like the value has to be true for the forms authorization element to work. Otherwise, a configuration exception is thrown. Based on the doc, the cookie only sent on secure connections unless the setting for the ticket generator is changed. I have tried the set up with both true/false values for "cookieSecure" and the result has been the same. I am not just why the cookie is not sent because I see it there in the browser history and in the CAS logs. ...but I have been wondering, could this be a permissions issue ? The cookie by default is supposed to go to "/". Could this be that a write-permission is denied and the cookie is never placed on the server ? Misagh -----Original Message----- From: Marvin Addison [mailto:[email protected]] Sent: Monday, October 31, 2011 11:05 AM To: [email protected] Subject: Re: [cas-user] Setting up ExampleWebsite - Too many redirects & no cookie? > <casClientConfig > casServerLoginUrl="https://<full-machine-name>:8443/cas/login" > casServerUrlPrefix="https://<full-machine-name>:8443/cas/" > serverName="https://<full-machine-name>:443" For simplicity, serverName should be the fully-qualified DNS name of the client host. Also, you might set redirectAfterValidation="false" to see whether that helps. M -- 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 -- 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 -- 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 -- 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
