If you have been following my recent adventures in playing with both Authentik and Keycloak as an OAuth/OIDC Identity Provider (IdP) for use with vCenter Server or VMware Cloud Foundation (VCF) Identity Federation, you can take it one step further and authenticate with a Yubico YubiKey or Apple Face ID for additional security.
In my original setup, the OIDC endpoint provided by both Authentik and Keycloak was using HTTP and works perfectly fine with both vCenter Server and SDDC Manager for a VCF-based environment. With that said, if you have a requirement to serve the OIDC endpoint over HTTPS, which is a requirement for using WebAuthn (e.g. YubiKey, Face Id, etc), then some additional configurations are required on both the identity provider as well on the vCenter Server side depending on the type of TLS certificate you are using.
As a prerequisite, I will assume you have already provisioned a TLS certificate that includes the full certificate chain but if you have not, here is a quick snippet for using OpenSSL to create a self-signed TLS certificate with the following required files:
- keypem - Private Key
- cert.crt - Certificate
- fullchain.pem - Certificate Chain
openssl genpkey -algorithm RSA -out key.pem openssl req -new -key key.pem -out csr.pem -subj "/C=US/ST=CA/L=Palo Alto/O=WilliamLam/OU=R&D/CN=auth.williamlam.local" openssl x509 -req -in csr.pem -signkey key.pem -out cert.crt -days 365 cat cert.crt key.pem > fullchain.pem
Keycloak
Keycloak makes it trivial to enable HTTPS using your own TLS certificate by just providing two additional arguments --https-certificate-file (certificate) and --https-certificate-key-file (private key) to the startup process.
kc.sh start --https-certificate-file=/path/to/cert.crt --https-certificate-key-file=/path/to/key.pem
Note: By default, Keycloak uses port 8443 for HTTPS but you can the default port by using --https-port argument
Authentik
While Authentik can be used with HTTPS right out of the box with their own self-signed TLS certificate, it does not provide a full certificate chain validation and hence you need to add your own TLS certificates. I really like the Authentik UX for setting up the IdP, but I was pretty shocked at how poorly their implementation was for using your own custom TLS certificates, which took me much longer to figure out than I had initially expected, especially compared to the Keycloak experience.
By default, if you open the Authentik URL in a browser and add HTTPS, it will automatically serve the auto-generated self-signed TLS certificate which will be displayed as "authentik default certificate"
To use your own TLS certificate, you add it to Authentik by navigating to System->Certificates in the admin interface and create a new certificate entry with a friend label and the certificate and private key as shown in the screenshot below.
Next we need to change the default TLS certificate that will be used by navigating to System->Brands and edit the default brand and go to very bottom and expand "Other global settings" where you will be able to select the desired TLS certificate as shown in the screenshot below:
You might say, that was pretty easy? Yes, it was SUPER easy BUT the issue is when the certificate actually goes into effect! While the documentation mentions there is a periodic check, roughly every 5 minutes, I have found that it goes live after a much longer period of time. I initially thought it was instantly after clearing the browser cache which lead me down a rabbit hole of debugging and troubleshooting.
I eventually came back after a couple of hours and magically the TLS certificate that I had configured was finally being served ...
I think the last mile of this process could be improved to provide a bit more details on when the certificate would go live or allow admin to make it live immediately.
vCenter Server
Once your Authentik, Keycloak or any other IdP for that matter has been setup with your desired TLS certificate, the next part is to the identity federation configurations within vCenter Server (which is true for both a vSphere or VCF environment).
If you recall in the previous blog posts, we had selected the Okta option to setup our OAuth/OIDC IdP, however for OIDC endpoint using HTTPS, we need to select the PingFederate option.
The IdP configuration wizard between Okta and PingFederate is exactly the same except you now have the option to add your certificate chain which is required to validate the OIDC endpoint that must be served over HTTPS.
If the certificate chain that you have provided is able to get validated successfully with the OIDC endpoint of your IdP, then you will be able to proceed with the remainder configurations which is exactly the same as I have blogged about HERE and HERE.
Thanks for the comment!