[SOLVED] pre-authenticate user in aspx application

So there's several ways I can think of to do this, depending on your current intent for both applications and reasons for doing what you're doing. I'll try and list each here with some pro's and cons. I'll say again that none are what I'd consider easy for a new web developer; are there others on your team that have experience in one or both technologies?

1) Probably the simplest option, if you can do it is to have the Node.js process be the gateway. The ASP.NET application never needs to authenticate the users at all, the Node.js app acts as a full-on reverse proxy to the ASP.NET app. This works well if you can support it, and you can secure it by having the Node.js application login to the ASP.Net app (via whatever method you want; basic auth, forms login, whatever). If you need the ASP.Net app to be aware of what user is in the current context, then you can push whatever info you need into the request headers to do so (e.g. if they share the same database, you coudl put in the Id of the user that the node app has authenticated). If you wanted the ASP.NET app to be accessible on its own as well as via the node app, then the node app becomes one of many users and the asp.net app needs a HTTP Module to normalize whether the user info is coming from Session or from the Http headers. The easiest way to do this is to have the Http Module check that the current user is of a given role (e.g. NodeApp) and is logged in, and then it either copies the user information from the HttpContext into a new Session variable (that the rest of the app uses), or else looks up the proxied user in the DB and does the same. Basically, the rest of the app will never trust the HttpContext's current user for making decisions at that point.

Pro's: reasonably simple architecture, does not depend on what domain each app is on. Both apps need access to the user DB for it to work well.

Con's: If for some reason the apps can't have access to the same user db it isn't as good. There's some overhead for doing the proxy (not much, but still there). There's a bit of brain bending around whether you're talking about the 'real' user or the 'node' user that you have to keep straight.

2) OAuth (or alternatively OpenID) is the most standards-compliant option. In this case, you'd setup the Node.js app as an OAuth provider and have the ASP.NET app be an OAuth consumer. The user can then use their Node username and password to login, and have the Node app pass an auth token to the ASP.NET app via existing authentication modules.

Pro's: Less code to write on the ASP.NET side than the above example, standards compliant. you could switch out (or add) OAuth providers if you wanted to later

Con's: A bit more indirection for the user (redirects between the apps). This can probably be minimized, but you'll need to be very familiar with the OAuth protocols.

3) Session sharing (considered session hijacking if someone else is doing it to you. . . ). If you're on the same domain, then the Node.js app can simply write out the ASP.NET session and auth cookies like ASP.NET would. I say 'simply', but there's a lot of details of the ASP.NET machinery that you'll need to understand to do it right. http://support.microsoft.com/kb/910443 . The main bits are that you'd need to put your ASP.NET Session Store in a database, and then have Node.js manage the addition and removal of elements from there so that when ASP.NET goes looking at the session & auth cookies on a given request, it can find them in the place it expects to find them and then the ASP.NET process would find them there and act accordingly.

Pro's: Uses the ASP.NEt machinery that's already in place to some degree Con's: Probably pretty fragile, all things considered. Your node.js app would need access to the machineKey that the ASP.NEt app is going to use to decrypt the session contents. You'll need to make sure you're using the same encryption algorithm and both apps would be coupled to the same session store.

4) Roll your own membership provider in ASP.NET to issue a Forms Auth ticket to the Node app. This is somewhat similar to a blend of 1 and 3. In this option, the Node app, after authenticating the user, would send another request to a Login endpoint on the ASP.Net server, providing it credentials identifying itself however you want (e.g. a shared key that's been encrypted in some way). It could also provide any user details you want. You could then manually call the Forms Authentication api in your ASP.NET code to create a ticket for the end user (http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket.aspx) i.e. no calculating it yourself; session store can be anywhere. The response to the Node.js app will include the ticket data in the auth cookie and so your Node.js app can pipe that data back to your user, so that the next time they make a request to the ASP.nEt app, they'll have a valid auth cookie generated by asp.net.

Pro's: More flexible than #3 and less user mungery than #1 from the ASP.NET perspective. Con's: Still requires both apps on the same domain, still requires a lot of integration between the two. If you screw up your Membership provider you could accidentally create a hole in your security.

Overall, I think the OAuth solution is the best one, but those are all the methods I can think of to do it.