Hi Chris, Check the cookie settings on the formsAuthentication element in web.config. The situation you described in your post would be explained if the CAS client is setting the cookie under a path or domain where the browser won't send it back on the return trip or if you are requiring a secure connection for the cookie on pages that aren't https:// (most secure workaround here is to go 100% https on your site).
You should be able to verify this by looking at the logs or with Fiddler. When the CAS ticket gets validated, the CAS HttpModule will call FormsAuthentication.SetAuthCookie(). On the response to your client, you should see a Set-Cookie header for a cookie whose name matches the web.config formsAuthentication cookie name (default is .ASPXAUTH). If that cookie has any of these parameters: Path, Domain, Secure, you'll need to make sure that those are valid for your scenario. You'll know if there's a problem on the next request if the cookie isn't included in the headers. That means that either the domain, path, or secure setting wasn't valid or... or possibly a very weird situation where you have maxed out the maximum amount of cookie storage that the browser will allow for that domain. This can happen if you are using cookies all over the place in your application or are attempting to persist large amounts of data in cookies. Each browser has different limits and they change every now and then. If you really need to get your hands dirty, another useful troubleshooting approach is to remove the nuget/dll from your project and add the DotNetCasClient source to your solution. If you add it as a project reference rather than an assembly reference, you can set breakpoints and step right into the client code. The CasAuthenticationModule is a pretty good place to plug into the pipeline events and you can step into the CasAuthentication class methods from there. -Scott On Tue, Jan 22, 2013 at 5:22 PM, Christopher Comstock < [email protected]> wrote: > I'm using the dotnet cas with mvc3 (.net4), and monitoring the CAS > logs and fiddler, everything appears to authenticate fine from the > primary cas server. I see the ticket come back, the user info etc. But > when it sends me back to my site, it's as if I'm still not > authenticated, so it gets another ticket (each ticket is valid and has > its own incremented/unique number), returns to my site, cas still > doesn't process the ticket, so it repeats, ending in a redirect loop > that the browser detects and kills. > > This (from the documentation) is apparently where it fails: > > "Assume the ticket validates successfully. The > CasAuthenticationModule sets the context.User and > Thread.CurrentPrincipal to a CasPrincipal for the current request. It > also drops a FormsAuthenticationCookie containing a > FormsAuthenticationTicket to the client which will be detected by the > CasAuthenticationModule and used to authenticate subsequent requests. > The MVC RequestHandler executes. This time, the [Authorize] attribute > passes the test" > > My protected mvc controllers do simply have an [Authorize] tag on > them. There are commercial SSLs on both sides, and my client site is > on the same network as the CAS system. > > My client CAS logs showing ticket creation and loop below, anyone have > any ideas? > > DotNetCasClient.Protocol Verbose: 3237 : Ticket validation response: > <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> > <cas:authenticationSuccess> > <cas:user>u3468</cas:user> > <!-- Begin Ldap Attributes --> > <cas:attributes> > <cas:uid>u3468</cas:uid> > > <cas:mail>[email protected]</cas:mail> > > <cas:username>u3468</cas:username> > > <cas:sn>Test</cas:sn> > > <cas:givenName>U3468</cas:givenName> > > > <cas:memberOf>cn=allUsers,u3468</cas:memberOf> > > > <cas:alluserrole>cn=allUsers,u3468</cas:alluserrole> > </cas:attributes> > > <!-- End Ldap Attributes --> > </cas:authenticationSuccess> > </cas:serviceResponse> > > DateTime=2012-12-18T21:32:53.7639627Z > DotNetCasClient.Protocol Verbose: 3237 : Creating > FormsAuthenticationTicket for > ST-207-TJFiTssqFTT5CiUkbEHL-idpdev.111111.edu > DateTime=2012-12-18T21:32:53.9182804Z > DotNetCasClient.HttpModule Information: 3237 : Redirecting from login > callback > DateTime=2012-12-18T21:32:53.9309775Z > DotNetCasClient.HttpModule Information: 3237 : Redirecting to CAS Login > Page > DateTime=2012-12-18T21:32:53.9475814Z > DotNetCasClient.Protocol Information: 3237 : Redirecting to > > https://idpdev.111111.edu/cas/login?service=https%3a%2f%2ftest.mysite.com%2finstructor%2findex > DateTime=2012-12-18T21:32:53.9475814Z > DotNetCasClient.HttpModule Information: 3237 : Processing Proxy Callback > request > DateTime=2012-12-18T21:32:54.0237640Z > DotNetCasClient.Protocol Verbose: 3237 : Constructed validation URL > > https://idpdev.111111.edu/cas/serviceValidate?service=https%3a%2f%2ftest.mysite.com%2finstructor%2findex&ticket=ST-208-fzG1kpaoSQ3d5WlgfhjS-idpdev.111111.edu > DateTime=2012-12-18T21:32:54.0237640Z > DotNetCasClient.Protocol Verbose: 3237 : Ticket validation response: > <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> > <cas:authenticationSuccess> > <cas:user>u3468</cas:user> > > ...continues the same loop until browser notices and quits. > > In fiddler, I can also see a) my secure page being hit, b) the call > out to the CAS server, c) the return hit to my side with the ticket in > the querystring, but it simply repeats. > > -- > 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
