What is Single Sign-On?

vCenter Single Sign-On is an authentication broker and security token exchange, and provides a more secure way of accessing your vSphere solutions.
In versions of vSphere 5.0 and earlier, authentication and authorization occurred via the domain connection of the vCenter Server host machine. In this model, all vSphere components which required login needed separate login sessions. This can become quite cumbersome and time consuming when switching between various VMware solutions.
Starting with vSphere 5.1, vCenter Single Sign-On was introduced to act as a federated authentication and authorization source. This allows all VMware software which is programmed to work with SSO to use a single login point to access all solutions.

History of vCenter Single Sign-On

vCenter Single Sign-On was first introduced with vSphere 5.1 in 2012. SSO in 5.1 was an outsourced software package which was created by an OEM vendor (RSA). This was not very well implemented and VMware recieved a lot of flak from the community and its customers. So, for vSphere 5.5, it was replaced by a much more robust system that was developed in-house at VMware.
 

How it works

The vCenter Single Sign-On system runs as a web server application, to which clients can connect over a TCP/IP connection to make authentication and authorization requests. The actual logic is controlled via a series of java applications which are accessed via the front end web server. SSO also maintains a series of “Identity Sources”, which it leverages to manage user requests. An Identity Source represents the physical source of the data of the users and user groups that you manage using SSO. An identity source can be one of the following:
        1. An external directory, such as OpenLDAP, or Microsoft Active Directory
        2. The System identity source (vsphere.local database)
        3. Local Operating System Users (of the machine on which SSO is installed)
Once users have been authenticated, SSO will provide a Token which can be used to login to various vSphere solutions. The configuration for Single Sign-On is maintained in a simple database.

Dependencies and Trusts

Since SSO provides a critical component which is required for all vSphere solutions, almost all of these solutions have their own trust relationship and therefore dependency with SSO. If this trust relationship is broken(via reinstallation, loss of configuration or replacement of SSL certificates, etc.) the solution will almost certainly be rendered inoperable. The below diagram shows the dependencies and trusts that the applications have.


vTip: If you need to update the certificates on any of these solutions, make sure the trust is updated as well.