Hi Scott! Welcome to the Jasig cas-dev list and thanks for the thoughtful post. The fact that AuthenticateRequest fires every time really threw me for a while. I had imagined that this would only fire when an unauthenticated user tried to access a protected resource, but as you rightly point out it fires on every request. I don't think we necessarily have to store the CAS ticket in the FAT cookie though, we should be fine just with whatever FormsAuthN needs to tie the request back to the user. I'll check out the provider links, a Passport provider sounds interesting.
Just to remind everyone, I've got a draft port of the code (1.0 protocol) in the sandbox at, https://www.ja-sig.org/svn/sandbox/JasigCasClient It's not yet functional, but I'm hoping to at least use the CAS domain classes in a working solution. I'm finding that SVNMonitor is a really handy tool to keep abreast of commit activity. http://www.svnmonitor.com/default.shtml Cheers, Bill On Thu, Mar 26, 2009 at 5:47 PM, Scott Holodak <sholo...@rutgers.edu> wrote: > Hi, > > I've been reading, but haven't posted to this list yet. Here's my 2 sentence > introduction: > > I maintain a .NET application for Rutgers that uses CAS. I worked under Bill > Thompson on the project for about a year and got a very quick crash course on > CAS from Scott Battaglia. > > > Now here's my very long message: > > The CAS implementation we went with sits on top of Forms Authentication and > basically shoehorns the CAS behavior into the Login page. Forms > authentication and ASP.NET takes care of locking users on the login page (via > the Forms Authentication and/or the URL authorization). The login page took > care of ticket validation. We used a SqlMembershipProvider as a user list > and (using a standard password for every user in the > SqlMembershipProvider--we're not using SqlMembershipProvider to check/reset > passwords). We then use the SqlRoleProvider for all roles on those usernames. > > In other words, we used CAS To determine whether a user had a valid Rutgers > username/password, used the username that CAS returns to check the > SqlMembershipProvider using a default password for everyone (to make sure > that the valid Rutgers user was allowed to access the app), then called > FormsAuthentication.RedirectFromLoginPage. Not terribly elegant, but pretty > easy to get up and running quickly. If it sounds unsafe, I'm not explaining > it correctly--the SqlMembershipProvider isn't the password authority, CAS is. > > Modeling CAS Authentication after the Forms Authentication provider is not a > bad idea, but it's non-trivial. The module is just one piece of the puzzle. > The AuthenticateRequest event fires on every single request, so you would > need to store the CAS ticket in a cookie and validate that cookie--quickly. > You would want to be able to trust the cookie until it expires (and prevent > tampering) and optionally push the expiration out whenever a new request > comes in--don't validate the ticket on every request. Setting the cookie > would probably have to take place in a custom membership provider. The > HttpModule is just one piece of the Forms Authentication puzzle. The > FormsAuthentication classes are sealed/non-inheritible/non-overridable. > There are about 20 classes that make it all work. Without being able to get > at/alter the plumbing underneath Forms authentication, I'm not sure where you > would set the CAS cookie, and what order the HTTP modules are fired in order > to authenticate the requests. > > The relationship between the Forms Authentication and the Membership > Providers is difficult to dissect and I'm not sure that there is a way to add > another authentication type besides Forms and Passport > (web.config:configuration\system.web\authentication\[forms|passport]). I > couldn't find the configSections defined anywhere in the .config files in > c:\windows\Microsoft.NET\Framework\v2.0.50727\CONFIG. > > The passport provider is a lot like what CAS is doing. I think it has been > replaced by the Windows Live SDK. This is MS's single-sign-on > implementation. The sample C# code in the Windows Live SDK looks like it > short circuits the authentication provider model, but the original Passport > provider code might be a good place to start disassembling or looking at Mono. > > If it's possible to implement a Passport provider, most of the heavy lifting > might already be taken care by the code included in the framework. > > I'm not sure how much time I'd have time to contribute to the actual coding, > but I'm happy to help out in whatever way I can. I would very much like to > pull out my implementation and plug in a tested .dll & configuration. I'd > also like to see if/how this is done. > > Here are some resources that might be useful: > - http://msdn.microsoft.com/en-us/asp.net/aa336558.aspx > Introduction to the Provider Model > Introduction to the Provider Model > Membership Providers > Deep Dive on the ASP.NET Providers > Microsoft ASP.NET 2.0 Providers: Introduction > Membership Providers > - http://msdn.microsoft.com/en-us/library/bb404787.aspx > - http://go.microsoft.com/fwlink/?LinkID=86932&clcid=0x409 > > If you decide not to go the low-level way, another approach would be to > implement a CasLogin control for login pages that takes care of redirecting > users to the CAS login screen & validating the CAS ticket on the return trip, > making the calls to the FormsAuthentication methods automatically. That > could be packaged into a DLL, but it's not as pretty. > > Scott Holodak > Rutgers University > > -----Original Message----- > From: Winfrey, Catherine [mailto:cwinf...@vt.edu] > Sent: Thursday, March 26, 2009 3:53 PM > To: cas-dev@lists.jasig.org > Subject: RE: [cas-dev] .Net JasigCasClient > > Could you provide a reference for " FormApplicationModule itself, as > demonstrated by Reflector, Mono[1], > and Michael Barton" so that I understand your approach a little better? Or > do you mean FormsAuthenticationModule? > > I have done some testing with HttpModules as well and agree that they are a > bit different from the ServletFilters. I have had some success with them > but thus far only with the Authentication step of the processing. I am > doing some more testing now. > > -----Original Message----- > From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] > Sent: Thursday, March 26, 2009 14:06 > To: cas-dev@lists.jasig.org > Subject: [cas-dev] .Net JasigCasClient > > Folks, > > Initially when I started the port of the Java CasClient to .Net I > assumed since HttpModules are analogous to ServetFilters that it would > be relatively straight mapping from Filters to HttpModules. However, > as I dig deeper into .Net and the HttpRequest/FormsAuthentication > lifecycle this turns out not to be so simple. For one, HttpModules > and ServletFilters are not exactly at the same level of abstraction, > HttpModules being a bit lower level (i.e. HttpSession may not be > available depending on what events have fired). The other > complication is the HttpApplication pipeline itself, which fires a > mess of events and may make multiple calls into individual Modules > which is a different behavior than Filters. > > So, I'm started to come around to the approach taking by the > FormApplicationModule itself, as demonstrated by Reflector, Mono[1], > and Michael Barton. I think we end up with one CasHttpModule that > handles two events and is configured with the Cas specific components > for handling ticket validation and setting up Context.User. > > I'd like to end up at place that has these characteristics: > 1) dead simple easy deploy (drop in dll, a few web.conf settings) > 2) excellent integration with .Net framework (Context.User, etc.) > 3) feature/quality parity with Java client (good unit tests, support > for saml, etc) > > Thoughts? > > Bill > > [1] Mono FormsAuthenticationModule: > http://www.koders.com/csharp/fid4BEDC51250B2B507391467CF38C6F5F600579CCD.asp > x > > -- > 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: wgt...@gmail.com > 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
