Question

I have a legacy asp.net app that is using forms authentication. I'm making changes so that in certain scenarios, it will bounce a user over to our ADFS server to get a token. This is all working fine, and ADFS sends me back to the application with a valid token.

Now, this app is old enough that it's not using the built-in identity stuff, much less claimsidentity, so when I get a valid token and arrive back in my relying party, IsAuthenticated is true, and I have a valid ClaimsIdentity, but of course, my current code never looks at that stuff anyway. The ROI for reworking the entire app to use the Thread.CurrentPrincipal is prohibitively poor, so instead I've got to grab the Thread.CurrentPrincipal for these users when they come back from ADFS and set up the legacy/proprietary/old user/identity classes that this app runs on. My question is exactly where/when to do that?

My first thought was to do it in one of the event handlers in global.asax page, possibly in Application_BeginRequest() or Application_AuthenticateRequest(), but that's just a guess. There, I was thinking I could check if Thread.CurrentPrincipal is authenticated, and if my session user has been configured. if not, I could go ahead and set it up. I'm not positive, if this is the right approach, or if it is, which of those two methods makes the best spot since I'm not sure about exactly when each one is called.

Was it helpful?

Solution

Either is probably suitable. Application_BeginRequest fires for EVERY request, where Application_AuthenticateRequest may only fire for requests that require authentication, accoridng to your Web.config settings.

If you're serving very many requests that don't require authentication, it may be more efficient to do it in Application_AuthenticateRequest. There's not really a norm here, because you're working outside the system, and the assumption is that whatever you do would be a temporary measure.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top