How to handle authentication against /portal/sharing/rest in PowerAutomate webhook receiver?

[PhilippeVDV]

Hello

I've set up SAML authentication for ArcGIS Enterprise where users can join automatically with a default Viewer user type.

I'm trying now to set up an organization webook. The idea is that when a SAML user is added to a specific Portal group (through SAML based group membership), a webhook is triggered to promote the user type from Viewer to Creator (and role from Viewer to Editor)

In /portal/sharing/rest you can do a http POST request to update the UserType as follows: https://FQDN/portal/sharing/rest/portals/0123456789ABCDEF/updateUserLicenseType

I've configured the webhook in ArcGIS Enterprise succesfully, but I'm struggling now in PowerAutomate with the authentication against /portal/sharing/rest

I tried to authenticate by setting Authentication Type to Basic and providing the portaladmin credentials

Next, I execute the http POST request as follows:

But this doesn't seem to work

The webhook receiver is triggered succesfully when a user is added to the group, but it seems that the authentication goes wrong against /portal/sharing/rest, because I receive a 403 error: "You do not have permissions to access this resource or perform this operation"

So basically my question is, how do you authenticate agains /portal/sharing/rest so that you can execute all the available POST requests

I'm not a developer, but I hope that this should be possible in some way? All ideas or sample code are welcome (preferably in Power Automate)

Best regards

Phil

[KevinHibma · Accepted solution]

I'm not real sure what thing in Power Automate your first screen shot is from, but I'll guess it's not what you want to use / it doesn't authenticate like you want.

Try making an HTTP Post call to generateToken: https://developers.arcgis.com/rest/users-groups-and-items/generate-token/

That should return a token, which you can then use on all your calls that require authentication. In my screen shot I get a token, parse it from the response, and make use of as a header on all my calls back to the Portal.

[PhilippeVDV]

@KevinHibma , thanks a lot for your feedback! Following your instructions I was able to create the webhook that increases the User Type and Role when a user is added manually to a certain group. This works perfect now.

However, my webhook doesn't seem to work when a SAML user is added automatically to a Portal group that was created based on SAML based group membership.

I tested both with /groups/<groupID>/addUsers and the more general /groups/<groupID> but when a SAML user authenticates the first time and is added automatically to the group it doesn't seem to trigger anything. Any idea how to solve this?
Best regards

Phil

[KevinHibma]

@PhilippeVDV Interesting timing. I've been working on this exact question this week. Today, you're correct, no webhook is triggered when a SAML user has been added to the group by based on group membership. Internally, different "things" are happening with the add user / authentication checks and calls when going this route compared to adding a built-in user to a group. I'm investigating if we're able to support this scenario. For now, I do not believe there are any workarounds.

[PhilippeVDV]

Thanks again for your feedback @KevinHibma . I opened a support case in parallel, and apparently an enhancement request was logged very recently:

ENH-000166912 - Portal organization webhook: Add capability to trigger /addUser and /removeUser events for group members who joined based on (AD) SAML-based membership

And got also this information: "This is because those users are automatically enlisted as a member of the group because that was the prerequisite (that they can join because they're a member of a particular designated SAML Group). Sharing, unsharing, and deleting items from the group does trigger an event. A workaround for this, if they want to be alerted when such a user joins that group, would be to just have them share something immediately after joining."

I did not test the workaround yet

Best regards

Phil

[KevinHibma]

That's exactly the enhancement request I'm evaluating. I need to see if its technically possible before accepting/rejecting. I hope to have that question figured out soon. If we can do it, we'll try to address in an upcoming release.