Lately, I’ve been spending a lot of time getting our company lab set up and configured with all the bells and whistles that VCF 9 brings to the table. The new SSO experience was something I was really looking forward to. Previously, you had to configure the identity provider for every single product and platform, then add in the permissions and then manage that connection seperately. The new SSO experience, powered by the all new Identity Broker, is supposed to alleviate a lot of that management overhead.
VCF Identity broker
The new VCF identity broker brings a lot to the table. It is no longer a full IdP like vIDM was, instead it just acts as a broker to connect the VCF suite to your actual IdP. This change also enables using modern authentication mechanisms like OIDC or SAML with the VCF suite, which can only be a good thing! When deploying the Identity broker, there’s 2 deployment modes; embedded and appliance. In the embedded mode, the appliance is embedded in vCenter and runs there. This makes it easy and quick to get going, but it does come with limitations and downsides. The embedded mode introduces a single point of failure, if the vCenter server in the management domain goes down, so does your SSO. You can also just connect 1 Identity broker per VCF instance.
The appliance model, is a clustered deployment of at least 3 nodes. You can tolerate a single node failure and still have SSO and you can connect a maximum of 5 VCF instances to the Identity broker. Of course, this does come at the cost of an additional component to manage (although it really isn’t a lot of work) and additional resources required.
Installation
Installation of the VCF Identity broker is really easy thanks to the VCF Fleet Manager. Just fill in all the required details in the wizard and the deploy will happen completely automatically. I do want to point out this tiny setting that has some consequences for other deployments!
Keep track of the internal cluster CIDR setting. The Identity broker appliance nodes run kubernetes, this internal cluster cidr is used for the communication between the nodes. If you’ve used this CIDR in another product that uses a similar deployment model, like VCF Automation, make sure these ranges do not conflict! It’s specified in the deployment wizard but I had read over it and spent the better part of a week troubleshooting my VCF Automation deployment because of it.
SSO Configuration
Once the identity broker setup is complete it’s time for the actual configuration!
In VCF Ops, go to Fleet management and then Identity & access. You’ll be greeted by this screen
Select your VCF instance, if this is the first instance, you’ll only see one. In the next screen, click on the start button.
In the screen that opens, you will be asked what deployment mode you used. As outlined before, we went for the appliance mode. Select that and hit next.
Now we come to the same menu as before but we can continue to step 2.
This is where we actually select the IdP we want to use. For our use case, we’re going to select LDAP. Make sure you have your certificate handy. I combined the root and intermediate CA certs into a single file and uploaded that as “chain.cer”. Fill in the other variables according to what is relevant for your environment.
Make sure you have LDAPS setup and that it is working correctly. In our lab, I could not get the Identity broker to play nice with our domain controllers when LDAPS wasn’t working, even though I was trying the connection over LDAP.
Next, it’s time to configure provisioning. This is where we tell the identity broker what groups and/or users it needs to look for. These groups will then be presented on to the underlying components like vCenter and NSX.
First we need to do a mapping of the attributes used by IDB to what is present in AD. This is done in the screen that shows next.
After the attribute mapping, it’s time to get the groups selected. This is done in 2 steps. First, we set the base DN for IDB to look in and click on select.
This will trigger IDB to do a lookup in the directory and present you with the groups that it’s found. Click the checkmark in front of the groups you want to be present and click on next.
I’m going to skip the user provisioning for this guide, we don’t want any individual user to be mapped through to the environment. Everything needs to be done through groups. This is also what I recommend for production environments.
Client configuration
Now that we’ve set up the base SSO configuration, we can start preparing all the components of VCF to use the SSO configuration. For vCenter and NSX this is very trivial. In the Identity & access screen, you can simply check the box in front of them and hit configure. This will add a new IdP in those components that can be used. It will also change the default login screen to use VCF SSO.
For Operations and Automation it’s also trivial, just go to the identity & access part of Operations. Expand the VCF management item and select the operations appliance. In the right-side of the screen just hit continue.
In the next screen, select the correct appliance and click on Configure. For automation, you can do the same steps.
Permission mapping
All the steps so far have been for getting the SSO configuration done. Everything works and if you click the login with VCF SSO button, you will be redirected to the identity platform you chose. However, since we haven’t given the configured groups any permissions yet, you will be greeted with access denied screens. For vCenter and NSX, the permission mapping is done in the same way as you would do for a regular LDAP connection.
Where it gets interesting, or at least for me, was the components I didn’t really touch all the much in the past.
Operations
To configure the role mapping for Operations, go to the control panel and click on the Access Control button. In the next screen, go to user groups and click on the 3 dots to open the menu. Click import from source.
In the window that opens, enter part of the name of the group you want to import. Check the groups you want to import and continue.
This makes the group available to Operations, but it will not have any permissions yet. To grant the group permissions, edit the group. In the next window, select a scope and a permission level. In my case, I’m adding the group on all scopes and granting it admin privileges. In this screen you can also check that all users in the group are correctly shown in Operations.
Operations for Logs
Not all components of VCF can be configured as easily as the others. Operations for Logs and HCX need to be configured slightly differently. To get those components working with VCF SSO, you need to setup an OIDC client and then configure those components to talk to it.
The OIDC client is set up from VCF Operations, in the identity & access menu like before. On the right-hand side, click on VCF Other Components. Once there, add a new OIDC client. Give it a name and select the identity broker that should be used. Keep the screen open, we will need the issuer, ID and secret later on!
Go to Operations for Logs, click on Configuration, then click on Authentication. On the right-hand side, click on VCF SSO.
Give the provider a name and paste the values from the Operations OIDC client. Make sure the toggle at the top is switched to enabled.
Now it’s time to do the permission mapping for Logs. To do this, go to Management, then access control. At the bottom of the screen, you’ll see Directory groups, in that section click on New group.
In that screen, enter the exact name of the group you want to have available in logs, as well as the exact domain name. On the right-hand side select the role you want to assign to the group. In my case, I’m assigning super admin permissions to a single group.
Conclusion
As you can see, VCF Identity Broker brings a lot of improvements to the table over vIDM. It’s a major step in the right direction but it’s far from perfect. After I set everything up in the lab, the disks on one of the identity broker appliances filled up and the recovery hasn’t been easy so far. I will update this article with a link to the resolution.
What I’d love to see is the ability to push the permissions to all the different components, it doesn’t feel as easy as it can be. But I’m sure this experience will be improved in future releases!