It turns out everything was setup ok except one thing. In the web
config, forms authentication tag, the "path" attribute was not set to
the default value of "/" and I missed it.  All good now.

On Tue, Jan 22, 2013 at 6:16 PM, Scott <[email protected]> wrote:
> 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

-- 
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

Reply via email to