Hi Bill, Cathy, I haven't really had a chance to dig into how CAS is implemented. I haven't incorporated Single-signout in my application and I don't know what the CAS-Web server communication looks like. I'll assume it's a regular HTTP request that gets handled specially from a trusted source. If so, these can be handled by a Handler or Module (I forget which one is which). I'll try and address the points conceptually, but correct me if I'm missing something.
=== Bill My thinking is that you would want to encrypt the information necessary to recreate the Principal in the cookie. When you authenticate the request, you attempt to decrypt the cookie. If you can't, it means it was tampered with. If you can, you recreate the principal with the decrypted data. You don't literally need to serialize & de-serialize the principal. If all that you're storing in the cookie is the username, you don't even have to re-invent the wheel. Just use FormsAuthentication.SetAuthCookie(...). The benefit here is that the .NET Framework takes care of validating the cookie & setting up the principal for requests when authenticating subsequent requests. This is some code from my login handler: [1] FormsAuthentication.SetAuthCookie(Username, false); [2] FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket(Username, false, 30); [3] FormsIdentity Identity = new FormsIdentity(Username); [4] GenericPrincipal GenericPrincipal = new GenericPrincipal(Identity, null); [5] HttpContext.Current.User = GenericPrincipal; [6] System.Threading.Thread.CurrentPrincipal = GenericPrincipal; In subsequent requests, the HttpContext.Current.User and System.Threading.Thread.CurrentPrincipal are set by the Forms Authentication module automatically and I don't have to worry about it. The reason I had to do it in the Login event handler is because the cookie created in SetAuthCookie() isn't available until the next request and I need to do additional processing on the user prior to the login redirect. If I didn't, the redirect would make lines [5] and [6] unnecessary. See here for some more background: http://msdn.microsoft.com/en-us/library/ms998372(dev10ide).aspx === Cathy, As far as single sign-off goes, my suggestion would be to add invalid tickets to the Cache object. HttpContext.Current.Cache.Add(...). The Cache collection takes care of removing stale items. I'm not sure how the Cache collection works across servers, but I'm pretty sure it's configurable like the Session provider. On each request, check if the FormsAuthenticationCookie shows up in the Cache, and handle it accordingly. I'm not sure at what point in the request processing you'd handle single sign-outs. My thinking would be BeginRequest (just before AuthenticateRequest). I'm pretty sure that the Cache collection belongs to the Application, so it should be available. You could destroy the cookie and clear out the principal. That should be enough to get the Authorization subsystem to treat the request as anonymous. Then the Authorization subsystem would take care of either redirecting you to the Login page or leaving you where you are (depending on the authorization rules for the page you're on). Scott Holodak REX | RIAS Extensions ----- Original Message ----- From: "William G. Thompson, Jr." <wgt...@gmail.com> To: cas-dev@lists.jasig.org Sent: Wednesday, May 6, 2009 12:10:19 PM GMT -05:00 US/Canada Eastern Subject: Re: [cas-dev] .Net JasigCasClient Hi Scott. This issue is not so much as where to store the ticket as to where to cache the ICasPrinciple and IAssertion. In regular WFA the username is just stored in the FAT and the IPrincipal is re-created for every request. Typically, CAS clients store the CasPrincipal/Assertion in a server-memory cache (Session) that is tied to a specific session. Thoughts on where to store the ICasPrincipal/IAssertion? I was consider the Session and then adding another event handler to store/retrieve it into Context.User, etc. for each request. Bill -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
