Conceptual Deep Dive in VMware vCenter Single Sign On
One of the key new features in vSphere 5.1 is the Single Sign On. Because it’s new and also complicated, I’ve heard it’s not easy to get it right the first time. Experts recommend that you should play with it in a test or staging environment before upgrading your production environment.
It’s understandable for new things which always take time to get familiar with. I am not going to discuss on whatever best practices on using the Single Sign On, but rather the concept and flows behind it. The discussion helps you understand the feature deeper than pure GUI, therefore may assist you to diagnose SSO related problems.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
For that, you got to read the vCenter Single Sign On Programming Guide. I find it’s pretty well written especially the content on concepts and architecture.
The basic idea of single sign on is easy. It says that once you login into one system, you can be automatically authenticated with other systems therefore no more login afterwards. It started from Internet Web world in which people are tired of having to login many times, and even more with creating multiple usernames and passwords with each site (it’s particularly painful in that different sites may have different and conflicting password policies therefore you can use one password for all). There are many single sign on services on the Internet these days. Note that, the single sign on goes one step further than sharing the identities across systems.
Why VMware got into this business? For sure VMware is not an Internet company, but it has many different products, each of which requires its own username and password. All the products are still usable, but not as convenient as customers want while pulling them together. To solve the problem, the Single Sign On was called to help.
As you can see, the single sign on is pretty easy conceptually. When it comes to implementation, however, it’s a different story. You know anything involving multiple entities is not easy, just like doing projects involving multiple teams in an organization or across organizations.
Single Sign On runs as a server that is accessible from other products which need authentication services. In the VMware vSphere case, it’s vCenter and other solutions on top of it. It does not exclude the possibility of being accessed by any third party application assuming the SDK is used.
One key thing to support Single Sign On is the identity repository. You can integrate multiple sources of stores but not duplicates. As of vSphere 5.1, the vCenter SSO supports: Windows Active Directory, OpenLDAP (Lightweight Directory Access Protocol), vCenter local user accounts, and vCenter SSO user accounts.
Once that is settled, any login to products will be checked against the SSO service. If you look closely at the Figure 1-1 of the programming guide, you will find out the vCenter login is channeled to vCenter Single Sign On server. The vCenter Client first sends a token request which is verified with identity store. If successful, a SAML(Security Assertion Markup Language) token is issued back to the vCenter Client which then uses the token to login into the vCenter server. The diagram doesn’t show how the vCenter Server goes back to the SSO server to validate the SAML token. Notice that the method used to login into vCenter from vSphere Client is different from previous one, but the SessionManager.loginByToken() which has been added in vSphere API 5.1.
The interaction between a client and SSO server is based on the SOAP protocol which should be familiar for most of us who have used vSphere SDK that is based on SOAP too. As a typical SOAP request, the token request includes SOAP header and body. For security, timestamp and certificate are included as well.
Beyond issuing SAML tokens, SSO server can also help 3 additional functions:
- Renew. As its name suggest, this renews an existing token for more time. It should be done before the existing one expires.
- Validate. Confirms whether an existing token is valid or not.
- Challenge. It’s said to be part of negotiation with vCenter Single Sign On server to obtain a server.
I didn’t find much discussion the Challenge function in the guide. I guess it would require look at the traffics to really dig into that for details. I may have chances to do that along the way.
Fortunately, the SSO SDK is included in the vSphere SDK 5.1. There are also a few samples illustrating the usage of the APIs. These samples share the same problems as those of vSphere SDK: the details of Web Service, which should be hidden, obscure the real flow of SSO APIs. I may include the SSO into future vijava API if I can find time.