views:

162

answers:

3

I have a project with several separate components that all need to talk to each other. I am now trying to find a good way to share a permission system between each component.

The 3 major components are:

  1. An ASP.Net Web Application
  2. A Silverlight application (served by the web application)
  3. A Windows Service, which provides some WCF web services to the Silverlight app.

The servers(1,3) both have access to the same database. Communication between each component is performed by WCF web services.

I need to make sure that whoever is requesting information from the Windows Service(3) is a user with correct permissions to access it. The Silverlight App(2) is where the requests should be coming from. At the moment, no user information is available to the Windows Service(1) because it is completely separate from the Asp.Net App(3). I don't want to store and pass around a username and password, and the user should only have to enter their credentials once, which occurs when at the log in on the ASP.Net App(1).

What is a good way to get user identification to the Windows Service(3)?

(I'll post a possibility I see as an answer below.)

A: 

One possibility I see is passing around the session ID from the ASP.Net application for user identification.

When the Silverlight application(2) is served from Asp.Net(1), it could be passed the session ID. Then, when the Silverlight app(2) makes requests to the Windows service(3), it can pass the session ID as a paramater. The Windows service(3) can use a WCF service exposed by the Asp.Net app(1) to query the user identification for the given session ID.

Is there a potential security flaw here? It seems to me that if some one can hijack the sessionID, it will be exposed and hijackable whether or not it is passed to the Silverlight app.

grimus
+1  A: 

If it were up to me, I'd use the authentication information (the User) from the ASP login to pass around. This object is automatically passed to all the ASP.NET web pages, so it's readily available any time you need to call the Windows Service, and you should be able to easily verify the permissions.

Harper Shelby
I had considered that, but I think it would be too easy for a hijacker to simply pass the user id to the web service and pretend to be a user.Its a similar situation with the session ID, but the session ID should be occasionally changing, while the user id would stay constant.
grimus
The User object is not just a user ID - it's an in-memory object that's created on login (and probably stored in the Session, but I'd have to read up to be sure). It's at least as safe as the Session ID, and not *easily* injectable.
Harper Shelby
+1  A: 

You can secure the calls between Silverlight and ASP.NET use ASP.NET Application Services which exposes the ASP.NET authentication mechanism to Silverlight. The Silverlight app will then maintain the session information for subsequent calls to ASP.NET. In the past I've created WCF services in the ASP.NET application and used the PrincipalPermission attribute (http://msdn.microsoft.com/en-us/library/ms731200.aspx) to secure the WCF service methods with login information that was provided in Silverlight. This scenario works flawlessly and doesn't require you to create your own security mechanisms such as passing around session ID or a string that would indicate a user name (not recommended). I think this setup would also work for you between multiple servers, but I'm not sure how hosting the WCF service in a Windows Service will effect security. There might be a way to enable some form of impersonation between the two. Definitely look into ASP.NET Application Services for securing #1 and #2, and if you can manage to host your WCF Services in IIS then it would meet all your requirements with very little work required on your end.

James Cadd