1

For a web app, the client side is javascript in the browser. The server side is ASP.NET with a REST API. At present there is a single server but we plan to scale out with a server each in the US, UK, and AUS (on Azure). We'll have redis (but that does not sync up instantaneously). They will (almost) always be using SSL.

When a user logs in, we authenticate them. It's easy to pass back the primary key of that user record in the DB and on subsequent calls in, pass that PK to identify the user. It's also trivially easy to then impersonate any user.

What's the best way to implement this? The two things I have thought of are:

  1. Return a guid and require that guid on all subsequent calls.
  2. Store the PK in the Session data on the server side and use that to identify the user on all subsequent calls.

Both of the above work if an existing session continues to go to the same server (which I believe it does) for each subsequent request.

So, what's the best way to do this? Either of the above two? Or is there another approach that's better?

thanks - dave

closed as off-topic by Xander, schroeder, Jens Erat, TildalWave, RoraΖ Jan 21 '15 at 12:00

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – Xander, schroeder, Jens Erat
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Isn't sessionID used for this very thing? You have a table to match the ever-changing sessionID with the user ID. – schroeder Jan 20 '15 at 22:01
  • @schroeder - That's what store it in the Session is. The sessionID in ASP.NET is used to tie to a Session dataset you can put stuff in. – David Thielen Jan 20 '15 at 22:03
  • Why not just use the built in .NET membership sessionID? You don't even have to worry about sending it back. Once they are authenticated .NET manages it for you. And how is it trivially easy to impersonate any user? How would you ever see someone else's key without breaking SSL? – TTT Jan 20 '15 at 22:06
  • @TTT That is my option #2 above. Is that a good way to handle this even when scaled out? – David Thielen Jan 20 '15 at 23:42
0

In ASP.NET you can keep the session in a data store instead of in memory, this is useful for load balanced deployments. The session can be kept in SQL and I have also found an example of using Redis to store it so retrieval is faster.

So in your case I would use ASP.NET authentication and then use the session to keep the primary key you mentioned in order to recognize the user.

Not the answer you're looking for? Browse other questions tagged or ask your own question.