This use case presents alternatives that you can use to pass user credentials without using the vRealize Automation plug-in "per user" session capability.
In some use cases, it is required that the roles and permissions for the workflow accessing back to vRealize Automation are the same as the user who initiated the workflow from vRealize Automation. Some of the use cases that require this are:
- For auditing purposes - when it is necessary to track which user made a change, even if this is through a workflow the user triggered in vRealize Automation.
- For presenting information that the user can access, such as the content of a drop-down menu run by XaaS operations or a query run within a workflow.
- For taking actions, modifying properties with the role and permissions of the user. For all operations, the user can trigger that through extensibility.
As of vRealize Automation 8.4, there is no solution to pass the vRealize Automation authentication from vRealize Automation to vRealize Orchestrator so it can be used to authenticate back in vRealize Automation. The vRealize Automation plug-in supports per user sessions, but the plug-in uses a service user role with limited rights.
The workaround for this limitation is to query the end user to reenter their credentials when they run the workflow. However, doing so exposes their credentials to the vRealize Orchestrator developer.
Another solution that prevents users from accessing unauthorized data is to use a service account and create action-based filters by project based on user permissions.
The sample workflows provided in the sample package use the default host provided when running the Set vRA Host workflow.
