Web Forms Authentication sounds good (and still lets the WFA acronym okay for my wiki page).
My comments: 1. Use of a different events for the WFA approach. I tested this briefly and I dont think it will work, at least not without some kludging. If the JasiCasClient OnAuthenticate method is registered for the AcquireRequestState event rather than the AuthenticateRequest event, it never gets called for a secured page. When the AuthenticateRequest event doesnt establish an IsAuthenticated true state, the only other events fired are PostAuthenticate and EndRequest. 2. Side effects. I agree that these side effects probably are not issues in terms of things that would have to be worked around if the WFA approach is selected. I just think that the fact that the other approach avoids these types of issues makes it preferable. 3. Round trips to CAS login. For the non-WFA approach, additional login requests to the CAS server are avoided by using the presence of the IPrincipal in the session for authentication purposes. One of the biggest advantages I see to the non-WFA approach is the ease of access to the session in order to maintain the user information returned in the CAS response, especially for SAML 1.1, and make it available to the web page. Another is the simplicity of the code. -----Original Message----- From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] Sent: Monday, May 04, 2009 15:47 To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] .Net JasigCasClient 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: cwinf...@vt.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
smime.p7s
Description: S/MIME cryptographic signature
