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.
