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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
