Staff
775
Views
9
Comments
How to: Setting up Application's access to file systems

Hello

 
Let me share with you some concerns and how-tos regarding giving privileges over file system resources to OutSystems applications.
 
Suppose you which to have an OutSystems Application to access, without restrictions, to a specific local or remote folder. Since there are differences when dealing with remote folder locations, I’ll present different approaches for this task, depending on the requirements:
 
 
  1. Access to Local Folders only: if your OutSystems Application requires to access local folders only, for reading and writing files, then grant all necessary permissions over that folder to the local group IIS_WPG (Windows 2003) or IIS_IUSRS (Windows Vista, 2008 and 7). This group includes the default users that run the OutSystems Applications, and thus access the files on that local folder. No additional user is required, but it would allow all applications to access the folder. If you want only a specific user to access that local folder, then just add your local user to the local IIS_WPG or IIS_IUSRS group, and grant the permissions  over the file system resource just to the local user instead of the group
  2. Access to a Remote Folder only: if your applications try to access files, reading and writing, on a remote server (like a network share folder), then you need to have the same user credential to run your application and access the remote folder. There are two ways of doing this:
o    by using a domain user, recognized by both servers, and then add that domain user to your local IIS_WPG or IIS_IUSRS group on the OutSystems server, and grant necessary file permissions over the folder of the remote server to the domain user.
o    by using a local user on both servers, which have the same username and password (being like the same user in different servers, but with the same credentials), and again add the local user to your local IIS_WPG or IIS_IUSRS group on the OutSystems server, and grant necessary file permissions over the folder of the remote server for the local user created on that server
  1. Access to a local and remote folder: this is basically a combination of the two above, where you should add your user (either local or domain) to the local IIS_WPG or IIS_IUSRS group on the OutSystems Server, and grant the necessary file permissions (reading and/or writing) over the local folder to the IIS_WPG or IIS_IUSRS group, and the remote folder to the user (either local or domain)
 
 
If you created a new user, depending on the chosen scenario above, all you need now is to configure your application to run under its credentials. You can do this by:
 
 
  • Accessing the OutSystems Service Center on the OutSystems Server (either through remote or local browser using https://<serveraddress>/ServiceCenter, or locally using the Start Menu -> Programs -> OutSystems -> Service Center). Login using an administrative user and access the Factory section. In the espace list page, press over the espace that you want to access the applications and you’ll jump the its details page.
  • Under the Operation tab, you’ll find input boxes for Run As settings. Just type in the local or domain user and password and press ‘Apply runas Settings’. Your application will now run under the chosen user credentials.
 
 
The OutSystems Applications run under the IIS, and thus, by the IIS worker process, which by default is executed by the local NETWORK SERVICE, and by default all espace applications run within this worker process under the IUSR_<machinename> user (IIS 6) or an Application Pool Identity (IIS 7+), which is the default local ASP.NET runtime user or identity specifically created by the .NET Framework to execute .NET web applications. This user belongs to the local IIS_WPG (Windows 2003) or IIS_IUSRS (Windows Vista, 2008 and 7) group, allowing the load web applications. This is the key to have other users to load web applications: just add them to the correct local group.
 
 
 
Hope this information is helpful.
 
Cheers
 
Miguel Simões João
Hello Miguel,

I've read this post many times and every time I read the post it becomes more clear. However, if everything was clear I didn't need to post :).

So some points and questions, hope you can answer them.

First of all, if you're using the 'run as' setting for an eSpace with a domain user, the username that needs to be used in the 'run as' username box will be: 'domain\user'.

Having found the above problem (which was really frustating to find out :) ) and applied I come to my problem:

So I've set user 'abc' as the application account. When I create a file on the fileSystem in a folder (where user 'abc' has modify rights) the owner of the file is Network Service. So not the user that I've set in the run as property. When I take a look, the eSpace is in an application pool where the identity is set as Network Service (which was set by default). So who (application pool or application itself)  is the one that the determinates the user to write the file to the fileSystem?  When I change the application pool idenity to user 'abc' the owner of the file is 'abc' (like it should be).

