On Tue, May 5, 2009 at 1:39 PM, Winfrey, Catherine <cwinf...@vt.edu> wrote:
> Web Forms Authentication sounds good (and still lets the WFA acronym okay
> for my wiki page).
OK. Just wanted to make sure we are talking about the same thing. :)
>
> My comments:
>
> 1. Use of a different events for the WFA approach.
> I tested this briefly and I don’t 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
> doesn’t establish an IsAuthenticated true state, the only other events fired
> are PostAuthenticate and EndRequest.
Rather than register OnAuthenticate for AcquiredRequestState, I think
one could leave it where it is and simply add a new handler method,
OnAcquiredRequestState, that would check for a flag/object on
HttpContext.Items and retrieve/store the CasPrincipal in the Session.
The flag/object would be set by OnAuthenticate, and would either be
the initial CasPrincipal or a flag based on the FAT to retrieve the
CasPrincipal from the Session.
"HttpContext.Items: Gets a key/value collection that can be used to
organize and share data between an System.Web.IHttpModule interface
and an System.Web.IHttpHandler interface during an HTTP request."
>
> 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.
I still don't see how the issues are any different for either
approach...maybe I'm still missing something.
>
> 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.
I don't foresee the WFA approach needing additional CAS login
requests. If we can't figure out how to effectively attach the
CasPrincipal to a session we would indeed be sunk. The two approaches
we have so far are serialization to the FAT cookie, or some hook into
the Session. Both have their pros and cons, either one should be
achievable.
> 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.
I'm still of the mind that both approaches have their place, and that
both should be able to leverage a common CAS client domain model.
With either approach I would expect application code to be the same
and look something like this:
// existing APS.Net code should continue to work as is
IPrincipal user = HttpContext.Current.User;
user.IsInRole("student"); // potentially queries attributes returned
via SAML 1.1. CAS response
user.Identity.Name // returns name of the current user (i.e. Principal Name)
// using extended Cas functionality should feel natural to ASP.Net
ICasPrincipal user = HttpContext.Current.User;
IProxyTicket ticket = user.GetProxyTicketFor("http://some.proxied.service/";);
ILookup attributes = user.Assertion.Attributes;
Best,
Bill
>
>
> -----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
>
--
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
