vCenter Single Sign-On (SSO) - Part1

This feature was introduced in vSphere 5.1 and changed the whole architecture of vSphere environment in terms of authentication and directory services.

Concept

Previously, when you login to your vCenter (for example), your username and password are authenticated against vCenter AD or vCenter local users.

With the presence of SSO, your credentials are passed from vCenter to SSO server. SSO is using Shared Token Service (STS) as authentication interface with vCenter. The credentials are passed as WS-TRUST message to STS. Your SSO server can have multiple mixed identity providers (LDAP, Local Users, OpenLDAP, System-Domain). SSO will try to authenticate the credentials received in WS-TRUST message against all identity providers till successful authentication is matched. Upon successful authentication, STS generates a SAML 2.0 token which is sent back to vCenter and to end user.

Note: vCenter will ONLY pass the credentials to SSO and won't do any authentication

At this stage the end user will get into vCenter and start browsing different components. The vCenter Server uses the token to perform operations on behalf of the primary user. From the client's perspective, the vCenter Server stands between the client and any vSphere services that the client can use via the vCenter Server.

For example, in case the end user wants to browse vShield Tab from vSphere Client, prior to vSphere 5.1 the user needs to enter new credentials. With the presence of SSO, vCenter will pass the token on behalf of the client to vShield manager and vShield manager use it to verify the user against SSO.

Let's consider another example when you want to browse vCloud Director (vCD). Once the client tries to open vCD portal, the page will be redirected to vSphere Web Client to authenticate. Accordingly, vCenter will pass the token to vCD which is used to verify the user against SSO.

SSO Administration

You can manage SSO server using vSphere Web Client. This is done simply  by browsing Web Client and using admin@system-domain account for login. This is the default SSO administrator account created during installation of SSO server.

Note: admin@system-domain account can't be deleted. Only password can be changed which will impact all other components of vSphere Environment.

To verify and modify SSO configuration browse to Administration > Sign-On and Discovery > Configuration.

As mentioned in previous section, SSO can have four types of identity providers:

• System Domain

This is SSO Server acting as identity provider which includes the users defined locally in SSO management console. This identity provider will attached automatically during SSO installation.

To add users locally to SSO server, navigate to Administration > Access > SSO Users and Groups. You can start adding local users to SSO and assign privileges as well. Similarly, you can list all the users from all providers.

• Local Users

Those are the local users defined in the OS where SSO is installed. For example, assuming that your SSO Server is installed in a VM running Windows 2008 Enterprise R2 x64 as OS. The windows server will act as identity provider in SSO including all locally defined users. This identity provider will be attached automatically during SSO installation.

• LDAP

You can attach MS AD server as LDAP identity provider to SSO. All the users defined in the LDAP server based on the search base will be used by SSO server. In case SSO server is installed on a VM/Host which is member of domain,  SSO auto discovers the AD domain and joins it automatically during the SSO install process. Accordingly this AD will be automatically used as identity provider. Multiple AD servers can be added.

• OpenLDAP

Similarly you can attach OpenLDAP servers as identity providers to SSO

Due to the fact that multiple identity providers can be attached to SSO server, SSO server is using UPN authentication against identity providers. This means that the client should enter the user name in UPN format (e.g. admin@system-domain, administrator@ehdf-vcenter-01, ehdfcloud\baqari, etc). Optionally, you can make a provider as default identity provider. In this scenario the client can enter the username without domain. Once the username is received by SSO, it will search against default identity providers ONLY. In case of match, the domain will be automatically attached to username by SSO. In case of no match, the authentication will fail and the username won't be verified against non-default providers. You can have multiple default identity providers but you need to make sure that you don't have overlapped usernames.

To configure default identity provider:

 

You can also control Password Policies and Lockout Policies as well.