views:

162

answers:

1

I have an un-ideal application and without going into the ins and outs this is what is needed.

A 3rd party app needs to make a request to a page which will return data. Because I have Forms Authentication enabled this request always ends up being sent to the login page. I have therefore set it so that all users can see this page even though they are not logged in. What I want to do in the Page Load or similar is to check querystring parameters which the 3rd party app can send and validate it against FormsAuthentication.

When this 3rd party app makes its request a user has already logged on so I was wondering is it possible that I can check something against the currently logged in user to see if it matches the 3rd party request?

What I need to also do is send that information from the logged in user to the 3rd party app so that when it makes its request it matches up with the logged in user.

A: 

I may get down votes for this, but I'm going to answer anyway because if one of my co-workers asked me this question, I would read them the riot act. (I won't read you the riot act because I'm not responsible for your systems or the security of your data.)

I see from your first sentence that you realize this may not be the best idea because it is an "un-ideal" application.

I know that what I'm about to suggest will result in duplicate code and add to maintenance down the road, but when you balance that against short-circuiting the authentication mechanism or tampering with a well-known and trustworthy mechanism to weaken it so as to allow another application to use a "back door" (which is what you're really talking about doing here - creating a back door for this other application but attempting to use querystring parameters as part of the login mechanism) it is really the lesser of two evils to have more code and more to maintain.

So... Have you considered, and is it a possibility for you to set up another method for this other app to get the data? You say that it is just getting data, so why not have a separate web services project or some other project appropriate. Even another web site application would be a better solution to what you're proposing.

Even if this data is not what you would call "Sensitive" I still think trying to build in a back door is a bad idea. It may not be a critical issue on the current application, but not coding for security is a habit, and once you do it in one area, you're more likely to take unnecessary risks elsewhere.

David Stratton
I completely agree so don't get me started. Maybe I will not change any authentication approach and use a public/private key scenario. A public key is sent via URL and then a private key in the page is used and then do some magic and if they tie up the request is allowed else they are sent to an unauthorized page. However I have no idea how to do this public/private key stuff and is the public key generated each time?
Jon