topic Re: How to handle authentication against /portal/sharing/rest in PowerAutomate webhook receiver? in ArcGIS Enterprise Questions

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

PhilippeVDV — Mon, 27 May 2024 18:34:22 GMT

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

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

KevinHibma — Mon, 27 May 2024 18:59:28 GMT

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.

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

PhilippeVDV — Wed, 29 May 2024 11:43:46 GMT

@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

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

KevinHibma — Wed, 29 May 2024 13:35:53 GMT

@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.

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

PhilippeVDV — Wed, 29 May 2024 14:37:49 GMT

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

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

KevinHibma — Wed, 29 May 2024 15:00:01 GMT

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.

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

DougYurek — Mon, 03 Feb 2025 14:50:14 GMT

Hey Kevin, any update on triggering a webhook when a user is added to a SAML group? I've been trying to implement this exact workflow (Assign licenses when a user is automatically added to a SAML group). Assigning licenses for an organization our size takes up a substantial amount of time.

My workaround (not optimal, but going to make it work):

Using FME Server to run on a schedule a couple times a day and, for example, query members of our Mobile Workers Group (portal SAML group) and compare that to current assigned licenses. Then I can assign/remove licenses depending on the results.

This might work for us, but it screams inefficiency.

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

KevinHibma — Mon, 03 Feb 2025 16:46:03 GMT

Thanks for the poke on this @DougYurek

Back when I initially responded we began looking at it, but this was near the end of a release and it was much more complicated than we anticipated, and had to defer it.

I have some time still in our current development cycle, so I'll get the team to take another look and see if we can make some progress on it.

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

PhilippeVDV — Tue, 22 Apr 2025 13:05:10 GMT

@KevinHibma , will it be implemented in the 11.5 release or not yet? Best regards, Phil

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

KevinHibma — Tue, 22 Apr 2025 13:13:47 GMT

Unfortunately, we won't be able to handle this particular scenario with a webhook event.

Internally, the user doesn't as much join the group, as they're simply allowed in based on the AD permissions. If we were able to support this, in theory we'd send a webhook event every time the user accessed the group (ie when the check is done).

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

PhilippeVDV — Wed, 23 Apr 2025 08:58:57 GMT

@KevinHibma , thanks for your reply. That's really a pitty. Isn't there any other event that could be used to trigger a webhook that increases the user type? Although technically a SAML or AD user doesn't 'join' a group, the number of members in the memberlist of the group changes when a SAML/AD user 'enters' the group. But a change in the number of group members isn't an event unfortunately. Would that be something that could be implemented in the future? Let me clarify our use case: we fully automated our user management after a SAML integration between ArcGIS Enterpise and a custom IdP. All groups in Portal are based on SAML based group membership and named user accounts are created automatically. The default user type is Viewer but of course, users in certain groups need higher user types (Contributor or Creator). The only way we can automate this is to run a script based on the ArcGIS API for Python that prints all users in a certain group with a certain ID and increases the user type for these users. But then there's always a delay: after someone logs on for the first time he/she should wait before they can start editing until the script has run. Not ideal. A webhook would be nicer. But then we lack an appropriate event trigger for SAML/AD users 'joining' automatically.