Hi Catherine, Sorry it too so long to respond...a bit buried at the moment. Here's some stream of thought feedback...
First, thanks for the SVN commits and your thoughtful post. I am very excited to see a budding community interested in a full featured JASIG .Net CAS client. The link to the comparison doc wrapped in my email...at first it didn't work for me, but then I saw the rest of the URL...anyway here it is again for others if they missed it: https://www.middleware.vt.edu/doku.php?id=middleware:cas:client:dotnet:jasig You refer to WFA as Windows Forms Authentication. It would probably be clearer and more accurate to call it ASP.NET Forms Authentication or Web Forms Authentication...no? Some more below inline... On Mon, Apr 27, 2009 at 11:03 AM, Winfrey, Catherine <cwinf...@vt.edu> wrote: > After much discussion here at VT, we still consider a CAS .Net client > that does not use Windows Forms Authentication (WFA) to be a better > solution. I have checked in code that uses HttpModules but not WFA as a > configurable option in the JasigCasClient sandbox. > > Pros / cons for the non-WFA approach: > Pros: > 1. simpler code > 2. ability to use an event (AcquireRequestState) where the Http > Session is available, allowing very simple code to maintain the CAS > response Assertion information across Http requests What is stopping the WFA based module from also using this event/method? > 3. no side effects because of piggy-backing one authentication > system on top of another (see web page for details) I may be missing something, but I don't see either of the side effects listed as an issue. For #1 (Context.User), the behavior will be the normal behavior for ASP.NET applications. For #2, the same logic applies to any application that uses some token to manage a session. In the WFA case it just happens to be the FAT. > 4. should still be able to use IPrincipal and a custom membership > provider for role authorization if desired > 5. ability to easily tell very early in the process, and anywhere > desired, if the Http Request represents a CAS-protected page (see web > page for details) > Cons: > 1. potential need to provide a custom membership provider > > Pros / cons for the WFA approach: > Pros: > 1. more familiar to Windows developers > 2. path for CAS-protected secure pages is set using the standard > web.config location element > Cons: > 1. more complicated code > 2. some side effects from piggy-backing CAS authentication on top > of WFA (see web page for details) > 3. the two events used (AuthenticateRequest and EndRequest) do not > have access to the Http Session, which presents difficulties in > maintaining the CAS response Assertion information across Http requests > (see web page for details) > 4. limited, at best, ability to tell if the Http Request represents > a CAS-protected page (see web page for details) > 5. more frequent round trips to the CAS server because of FAT > timeout or FAT removal because of browser cookie policies (see web page > for details) I don't understand how this would cause more frequent trips to CAS. Wouldn't it be the same with either approach? > > Details about these comparisons can be found at: > https://www.middleware.vt.edu/doku.php?id=middleware:cas:client:dotnet:j > asig > > Comments? There may not be a right answer. Folks coming from a ASP.Net background with existing applications that they would like to CASifying might be more included to WFA model. Folks coming from a Java background might be more inclined to a simpler approach. If we get the CAS client domain model right, we should be able to have two approaches side by side leveraging mostly the same code. No? 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