I think I'm to deep in this and I don't know enough of it to say that is how it works, so I hope you can answer this.


Some other questions:

I've 2 eSapces (A and B). A is user provider and has an (public) action that writes the file to the filesytem, B uses the public action of A to write a file to the fileSystem. If a file uploaded in eSpace B is written to the fileSystem (by the public action in A), who is the user that writes the file on the fileSytem? A or B?

How about security? When a visitor of the application comes in, the user is set as an IIS user. So does this also means that user has the same privileges as the application (so if we got a really smart user he can acces the filesystems since these rights are set by the IIS?) Maybe it's a stupid question, but i was wondering this for a time now, so also hope you can make this clear also.

Is somebody else know the answer thats also fine by me :).

Kind regards,
Evert
Hi Evert,

The web request is run with the credentials set in the consumer eSpace.
If your issue is file system access I believe you can use the Network FileSystem component to explicitly set the credentials (instead of using the Run As)

Cheers,
Tiago Simões
Hello Tiago,

I shall test that situation today cause I was already using the network filesystem and the credentials didn't worked (the files created by the network filesystem extension had Network Service set as owner of the file).

So I'll hope you right ;).

Kind regards,
Evert
Hello Tiego,

Just run some tests with creating a file on the filesystem of the server and look who the owner of the file is.

1) Using the network filesystem extension doesn't set the user (defined in the write_binary action) as the owner, the default user (application pool) is set.

2) Setting the user as the application user (under the operation tab in servicecenter) makes that user the owner of the file (only works when the write_binary action is called by that eSpace (see number 3).

3) When using the action (trough a public action) in a consumer eSpace (the A-B story in my earlier post), doesn't make that user the owner of the file, the default user (application pool) is set as owner.


So number 1 means the network filesystem extention isn't working correctly (It would be nice to see that OS adapt that extention and make the improvements on it since is a very commenly used extension and the owner isn´t responding to post on it).

Number 2 is as expected.

Number 3 is a bit specific and not like I would expect.

About number 3: Even when I´ve set the user in the consuming eSpace (in the operation tab in service center) then the file is still made by the default user (application pool). So how can the right user been set when having to use a public action (since the write_binary action is included in a 'generic' action in another eSpace).

Hope you know how this problem can be solved.

Kind regards,
Evert
Hi,

It's still not working like it should be with the user set in the operation tab. An action (which is executed by a timer) was giving an error last night. Tested some things but it writes the file with the application pool account (network service) and not the account which is set in the operation screen.

Even tested if it makes a difference that the action was called by a timer or action in a screen but the logic stayed the same.

Kind regards,
Evert
Hello, I have an Outsystems Web Application and I gave it permissions to (service center-> eSpaceoperations) run as "Adminstrator" and also "IIS_IUSR"  (a user I created) but those credentials are not passed to the user that logs on the application.

For example I have a shared folder with images, the web application can acess those since it has the right credentials but the user cannot see the images!! It always ask for credentials in windows server 2008 R2 for each image to show!

How can I make my user have the same privileges has the application? Because I want to allow user that log on to the application full acess to those shared folders. I also choose "turn on sharing so anyone with network access can read and write files in the public folders‏" to see if it stopped asking for credentials, but with no luck.

Any ideias, please help... Thank you
Actually the web application can't pass the credentials with the "run as" in (service center-> eSpaceoperations).

I have "solved" this by simple editing the security permissions of the folder and adding Authenticated Users Group.

But now it allows everyone to access the folder. And I wanted only the application through the "run as" to access.

Any ideia how to make this.

Thanks


Hello Pedro,

Would it be possible to run the application in another application pool and set those application user to another user.

Kind regards,
Evert

Good evening,

but the configuration regarding the domain user to add to the IIS_IUSR group, has to be made in frontend server or in application server?


Thanks


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.