vRO workflow permissions when executed from vRA XaaS blueprint

[leema2]

Running vRA 7.1 with embedded vRO.

vRA is configured to authenticate against AD, and vRO is configured to use AD as well via vRA's component-registry.

Access permissions to vRO are restricted to our development team, ie they are the only users that can login and work within the vRO client.

When an end-user (non-developer) requests an XaaS catalog item from within vRA that calls a vRO workflow, the Events tab for that workflow in the vRO client shows the workflow being run by that end-user.

Is that really what's happening? ie even though the end-user has no explicit permissions defined to access vRO, the workflow is executing as that user?

Or is the vRO/vRA integration such that vRO is aware of the requesting user from vRA and logs that user as the invoker, even though it's not really executing as that account? In which case, which user does the workflow run as?

Mostly just trying to confirm that the only entry point to run vRO workflows for our end-users is via vRA catalog items, and I'm not misunderstanding how the permissions work.

Thanks

matt

[iiliev]

Hi matt,

I'm not very familiar with implementation details of this part of the product but to my understanding it is the latter - vRA/XaaS calls vRO REST API with a special solution user token so vRO is aware that the call is coming from vRA/XaaS, and gets implicit access permissions.

[leema2]

Appreciate the reply llian. That would seem to make the most sense.

[chicagovm]

I'm seeing very similar issues and confusion.

Would be great if VMware provided a document [ Best Practice ] on which "userID and/or Service Accounts" should be used during the various configurations when trying to link all components. Basically a Roles / Permissions and the flow of each account.

I have a service account in vRA 7.1 and accounts that are used to configure vRO 7.1 and then vCenter Global Groups ( Domain Groups ).