Appendix B: Security : Single Sign-On : Design Considerations
   
Design Considerations
*Use Single Sign-On (SSO) to provide a common service, both internally and externally.
*Need to use a supported IdP from VMware.
*The SAML assertion must contain attributes vCloud Director understands.
*vCloud Director and the IdP must be time synchronized to within a few seconds.
*Verify vCloud Director and the IdP have valid endpoint certificates.
*Use consistent hostname (or IP) when registering with the LookupService.
*If the SSO Server is not accessible and the accessibility issue cannot be resolved, use the SSO repoint tools that are that are that are packaged with the SSO clients such as vCenter and the Web Client.
*Identity Sources: OpenAM, Active Directory Federation Services, Shibboleth.
* Provide a highly available SSO service.
*Deploying vCenter SSO as a cluster means that two or more instances of vCenter Single Sign-On are installed in high availability (HA) mode. vCenter Single Sign-On HA mode is not the same as vSphere HA. All instances of vCenter Single Sign-On use the same database and should point to the same identity sources. Single Sign-On administrator users, when connected to vCenter Server through the vSphere Web Client, see the primary Single Sign-On instance. In this deployment scenario, the installation process grants admin@System-Domain vCenter Server privileges by default, and the installation process creates the user admin@System-Domain to manage vCenter Single Sign-On.
*ESXi 5.1 is not integrated with vCenter Single Sign-On, and you cannot create ESXi users with the vSphere Web Client. You must create and manage ESXi users with the vSphere Client. vCenter Server is not aware of users that are local to ESXi, and ESXi is not aware of vCenter Server users. However, you can configure Single Sign-On to use an Active Directory domain as an identity source, and configure ESXi to point to the same Active Directory domain to obtain user and group information.