Can I build a .net web service that allows anonymous access but impersonates user privilages based on userid?

Question

I have a web application on an IBM WAS server (Windows).

In the WAS app users are able to browse files on a different server. This functionality connects to a web service in order to retrieve a listing of files from a network path.

The web service is built with .net and resides on a separate server which is in the same domain as the file server.

The WAS app service request sends the user's id as part of the call.

Is there a way to take the user's id that is passed to the web service and restrict that user to only the files/folders they have access to based on Windows Security?

From what I know this is not possible unless the WAS app is able to send the request to the web service as the logged in user.

So, my second question is, is it possible to pass Windows user credentials from a WAS application to a web service?

I'm not too familiar with Windows Authentication and impersonation and I know even less about WAS and how it handles security so I'm hoping to find out if this is possible and where I might get started.

Answer 1

Here is a link to understand Anonymous Access and Impersonation with .NET : Anonymous Access and Impersonation

Answer 2

No. You can create an identity token, but for access check you would need an impersonation token and such a token can only be created by presenting the password or by delegation from an account trusted for delegation that in turn was presented the password (or sufficient proof to trust that the original identity posses the password, ie. the AD vouched for him).

What you need to do is have the WAS server impersonate the caller and then call your service under impersonation. The account running WAS would have to be configured to allow constrained delegation.

Answer 3

Assuming you have an Active Directory setup, the only way I can think of for the WAS server to send along the credentials of the user accessing it is if the DC recognizes the WAS service (I.E. the account running your WAS application) for delegation. We ran into this problem (somewhat) here. We use an AD account to run our IIS application pools, and then that AD account needs to be able to verify users against AD and connect to SQL server.

The fix for us was to register service process names (SPN's) for user running the IIS application pool. This allows the user account to authenticate users against AD since AD will recognize it as a service. Then you can follow traditional .NET impersonation rules to pass the credentials along. I'm sorry I can't provide more specific information, but I hope this at least points you in the right direction.

See: http://technet.microsoft.com/en-us/library/cc773257.aspx