vCenter Single Sign On (SSO) is an authentication proxy

I’ve been in numerous discussions regarding vCenter Single Sign On (SSO) where mostly people didn’t fully understand the functionality of SSO.

Let me make this statement:
SSO is an authentication proxy.

The function of SSO is to act as a single proxy in your VMware environment to verify user credentials against security providers. When configuring SSO, you configure SSO with every security provider that needs to authenticate users. Besides the proxy function you can also define internal SSO users. These users are located inside the SSO database. Whenever you are successfully authenticated by SSO, you receive a security token that let’s you connect to other vSphere components without providing your password again, hence Single Sign On.

There are three kind of users that can be used:

  1. Internal system users, referenced with the @system-domain domain
  2. Local users. These are local Windows users defined on the SSO server
  3. LDAP users. These users are located in external LDAP databases, like openLDAP, Active Directory.

Let me make another statement:
You do not set permissions for resources in SSO

Permissions are still set on the resources (for instance vCenter Server). Nothing changed for that. So if a user needs to be granted permission to vCenter, you add the user on the vCenter server and assign permissions as you used to do before. Additionally you are now able to add permissions to @system-domain users.

Let me finally make this last statement:
You can have multiple SSO installations in your environment

The fact that it’s called Single Sign On does not necessarily mean that you can only deploy one instance of SSO in your complete environment. Every vCenter installation requires an SSO instance, but there’s nothing wrong with installing a separate SSO instance for every vCenter Server in your environment. As a matter of fact, installing multiple SSO instances makes the environment less complex, does not create dependencies between vCenter Server environments and therefore simplifies future upgrades.

Related posts:

  1. Replacing VMware vCenter 5.1 Certificates Made Easy Tweet The release of vCenter 5.1 added more components and therefore more certificates into the mix. Using CA signed certificates increase security, but the process of updating these certificates is...
  2. Versioning and Renaming Elements in vCenter Orchestrator Tweet During the development cycle of a workflow, your workflow can change drastically whenever you add new functionalities. Therefore a good practice is saving different versions of your workflow. One...
  3. VMware vCenter Server Heartbeat Tweet VMware just released the VMware vCenter Server Heartbeat product which was first publicly announced at VMworld Europe 2009. VMware vCenter Server Heartbeat is an addon which creates high availability...
  4. vCenter Orchestrator Configuration Element Attribute Values Missing After Import. Tweet When importing a package on a vCenter Orchestrator (vCO) server in my lab I noticed that the values of the attributes inside the Configuration Elements (CE) were missing. At...
  5. Brocade Network Advisor Management Plug-in for VMware vCenter Tweet The storage network administrator drew my attention to the Brocade Network Advisor (BNA) Management Plug-in for VMware vCenter. Brocade Network Advisor Brocade Network Advisor provides a unified network management...

0 Comments on “vCenter Single Sign On (SSO) is an authentication proxy”

Leave a Comment