***Note from Migration:***
Original Title was: Run FME Job using active directory account of user (not windows service logOn user)
I was chatting with a customer and they said they'd love to be able to let their users run scripts that access data and directories they are already entitled to using the Active Directory account.
Currently, the jobs all run as the single account specified as the Log On user for the FME Engine windows service). That account needs permission to access ANY data that might be processed by ANY job on FME Server.
I'd prefer if the jobs ran as the user that creates them.
An alternate solution could be a "Run as" option on a job, so that different service accounts can be used. The current solution of granting the account that is running FME Engine Services to every resource each job requires is a huge security risk.
This would be a really convenient feature. Now I need to remind everyone to grant privileges in the database and provide access on shares to the service user as well.
Some colleagues are not too keen on it as others can accidentally access/manipulate data.
We either request additional "password never expire" logins or the user agrees to update the password of the named connection when they change. And accepts that they are locked out if workspaces try to use the old credentials 3 times consecutively.
With dynamic engines it would be especially useful if workspaces/repositories/.../apps could be assigned to queues which are picked up by by engine run as a specific user.
From a security standpoint, this is a very important feature to avoid users exploiting the (very often) massive rights granted to the service user in cross-departemental installations.
I personally did not see how this could be achieved (on windows). But we have some customers who heavily rely on 'file-based data-storage' and e.g. 'sde-files'. They have severe security concerns with the current 'service-user rights used' implementation and would really embrace this idea.
Of course this is something only valid for implementations where files are the main data-source / target, so the useraccount of the process, is the means of authorization to the data-source and -target. This rather old-school situation is still very common, as the shift to data-storage for which FME can use 'connections' has only started for many organisations.
At first glance it sort of feels like designing better gas-stations, while we are moving towards full electric mobility, but it might still be a necessity. Many FME developers are not in the position to change the data-storage implementations at the organisation they work for, but still need to comply to ever stricter security protocols.
Martin
I just wanted to post a similar idea. Interestingly, my usecase is different. I was thinking about using the credentials of a user that is authenticated on FME Server (in order to run a workspace (app)), for the transformers in the workspace. In particular for the authentication parameters of an HTTPCaller, so that API requests/commits could be made in name of the user that started the workspace.
It seems that if this idea would be picked up, this can be achieved by using the 'Single Sign On' option for the Authentication parameter of the HTTPCaller.
To currently achieve this I feel there are two options
However, I do have some concerns with both of these options (altough I think the second option is most secure)
1. When inspecting the job in the GUI of FME Server, the value for the password parameter is shown as three stars (under the 'Request Data' group), and this is also the case in the job log. So far, all good.
However, using the REST API of FME Server, it is still possible to fetch the parameter values used in the job (from the GET call with end node '/transformations/jobs/completed'). From there you can fetch the actual stored value of 'fme_decrypt(<HASH>)'. Then I believe anyone using (the same version?) of FME can easily decrypt this password by opening up Workbench, adding an attributecreator, and creating some new attribute with this 'fme_decrypt(<HASH>)' for its value.
Then the short answer could be to make sure that also from the REST API of FME Server it is not possible to get the password parameters value in the form of 'fme_decrypt(<HASH>)'. But even then it would still be possible for any FME Server author to alter the workspace slightly (and reupload to FME Server). If you connect the password parameter to e.g. a ParameterFetcher and then add a Logger, you would still be able to log the decrypted passwords in plain text.
2. The main concern for this method is that an FME Server Author/Admin would need to manually upload web connections to FME Server for each user that needs to be able to run the workspace (probably together with the end user as they are often no FME users).
Also, this would allow an FME Server admin to also be able to use these user Web Connections in other workspaces, since the FME Server admin can provide himself access over all Web Connections that are stored on FME Server (from the FME Server GUI, Admin, User Management, Items, Connections)...
The other thing is that when using workspace apps on FME Server, you would probably need to make some kind of choice parameter to choose which users web connection should be used in the workspace. As a result this would allow users to choose another users Web Connection.
This latter issue is sort of specific to workspace apps, because they are being run in name of the user that created the workspace app, also when the option 'Require authentication' is checked to only allow specific user (roles) to run the workspace (which came as a bit of a suprise for me).
In case the workspace is run by a dedicated user (e.g. run directly from the GUI of FME Server), it seems to be possible to automatically link the (correct) users Web Connection, by relating it to the FME Server parameter 'FME_SECURITY_USER'.
Curious to hear other people's thoughts on this,
Thijs