I tagged this as Milestone 1 (JCC-1-0-0-M1). http://developer.jasig.org/source/browse/jasigsvn/sandbox/JasigCasClient/tags/JCC-1-0-0-M1
Bill On Sun, Mar 29, 2009 at 12:14 AM, William G. Thompson, Jr. <[email protected]> wrote: > Folks, > > OK. After regrouping and going after a more .Net approach, the > current sandbox builds and authenticates against CAS 1.0 protocol. > The sample web app in the project can be configured (web.conf) to > point to a CAS server of your choosing so you can quickly test it out > and step through the client code. There is still much to do, and > we're a long way off of anyone putting this into production...but we > may have a decent path now. > > http://developer.jasig.org/source/browse/jasigsvn/sandbox/JasigCasClient > > I tried to simplify things a bit and cut down on the abstract layers > in the Java version. We may need to add them back in as the protocol > support grows, but I'd rather start simple and get it working. The > key parts to look at if you are interested are: > > JasigCasClient.CasAuthenticationModule - this is the main client class > and the only HttpModule > > JasigCasClient.Security > ICasPrincipal > CasPrincipal > IAssertion > Assertion > > JasigCasClient.Validation > ITicketValidator > AbstractUrlTicketValidator > Cas10TicketValidator > > Still left to do: > * CAS 2.0 and proxy tickets > * Unit tests, unit tests, unit tests > * A good set of .Net FormAuthN integration tests > * SAML > ... > > We might need to start thinking about a JIRA instance. > > Cheers, > Bill > > On Thu, Mar 26, 2009 at 2:05 PM, William G. Thompson, Jr. > <[email protected]> wrote: >> 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.aspx >> > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
