从c＃web app中的网络共享访问文件

Question

I have a web application that needs to read (and possibly write) files from a network share. I was wondering what the best way to do this would be?

I can't give the network service or aspnet accounts access to the network share. I could possibly use impersonation.

The network share and the web application are both hosted on the same domain and I can create a new user on the domain specifically for this purpose however I'm not quite sure how to join the dots between creating the filestream and specifying the credentials to use in the web application.

---

Unfortunately the drive isn't mapped as a network drive on the machine, it's only available to me as a network share so unfortunately I can't make a transparent call.

There is one problem I can think of with impersonation... I can only impersonate one user per application domain I think but I'm happy to be corrected. I may need to write this file to several different shares which means I may have to impersonate several users.

I like the idea of creating a token... if I can do that I'll be able to ask the use up front for their credentials and then dynamically apply the security and give them meaningful error messages if access is denied... I'm off to play but I'll be back with an update.

Answer 1

Given everyone already has domain accounts. Try IIS integrated authentication. You will get an ugly logon box off network but your creds should pass down to the file share.

@lomaxx
Are you saying that only you have perms to the share or that you manually mapped it to a drive letter. If the later you can use ucn \\host\\share the same way you would use ac:\\shared_folder.

Random Would it be a burden to mirror the share to a local folder on the host? I hear ROBOCOPY is pretty handy.

Another Idea. Run IIS on your target share you can read via http and if you need to write investigate webdav.

Answer 2

You do have some options and one of of those is impersonation as you mentioned. However, another one I like to use and have used in the past is a trusted service call. Let's assume for a moment that it's always much safer to limit access through IIS to ensure there are as few holes as possible. With that let's go down this road.

Build a WCF service that has a couple of entry points and the interface might look like this.

public interface IDocumentService
{
    public string BuildTrustedRelationship(string privateKey);

    public byte[] ReadFile(string token, string fileName);

    public void WriteFile(string token, string fileName, byte[] file);
}

Now, you can host this service via a Windows service very easily and so now all you need to do is on Application_start build the relationship with the service to get your token and you're off to the races. The other nice thing here is that this service is internal, trusted, and I've even hosted it on the file server before and so it's much easier to grant permissions to this operation.

Answer 3

If you can create a new AD user, I think the simplest solution is to have the Application Pool run under that AD account's authority, which would mean your application is now running as the AD user. You would need to add the AD user to the IIS Worker Process Group on the machine running your application. Then as long as your AD user has write permissions on the network share, you should be able to use the UNC path in your file operations.

Answer 4

I've had no problems connecting to network shares transparently as if they were local drives. The only issue you may have is what you mentioned: having the aspnet account gain access to the share. Impersonation is probably the best way to do this.

You should be able to use any filestream objects to access the network share as long as it has a drive letter on the server machine.

Answer 5

Impersonation worked well for me in this scenario. We had a wizard that uploaded a zip file through the website, but we load balanced the site. Therefore needed to setup a way to save the file on all the machines.

There are many different ways to do it. We decided to make all requests to run under the user we setup and just added the web.config entry and setup the security permissions on the folders for the user. This kb article explains the setup very well.