Hi,
I've made a number of commits to the dotnet-casclient project over the past few weeks and I would like to get some feedback on the code (CasAuthenticationModule.cs, CasAuthentication.cs, and the ExampleWebSite which is based entirely on the CasAuthenticationModule) to help determine the best path forward. The implementation is very closely modeled after Microsoft's FormsAuthentication and FormsAuthenticationModule implementations in an effort to ensure proper integration with the ASP.NET framework. The revised version of the Forms-based module uses cookies which contain a key into the server's ticket manager. The contents of the cookie are encrypted, decrypted, and validated using the public static API exposed in the FormsAuthentication class (not to be confused with the FormsAuthenticationModule). Server-side state is provider-based (interface-driven), with a Cache provider-based implementation provided. The Cache provider is built into ASP.NET and handles threading issues and dependency or date-based expiration for free. While this implementation uses the FormsAuthentication class for cookie storage/encryption/expiration/validation functionality, it is not dependent on the FormsAuthenticationModule in any way-it works with or without the FormsAuthenticationModule installed in the pipeline. The approach taken here is a significant departure from the existing codebase. Mechanically, this is very different from the Java client implementation and the existing .NET CAS client module implementations, primarily due to the differences in how authentication is handled in ASP.NET and the lifecycle of an application & request. The changes light up many of the features in the .NET framework that are unavailable with the CasAlternateAuthModule or the previous version of the CasAuthenticationModule (URL Authorization, Membership provider support, Role-based security, User/role varied page caching, Code Access Security, etc.). I've been working very hard at minimizing the impact of my API changes with the goal of maintaining compatibility with the alternate module. However, it's becoming increasingly difficult to do that. Much of the code that was in the AbstractCasModule implementation was not compatible with the new model and in an effort to more closely align with the pattern that the Microsoft FormsAuthentication class used, a significant portion of the code was copied and pasted into a CasAuthentication class. With the exception of the some of the interfaces from the Java library (ICasPrincipal, IAssertion, ITicketValidator, IGatewayResolver, IProxyRetriever), the Exception classes, and the ticket validator implementations, and portions of the configuration class, a lot of the code exists solely to support two separate implementations that are really not very compatible in nature. I have three possible paths in mind: - Branch development and separate the modules. Since I haven't yet committed any changes that break the alternate module, I would advise that the Alternate module be treated as the last revision before my first commit. - Remove the alternate module from the trunk and focus development efforts on the Forms-based CasAuthenticationModule - Have the CasAlternateAuthModule maintainers update their code to make use of the CasAuthentication static API implementation and actively sync with API changes. Scott Holodak Aspire | A Plan for Princeton Princeton University 330 Alexander St Office of Development Princeton, NJ 08540 The Helm Building 609-258-9416 -- 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
