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:

  1. Renew. As its name suggest, this renews an existing token for more time. It should be done before the existing one expires.
  2. Validate. Confirms whether an existing token is valid or not.
  3. 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.

This entry was posted in vSphere API and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Posted November 4, 2012 at 11:59 pm | Permalink

    Conceptual Deep Dive in VMware vCenter Single Sign On via @sjin2008

  2. Posted November 5, 2012 at 12:48 am | Permalink

    Conceptual Deep Dive in VMware vCenter Single Sign On (DoubleCloud)

  3. Posted November 7, 2012 at 9:16 am | Permalink

    Conceptual Deep Dive in VMware vCenter Single Sign On from @sjin2008

One Trackback

  • By Welcome to vSphere-land! » vSphere 5.1 Link-O-Rama on November 10, 2012 at 8:20 pm

    […] Conceptual Deep Dive in VMware vCenter Single Sign On (DoubleCloud) Adding AD authentication to VMware SSO 5.1 (Gabe’s Virtual World) vSphere 5.1 Gotcha with Single Sign On (SSO) (Long White Virtual Clouds) Comparing behaviour of vCenter Single Sign On with earlier versions of vCenter Server (KB Article) vCenter Single Sign On FAQ (KB Article) Installing vCenter Single Sign On in a multisite deployment (KB Article) Setting up Apache load balancing software with vCenter Single Sign On (KB Article) Configuring vCenter Single Sign On for high availability (KB Article) Troubleshooting Single Sign On (SSO) issues in vCenter Server 5.1 (KB Article) Troubleshooting Single Sign On on a Windows Installation (KB Article) Understanding and troubleshooting vCenter Single Sign-On users, groups, and login qualifications (KB Article) Backup and restore the vCenter Single Sign On (SSO) configuration (KB Article) VMware vCenter 5.1 SSO Installation Error 29133: Administrator login Error (Valco Labs) vCenter SSO 5.1 Install Issues (VMwise) vCenter SSO Config + Multiple Domains (VMwise) vCenter SSO + Active Directory (VMwise) How vCenter Single Sign On Affects vCenter Server Installation and Upgrades (vSphere 5.1 Docs) How vCenter Single Sign On Deployment Scenarios Affect Log In Behavior (vSphere 5.1 Docs) vSphere Inventory Searching and Tagging (VMware vSphere Blog) vCenter Single Sign-On Part 1: what is vCenter Single Sign-On? (VMware vSphere Blog) vCenter Single Sign On: Understanding the Administrators role (VMwareTechPubs Video) vCenter Single Sign On: Managing Users (VMwareTechPubs Video) vCenter Single Sign On in the vSphere Web Client (VMwareTechPubs Video) […]

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.