On Wed, May 6, 2009 at 11:53 AM, Scott Holodak <sholo...@rutgers.edu> wrote: > Hi Catherine, Bill, > > Just a few points on the discussion: > > ==== > > Non-WFA Pros - simpler code: > > The biggest benefit of producing a WFA compatible provider is that the > incorporating it into a web application could be as simple as droping a dll > file in place and editing web.config. The difficulty in implementing the > provider it is outweighed by the simplicitly of using it. Plus, I think more > .NET developers would prefer to use something that fits the .NET model than > something that resembles the Java implementation--especially if the users > would consume the functionality in binary form anyway. > > ==== > > Non-WFA Pros - execution of CAS functionality in an event that allows access > to the Http Session > WFA - Cons - execution of CAS functionality must be in two events that do not > allow access to the Http Session > > The 'Session' is a higher level concept in ASP.NET, but you don't need it > handle caching a ticket. In > fact, I would argue that it would be a design flaw to do so. Remember that > the Session can be > configured for multiple persistence mechanisms (cookie, server process > memory, database, etc.). You > would need to account for the implications of all of those--a web farm > configuration doesn't have 'server > process memory' as a viable option. I don't think they are all appropriate > places to store the auth ticket > anyway.
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
