ArcGIS Server Override credentials in Geoprocessing Service.

Question

I have created a GP tool in python and decided to publish it as a GeoProcessing service in ArcGIS Server.

The GP Service permissions are set to: Public, available for everyone

This GP service receives a JSON string as Input, in it a credential to access the Geodatabase are set.

It is intended that the GP service creates a Geodatabase connection file, access a table (set with Editor Tracking capabilities) and modify a row.

It is expected the user name defined in the passed credentials appears in the Editor tracking field, instead appears ESRI_Anonymous

I created a user (my_user_server) and a role in ArcGIS Server, set the permisions of the GP Service to: Private, available only to selected users, and select the created role.

It is expected the user name defined in the passed credentials appears in the Editor tracking field, instead appears my_user_server

I found this documentation

It states that the behavior applies for Feature services. do not mention GP Services.

In my ideal world I would like to keep the GP service public, and have the Editor tracking field with the user name provided in the input JSON.

is that possible?

RogerDunnGIS · Answer

I'll try to address the issues in your last post, but you may end up having to make an Esri Support ticket or hiring professional services.  I think the fundamental issue at hand is that you want to use database-level permissions to modify through GIS, but you have to consider Esri-level permissions, too.  I'm no authority on the matter; just another user contributing to the forums.

The shadow accounts, as you call them, are going to be necessary because of the Esri licensing model.  Esri's user types and roles dictate what a user can do.  Not all account types can modify GIS assets.  It's Esri's licensing model that describes these permissions which, are disconnected from the user's database permissions.  When the logged-in user runs the geoprocessing task, it marks the changes in the feature class using their Esri account name, even though the task is connecting to the database with different credentials.  The user name and password for an Esri account should never match a user name and password of a database account.  These are two different levels, understand: database and service.

A public service that modifies features is a crowdsourced model.  The user can be anybody.  If you're going to crowdsource, then you make a GP public and the changes are marked as Esri_anonymous, as you saw.  This falls within Esri's licensing model, if I'm not mistaken.  Such things like Survey-123 can work that way.

Now, a DB admin can make as many database accounts as they want to and make them for free.  The admin might allow lots of users permissions across tables, fields, schemas, and the kinds of statement they can run.  And this might even all be for free.  But when you're going through Esri, you need paid accounts for the users to make those same changes.

Bottom line: If public geoprocessing tasks only allowed employees of an Esri customer to make GIS changes via one Esri account, then the customer will have broken the software license agreement with Esri.  I think.

Cristian_Galindo · Answer

Thanks for your answer.

I read it several times, and understand your security concerns, but I would invite you to this scenario, where a provided tool behaves different upon the environment:

If I execute my current tool, as a tool (python script) and give him the parameters defined (they include the GeoDB credentials for DBUserA), the tool perform the changes in the features classes, and the  changes are registered under the credentials (DBUserA) provided (As Editor tracking functionality promises to work).

If I export the tool as a public  GPService, and  execute the GP service and give him the parameters defined (they include the GeoDB credentials for DBUserA), the tool perform the changes in the features classes, and the  changes are registered under the credentials (ESRI_Anonymous).

If I export the tool as a protected GPService, and  execute the GP service under the Portal Credentials (PortalUserA) and give him the parameters defined (they include the GeoDB credentials for DBUserA), the tool perform the changes in the features classes, and the  changes are registered under the credentials (PortalUserA).

Now, My use case state that a Company has one Portal, and several GeoDBs, moreover the users of each GeoDB are different, and the users have access to their GeoDB's.

This tool provides a functionality that fits all GeoDB's therefore it is published for all the company. So far the users already manage a credential to access the GeoDB, and what they can do on the Geo DB. From my point of view the administrative burden to have shadows accounts in the Portal is way to high, moreover it will generate each user to require another credential to remember and to protect.

The danger here is publishing a public service which allows users to attempt guessing the administrator user names and passwords to your database so that they can gain secured information. What prevents a user of your GP service from passing in a JSON object containing the database "sa" (server administrator) user name and attempting a bunch of passwords?

If  Those shadow accounts in Portal are created and the GP Service is secured, the risk mentioned by you is still there: users are going to be able to attempt guessing the administrator user names and passwords to the GeoDB

It's better to leave it to ArcGIS Server/Portal to require the token which comes from server-level security instead of database-level security.

So, server-level security is not going to help in this use case.

But the documentation addresses that, too: "Tracking who made edits and when the edits were applied can help you enforce accountability and quality control of the features you add to your geodatabase."  So, while your goal is noble, it does circumvent the very purpose of user editing tracking in the first place.  I understand that you'll only let the user run the tool which makes the edits if they are authenticated and authorized database users.

Imagine I export the tool as a protected GPService, and  execute the GP service under the Portal Credentials (PortalUserB) and give him the parameters defined (they include the GeoDB credentials for DBUserA), the tool perform the changes in the features classes, and the  changes are registered under the credentials (PortalUserB).

for sure here indeed, it does circumvent the very purpose of user editing tracking.

For me it is a crappy design of the technology, because it is offered as a solution that will run in the server as it runs on the desktop, but it does not.

RogerDunnGIS · Answer

I make this comment not having tried what you're attempting to do.  The linked documentation you provided was very helpful in writing my reply.  I understand what you are trying to do, I understand the results of what is happening, but I do not think the behavior be changed by you.  The user name and timestamp marked in the feature class by the geoprocessing service is the user name that the geoprocessing service is running under.  If the service is public, ESRI_Anonymous is used, else the logged in user is used.

I understand your desire to include the user name making the changes as a parameter to the tool.  This seems like a great idea.  But the documentation addresses that, too: "Tracking who made edits and when the edits were applied can help you enforce accountability and quality control of the features you add to your geodatabase."  So, while your goal is noble, it does circumvent the very purpose of user editing tracking in the first place.  I understand that you'll only let the user run the tool which makes the edits if they are authenticated and authorized database users.

The danger here is publishing a public service which allows users to attempt guessing the administrator user names and passwords to your database so that they can gain secured information.  What prevents a user of your GP service from passing in a JSON object containing the database "sa" (server administrator) user name and attempting a bunch of passwords?  It breaks down your walls protecting your data.  It's better to leave it to ArcGIS Server/Portal to require the token which comes from server-level security instead of database-level security.