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.example.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-c6LfeZDfZmCiKPaNaPfy-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%2fappserver%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-c6LfeZDfZmCiKPaNaPfy-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
