I was until I dived in and found answers which I will do my best to explain here.
vCenter Single Sign-On is a new feature of vSphere 5.1 that is not just an authentication broker but also a security token exchange providing a more secure way of accessing your vSphere solutions. What that means is that when you previously logged into vCenter Server, you were authenticated with the provided username and password against the Active Directory configured for vCenter Server. With vSphere 5.1 and vCenter Single SIgn-On you no longer log directly into vCenter Server but with a security domain defined by your vSphere environment. When logging in to vSphere 5.1 you actually pass authentication to the vCenter Single Sign-On server which can be configured with multiple identity sources like Active Directory and OpenLDAP and on successful authentication, your username and password is exchanged for a security token which is then used to access the vSphere components like vCenter Server and vCenter Orchestrator etc.
Although vCenter SIngle Sign-On is an additional component in the vSphere suite, a critical component that is required before any other vSphere 5.1 component is installed or upgraded, it actually doesn’t necessarily mean you need to re-architect your vSphere environment. You can use vSphere just as you have been from years past and vCenter Single Sign-On will fit right on in just as an additional service local too or separate from vCenter Server.
Where some of the confusion comes from I believe is with the added benefits that vCenter Single Sign-On can bring when administering multiple vSphere environments. When installing vCenter Server you have the choice to specify or install a vCenter Single Sign-On server providing the ability to add multiple vCenter Servers and their components to a centralized vCenter Single Sign-On source. This provides a single pane of glass view across all vCenter servers, 5.0 and higher for administration as well as the ability to define queries that can be searched across multiple vCenter Servers without the requirement of Linked Mode used in the past.
Now this maybe seen as a single point of failure, a critical one at that when talking authentication but vCenter Single SIgn-On can be configured in a clustered or multisite deployment to help with availability.
Clustered deployments are with multiple instances of vCenter SIngle Sign-On are deployed, one is defined as a primary instance the remainder as slaves and all share a single database instance and placed behind a third party load balancer can provide redundancy or high availability of the vCenter Single Sing-On solution. This typically is local to a single site however if geographical sites are used with multiple vCenter servers, you can still utilize a central clustered environment, however a multisite configuration is recommended.
Multisite deployments are where a local replica is maintained at remote sites of the primary vCenter Single SIgn-On instance. vCenter Servers are reconfigured to use the local vCenter SIngle SIgn-On service and reduce authentication requests across the WAN. Multisite deployments do drop the support of single pane of glass views unless Linked Mode is utilized and multisite deployments are actually required to maintain Linked Mode configurations where roles, permissions and licenses are replicated between linked vCenter servers. Linked mode will re-enable single pane of glass views across multisite instances.
