Skip to main content

Hi

Is it currently possible to specify a list of users a user has the ability to execute REST requests on behalf of?

 

As I currently understand it it's only possible to select a list of users who can execute request on behalf of other users, but not specify what users they are allowed to execute on behalf of.

 

While the use of such privileges could potentially be monitored, and thus detect such usage this is reactive, and would not undo any damage performed by a bad actor. 

 

The scenario I'm researching is the misuse of a etm assyst user (who would naturally have broader access  such as delete of assyst users (possibly deleting the admin team's accounts) or editing of privilege groups) to allow for a broad range of etm integrations. 

 

Is this a correct understanding, or is there a method to limit a user to a select list of users they can act on behalf of of? 

-I do not think this functionality is active in assyst but better to log an incident to investigate this further.

-I will do a test to check this behavior is achievable by using CSG’s. If some one is trying to execute on behalf of request using user A which is in restricted CSG for the actioning user, may be you can achieve your requirement 

- If you are using “on behalf of” function through ETM, then you can use “No value when” field in the data mapper with an expression to check something on assyst user form specific for admin accounts
For example :
you can add all the admin accounts to one service department (either primary or secondary), 
then build an expression to check on behalf of user is in that svd, if yes then return true. So the etm will stop processing further in that data mapper.

Thank you very much for the reply.

I have since logged a support request as recommended (448492).

 

I had not thought about the ETM angle, while not exactly what i need, it is intriguing.
The problem I’m facing is whether to enable non admin assyst users to use onBehalfOfUser, and this then cause the need to think about privilege escalations as some users or bad actors could be tempted to use this power with a highly privileged user, such as the ETM user.  

 

The cause of this line of questions is due to the desire to let some integration users use onBehalfOfUser to better indicate what integration is performing an action, modification of a resource, or other changes in the application without also having to force them to set up multiple separate Windows service accounts, etc. This would allow for similar distinction for these integration users as can be done using ETM. 

 

As it stands, this seems not possible due to the possibility of massive privilege escalations if a user can’t be locked down to only being allowed to act on behalf of an admin-selected list of “dummy Assyst users.”

 

I will be keeping this thread open until the ticket is resolved; however, unless there is something else I've missed, the onBehalfOfUser functionality seems best kept under lock and key until an eventual enhancement is implemented.

Reply


Terms & ConditionsCookie settings