Overcoming Challenges of External OIDC IDP Integration with vCenter 8

Overcoming Challenges of External OIDC IDP Integration with vCenter 8
Recently I was brought in as a consultant on a project for a large company. The
engagement was to integrate Okta as the MFA identity provider for their vCenter instances, starting with their lab environment, which sounded like a simple project.

Of course… it didn’t stay simple for long.

The biggest complication right out of the gate was that all traffic had to pass through two different proxies. That’s where things started to get interesting.
The team had already configured the Okta Identity Provider in vCenter, but SCIM provisioning just wasn’t working. Okta wasn’t pushing groups through at all. Once Istarted digging into the environment, it became clear pretty quickly what we weredealing with—the vCenter appliance had no direct internet access.

On top of that, theorganization wasn’t willing to open outbound 443 to Okta.
So now we needed to introduce a proxy into the mix.

The First Hurdle
The primary proxy in their environment came with a major catch—getting changes approved on it was… let’s just say not quick. In some cases, not even realistic.
Because of that, we started looking for another path forward and ended up finding an internal team that managed their Apigee platform.
We pulled them into a working session and walked through what we needed. After reviewing everything, they confirmed we could split the traffic:

 General outbound traffic would continue through the main proxy
 SCIM provisioning traffic would route through Apigee

That gave us a workable path forward without having to fight the main proxy team forevery change.

The First Major Issue
During testing, things took a turn. At one point we removed and attempted to recreate the Okta Identity Provider in vCenter as part of troubleshooting—and that’s when we started hitting certificate errors.
Cue the troubleshooting spiral.
We went through all the usual steps:
 Running curl commands from vCenter to test connectivity

 Importing CA and issuer certs into the trust store
 Validating proxy certificate chains
None of it worked.
At that point, I started digging through documentation and came across a Broadcom article related to Microsoft Entra ID integration. Even though it wasn’t Okta-specific, the symptoms matched exactly what we were seeing.
The fix ended up being something you wouldn’t normally think of right away—we had to manually import the proxy certificate chain into the VIDB trust store used by the identity provider inside vCenter. That meant dropping into the appliance shell and updating the Java keystore directly.
Once we did that and restarted the relevant services, we were finally able to recreate the Okta Identity Provider successfully.
Below shows the Path and command structure needed to accomplish this:
 Path:
/storage/containers/vc-ws1a-broker/<HASH>/rootfs/usr/local/jre-
17.0.10/lib/security/cacerts
 Command:
keytool -noprompt -storepass changeit -import -trustcacerts \
-file <path to certs> \
-alias MSFT \
-keystore/storage/containers/vc/ws1abroker/########/rootfs/usr/local/jre-
17.0.10/lib/security/cacerts

Finally, we had some forward progress.

The Apigee Learning Curve

With the identity provider working again, the next challenge was getting SCIM fully functional through Apigee. None of us on the infrastructure side had much hands-on experience with Apigee, so there was definitely a learning curve. We had a quick walkthrough from one of their engineers, which helped conceptually, but the real work was in getting the details right.
I put together a basic YAML template for the proxy based on what we knew and some additional research. Sent it over to the Apigee team, and they confirmed we were on the right track.
But during deployment, they used placeholder URLs.

So when we tested… nothing routed correctly.
At that point, it was clear we needed another working session. After lining that up, one of their engineers jumped in, spotted the issue almost immediately, and corrected the base path and endpoint mappings.
Once that was fixed and deployed properly, we looped in the Okta engineer to confirm provisioning. Ran another test login—and this time it worked.
Okta MFA authenticated successfully into vCenter, and group provisioning was finally flowing.
Finally a win after a lot of troubleshooting back and forth.

The Next Unexpected Challenge

With the lab working, the assumption was we could just rinse and repeat for the rest of the vCenters.
Not quite.
Apigee requires every base path to be unique. The problem is that the SCIM base path used by vCenter is essentially fixed—you can’t just change it to something else.

So now we had a new problem:
How do you support multiple vCenters behind Apigee when they all expect the same base path?

The Final Architecture
After working through a few different ideas with the Apigee and networking teams, we
ended up finding a much cleaner solution than what we originally thought we’d need. Instead of adding another layer like NGINX to route traffic, we took a closer look at how the Apigee proxy was actually defined—specifically the OAS (OpenAPI) YAML file. Originally, the base path in Apigee mirrored the full SCIM path required by vCenter. That’s what caused the conflict, since Apigee enforces uniqueness on base paths.
The fix was actually pretty simple once we saw it:
 We shortened the base path to something unique per vCenter (like an identifier
or name)
 Then we moved the full SCIM path (/scim/v2/…) down into the individual
GET/POST operations in the YAML

This basically separated what Apigee cares about (unique base paths) from what
vCenter expects (fixed SCIM endpoints).
Once we made that change:
 Each vCenter had its own unique base path in Apigee
 Requests still hit the correct SCIM endpoints on the backend
 And we didn’t need any additional routing layer
After rolling it out, we validated:
 SCIM provisioning worked across all vCenters
 Group sync was consistent
 Authentication flows stayed stable
Much simpler design, and way easier to scale.
Final Thoughts
What started out as a “quick MFA integration” ended up touching a lot of different areas:
 OIDC identity federation
 SCIM provisioning
 Proxy and network design
 Certificate trust handling
 API gateway behavior
The biggest takeaway for me was how tightly identity integrations are tied to everything around them—networking, security, and even internal team processes. In the end, getting this working wasn’t about one fix. It was about working across multiple teams, figuring things out step by step, and being willing to dig into areas that weren’t originally in scope.