Workflow Activity run as different user

[Ahmmed Ali]

Hello All,

First of all, my sincere apologies for long question.

below is background of my query.

I am working on one integration now. It uses OAuth2.0. I have setup working for this.

I have authenticated third party application with myself logged in to SNOW. so access token created with my name in user field. I am using this OAuth profile in one rest message in workflow. so if I raise the request it is working. But if anyone else submits the request, it is failing with msg that no access code available. I got the reason as the token is for my account. so I changes the user name as System Admin in token.

now in workflow, I am using one run script activity before rest message activity to impersonate user System admin using below statement.

gs.getSession().impersonate("sys_id of user");

now it is working as expected for all users. so to make sure rest activity runs with admin account, I have this impersonate statement.

Another approach  I tried is, instead of run script activity, I placed one timer activity with small delay. now it is working as expected for all users. I tried to place logs before and after time activity. before timer activity the gs.getuser() returns user name who submitted the request. after timer activity, gs.getUser() returns name as system.

Now below are my queries.

1. is using impersonate statement in workflow best practice to make sure activity runs with user ID who has the access?

2. in second scenario, even though gs.getUser() return name as system, it is taking access token of system admin(user id is admin) user. is it snow default behavior that it takes admin access token?

3. Is there any other best approach I can go with.

Once again apologies for long question.

Thanks,

Ali 

[rahulpandey]

Hi Ahmmed,

In my opinion the first option is better option any day due to below fact.

When you introduce a timer, if breaks the contextualisation from actual user to system user and then many things won't work as expected, example if you have written a notification script which should go to updated_by user also, ACL won't work as expected.

Since, system is a backend or system user, we do not have anyways to identify the security behaviour viz-a-viz system user.

In nutshell, you are already using the better option #1 as per my opinion.

[Ahmmed Ali]

Hi Rahul,

Thank you for your reply.

I will go with #1.

my last query is, how SNOW handles system user here ? because out of curiosity, I removed user name from OAuth credential table. now there is only one record in oauth_credentials table which is refresh token and has blank user name.

now in workflow (with #2 above), if any other user submits the request the rest message is working. SNOW is taking this refresh token to get new access token and that access token is used in rest call. also the access token is saved in oauth_credentials table with user as blank only.

how this is handled by SNOW exactly.

Thank you so much for reply. Good learning from you.

Regards,

Ali

[rahulpandey · Accepted solution]

The System behaviour is really something is very hard to identify because of the fact, it is not a user(as admin user) but the system itself. You can get in touch with HI and might be able to get precise answers.

About point 2 , servicenow automatically handles the contextualisation, for example in case of inbound email+ attachment encryption, whenever servicenow get's an email, it maps it to user based of encryption role.

My experience servicenow gives good control to devs but there are some area we call it core code, where developer has not role to play. they have to follow the apis/flow

Hi is a very good place to learn about these core functionalities.