Hi,
I dropped by about a year and a half ago while working at Rutgers to pitch in some feedback (but no code) for a .NET CAS client implementation. I recently began working at Princeton University under Bill Thompson and CAS is back on my radar. I've been reviewing the 2 .NET CAS clients included in the DotNetCasClient library (CasAuthenticationModule and CasAlternateAuthenticationModule) and have some significant changes to contribute. The problem is that as I work at this, it ends up deviating more and more from the original codebase-I find myself needing to change method/class visibility and/or interface definitions in order to get things working. It's beginning to feel like either I should be copying code over to another library or significantly altering the API in the existing library. There is a lot of code in this library that I don't want to re-invent (ticket validators, configuration, protocol-specific classes, etc.), but I'm not sure how you'd want me to proceed with this. Also, I'd like the code to more closely align with the .NET framework authentication providers. My implementation is based on the CasAuthenticationModule. I found a few problems with it and a few ways to improve it. The biggest problem that I'm seeing in both of the implementations is that they are attempting to perform authentication too late in the event processing pipeline(in the AcquireRequestState event handler). This event fires after AuthenticateRequest, AuthorizeRequest, and ResolveRequestCache. This causes problems with Url Authorization (i.e., location elements in web.config), role based security, etc. which execute during the AuthorizeRequest. Possibly a bigger concern is that Caching of pages or content that require authorization can't function properly-in the worst case allowing users to see data that was retrieved by another user. If you aren't using caching, this wouldn't be a concern, but if you are-or if your site could use the performance boost, this is a deal breaker. The reason both implementations attached to AcquireRequestState is that they made use of the ASP.NET Session provider (typically implying server-side storage). By moving the ticket storage into a client-side cookie, all ticket validation can be handled in the AuthenticateRequest handler (cookies are available from the beginning of the request--BeginRequest). By using the static helper methods in the FormsAuthentication class, that cookie is encrypted, has sliding expiration support, and works with the .NET LoginStatus, LoginView, etc. controls. URL authorization, role providers, code access security, caching of protected content, etc. become possible safely. In order to implement SingleSignOut, the server needs the ability to keep track of tickets (either outstanding tickets or revoked tickets). I opted to track outstanding tickets using the ASP.NET cache provider to handle the sliding expiration. This opens the door to a couple of pretty powerful new possible [optional] features. For instance, guaranteed tamper proof ticket validation--even if the server key is compromised (including identifying the fact that the key is compromised), restricting users to 1 active login regardless of geographic location (i.e., if you log in here, the other person who logged in with your credentials down the hall just got logged out), administrative ability to 'kick' users off (invalidating their ticket) and even to prevent them from logging back on for a certain duration of time (or until the web server and/or ASP.NET application is restarted). How should I contribute this--as a new library, as a modified version of the original library? Any questions/concerns/comments? 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 [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
