> I would like to see #2, assuming as Marvin stated "configuration > distills down to something trivial for folks that don't need the > authorization and advanced security features of Forms auth". If > not, #1 might be valuable.
Forms authentication doesn't play a role in any of the authorization/advanced security features per se, it just makes them possible. Forms authentication is just the MS implementation that deals with authenticating users and setting a principal up on the thread/context.User at the right point in the request processing. It also handles collecting and validating credentials via HTML. Here a partial picture of the events fired at every request: http://support.microsoft.com/kb/307985#1 1) BeginRequest (very beginning of each request) 2) AuthenticateRequest (set principal) 3) AuthorizeRequest (verify principal is authorized for resource) 4) ResolveRequestCache (check for and handle cache hits) 5) AcquireRequestState (load user's session) 6) PreRequestHandlerExecute (last chance before page exec) 7) === IHttpHandlers, WebForms pages, MVC execute here === 8) PostRequestHandlerExecute (page just executed) 9) ReleaseRequestState (save user's session) 10) UpdateRequestCache (write to cache if necessary) 11) EndRequest (request done processing) The advanced security features in ASP.NET work as a consequence of Forms or Windows Authentication _because_ the principal is set at the appropriate step. The Session-based implementations broke these features solely because AcquireRequestState(5) fires after AuthenticateRequest(2) and AuthorizeRequest(3). So in other HttpModules, every request is effectively anonymous until AcquireRequestState(5) or PreRequestHandlerExecute(6) (depending on the order the modules are installed in the pipeline). The principal wasn't set early enough. With the earlier implementations, page-level code could detect an authenticated user because Web Forms pages execute between PreRequestHandlerExecute(6) and PostRequestHandlerExecute(8), both of which fire after AcquireRequestState(5) which is where the two implementations were setting up the principal. However, other security related HttpModules (i.e. UrlAuthorizationModule) need access to that principal in the AuthenticateRequest(2) and AuthorizeRequest(3) steps. Also, ResolveRequestCache(4) couldn't have varied cached content by user/role because AcquireRequestState(5) fires right after ResolveRequestCache(4). Attempts at storing an entry in the cache varied-by-user would have silently succeeded, but the actual data store would be contaminated--all writes would have been anonymous, all reads would have been anonymous--it would be last-in, first-out for everyone. Don't quote me on this because I haven't tested it, but I believe that by having this setup in the right spot, 3rd party ASP.NET applications that don't violate the assumptions of this model should be CASified as a result of the module being installed. Scott Holodak Aspire | A Plan for Princeton Princeton University Office of Development -----Original Message----- From: Winfrey, Catherine [mailto:cwinf...@vt.edu] Sent: Friday, March 05, 2010 12:43 PM To: cas-dev@lists.jasig.org Subject: RE: [cas-dev] Feedback requested on dotnet-casclient I would like to see #2, assuming as Marvin stated "configuration distills down to something trivial for folks that don't need the authorization and advanced security features of Forms auth". If not, #1 might be valuable. -----Original Message----- From: Scott M. Holodak [mailto:sholo...@princeton.edu] Sent: Friday, March 05, 2010 12:36 To: cas-dev@lists.jasig.org Subject: RE: [cas-dev] Feedback requested on dotnet-casclient Hi Bill, Catherine, I'm a little unclear about what you are agreeing to. The wording of the quoted paragraph implies two possible outcomes: 1) We maintain both modules in the library and the alternate module maintainers follow along with the API changes 2) We discuss & flush out any outstanding reservations about adopting the Forms-based module and remove the alternate module from the trunk. -Scott Scott Holodak Aspire | A Plan for Princeton Princeton University Office of Development -----Original Message----- From: Winfrey, Catherine [mailto:cwinf...@vt.edu] Sent: Friday, March 05, 2010 12:14 PM To: cas-dev@lists.jasig.org Subject: RE: [cas-dev] Feedback requested on dotnet-casclient I agree. -----Original Message----- From: William G. Thompson, Jr. [mailto:wgt...@gmail.com] Sent: Friday, March 05, 2010 12:08 To: cas-dev@lists.jasig.org Subject: Re: [cas-dev] Feedback requested on dotnet-casclient On Fri, Mar 5, 2010 at 9:50 AM, Marvin Addison <marvin.addi...@gmail.com> wrote: [snip] >> - Have the CasAlternateAuthModule maintainers update their code >> to make use of the CasAuthentication static API implementation and actively >> sync with API changes. > > My vote is for one of the above; I will update and maintain > CasAlternateAuthModule going forward if I determine it's valuable. > The determining factor for me in whether this component has value is > whether the CasAuthenticationModule configuration distills down to > something trivial for folks that don't need the authorization and > advanced security features of Forms auth. I expect I will find this > is the case and we can simply remove it and focus on > CasAuthenticationModule going forward. +1 Bill -- 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: sholo...@princeton.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: 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: sholo...@princeton.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
