- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, thanks for clarification.
So, when you start a vRO workflow from a given vSphere Web client UI, it calls vRO server REST API, authenticating with a SAML token issued on behalf on the user currently logged into the Web client (the user who starts the workflow).
Now, when you start the workflow from vc_#1, it will pass a SAML token issued by vc_#1 authentication provider, let's name it psc_#1. And when you start the workflow from vc_#2, it will pass a SAML token issued by vc_#2 authentication provider, let's name it psc_#2.
When these REST calls reach vRO server, it will try to validate the SAML tokens against the authentication provider the vRO server is configured with, let's name it psc_#3. For this calls to pass, it is required that psc_#3 to be able to validate tokens issues from both psc_#1 and psc_#2.
In practice, the above means that either:
a) all PSCs are the same (one common PSC instance is used for authentication by vRO server, vc_#1 and vc_#2), or
b) if these PSCs are different instances, they should be configured in a way that SAML tokens issued by psc_#1 and psc_&2 can be validated on psc_#3. I'm not sure what are the requiremenets for this setup to work; perhaps all PSCs must have same set of token signing certificates.
Hope the above makes sense ![]()