We currently have an HTTP Module in our assorted web (mostly web forms) applications that handles authentication, page access, and menu construction. We are trying to introduce SSO, but are finding that we cannot predict the order in which modules (or their events) execute. As a result, the Request Header values that SSO populates (such as username)http are often populated after our Security module initially executes.
I would hate to move the code to the master pages. Or, I guess more accurately, into a class called by the master pages, but I don't see another reasonable option. I need something that fires AFTER SSO does its thing.
I am looking for an alternative to using a module. Something that still provides a generally centralized passthrough/hub for controlling traffic. The only thing I have been able to come up with is a master page call, which does not let me manage non-aspx resources, but it may be the best I can do.
I was trying to solve the wrong problem. I was trying to make the current Security HTTPModule work in conjunction with SSO (Siteminder). The problem was that the existing code was designed at a time that it was both the authenticator of user identity and the authorizer of resource requests based on that identity. Not that we are giving up that first role, we have to move our authorization code into the appropriate event -- after SSO has set the request values -- PostAcquireRequestState. Placing the authorization code there solves all of our problems. To misquote the Bard, the fault is not in the code, but in ourselves.