I’ve got an MVC 2 application which won’t be doing its own authentication, but will retrieve a user ID from the HTTP request header, since users must pass through a gateway before reaching the application.
Once in the app, we need to match up the user ID to information in a “users” table, which contains some security details the application makes use of.
I’m familiar with setting up custom membership and roles providers in ASP.NET, but this feels so different, since the user never should see a login page once past the gateway application.
Questions:
- How do I persist the user ID, if at all? It starts out in the request header, but do I have to put it in a cookie? How about SessionState?
- Where/when do I get this information? The master page shows the user’s name, so it should be available everywhere.
I’d like to still use the [Authorize(Roles="...")] tag in my controller if possible.
We have a very similar setup where I work. As @Mystere Man mentioned, there are risks with this setup, but if the whole infrastructure is setup and running correctly, we have found it to be a secure setup (we do care about security). One thing to ensure, is that the SiteMinder agent is running on the IIS node you’re trying to secure, as it will validate an encrypted SMSESSION key also passed in the headers, which will make the requests secure (it would be extremely difficult to spoof the value of the SMSESSION header).
We are using ASP.NET MVC3, which has global action filters, which is what we’re using. But with MVC2, you could create a normal, controller level action filter that could be applied to a base controller class so that all of your controllers/actions will be secured.
We have created a custom configuration section that allows us to turn this security filter on and off via web.config. If it’s turned off, our configuration section has properties that will allow you to “impersonate” a given user with given roles for testing and debugging purposes. This configuration section also allows us to store the values of the header keys we’re looking for in config as well, in case the vendor ever changes the header key names on us.
So our web.config looks something like this
We have a custom SiteMinderIdentity…
And a custom SiteMinderPrincipal…
And we populate
HttpContext.Current.UserandThread.CurrentPrincipalwith an instance ofSiteMinderPrincipalthat we build up based on information that we pull from the request headers in our action filter…MyAppis a static class that gets initialized at application startup that caches the configuration information so we’re not reading it from web.config on every request…From what I gather of your situation, you have information in a database that you’ll need to lookup based on the information in the headers to get everything you need, so this won’t be exactly what you need, but it seems like it should at least get you started.
Hope this helps.