views:

183

answers:

1

I'm building a web site that will acts as a client to a persistant server process. ASP.NET will communicate with the server using .NET Remoting. The server is used by other clients as well (thick WPF clients and automated processes) and already has methods for password based authentication, authorization and sessions. The way I intend to build this is to require an ASP.NET session for all pages, and keep a remoted object in the server side session state that corresponds to a session in the backend server. I'll build a login page that passes on the credentials to the remoted session object which will keep track of the authentication status of the session. I hope all that made sense. Two questions:

  • Is it safe to rely only on the ASP.NET session to ensure that a request is authenticated, or do I need to add some authentication cookie on top of this as well? The site will contain sensitive material and all pages will require HTTPS, so the session key should not be possible to pick up by a third party (at least not more so than an authentication cookie).

  • How do I incorporate this with the ASP.NET authentication infrastructure? In specific, I want the HttpRequest.IsAuthenticated to be true if the server thinks that the session is authenticated and the Page.User principal to describe the currently authenticated user, again as seen from the server.

Thanks

+1  A: 

The ASP.Net Forms Authentication will do everything you need.

First off, it takes care of setting a secure authentication cookie for you, so you don't need to worry about that. It is as safe as any other session-based authentication token (in other words, it's open to session hijacking, but otherwise considered safe), but since you're using HTTPS, session hijacking cannot be performed, so you're safe all around.

HttpRequest.IsAuthenticated will be true when the FormsAuthentication is successfully performed. You'll likely need to write a custom MembershipProvider that will authenticate against your user store, fetch the user name and the back-end session object, and store them to session when the authentication succeeds. Writing a custom provider is very simple, there are lots of great examples that should cover what you need.

Here's a basic example.

womp