Tag Archive for sso

SAML explained

October 3, 2021 IT No comments

What does SAML stand for?

Security Access Markup Language

What is SAML used for?

SAML is an XML-based open-standard for transferring identity data between two parties: an identity provider and a service provider. SAML enables Single-Sign On (SSO), a term that means users can log in once, and those same credentials can be reused to log into other service providers. The OASIS Consortium approved SAML v2 in 2005. SAML 2.0 changed significantly from 1.1 and the versions are incompatible.

What is XML used for in relation to SAML?

SAML transactions use Extensible Markup Language (XML) to communicate between the identity provider and service providers. SAML is the link between the authentication of a user’s identity and the authorization to use a service.

How does authentication and authorization work in SAML?

SAML implements a secure method of transferring user authentications and authorizations between the identity provider and service providers. When a user logs into a SAML enabled application, the service provider requests authorization from the appropriate identity provider. The identity provider authenticates the user’s credentials and then returns the authorization for the user to the service provider, and the user is now able to use the application.

SAML authentication is the process of checking the user’s identity and credentials. SAML authorization tells the service provider what access to grant the authenticated user.

What is a SAML provider?

There are two primary types of SAML providers, service provider, and identity provider.

  • The identity provider carries out the authentication and passes the user’s identity and authorization level to the service provider.
  • A service provider needs the authentication from the identity provider to grant authorization to the user.

Advantages of SAML

  • Users only need to sign in once to access several service providers. This means a faster authentication process and the user does not need to remember multiple login credentials for every application.
  • SAML provides a single point of authentication
  • SAML doesn’t require user information to be maintained and synchronized between directories.
  • Identity management best practices require user accounts to be both limited to only the resources the user needs to do their job and to be audited and managed centrally. Using an SSO solution will allow you to disable accounts and remove access to resources simultaneously when needed.

Visualising SAML

SAML Example

SAML uses a claims-based authentication workflow. When a user tries to access an application or site, the service provider asks the identity provider to authenticate the user. Then, the service provider uses the SAML assertion issued by the identity provider to grant the user access.

  1. The user opens a browser and navigates to the service provider’s web application, which uses an identity provider for authentication.
  2. The web application responds with a SAML request.
  3. The browser passes the SAML request to the identity provider.
  4. The identity provider parses the SAML request.
  5. The identity provider authenticates the user by prompting for a username and password or some other authentication factor. NOTE: The identity provider will skip this step if the user is already authenticated.
  6. The identity provider generates the SAML response and returns it to the user’s browser.
  7. The browser sends the generated SAML response to the service provider’s web application which verifies it.
  8. If the verification succeeds, the web application grants the user access.

Installing SSO as part of the vSphere 5.x Upgrade process

July 12, 2013 SSO No comments

ssoicon

SSO

vSphere 5.1 introduces vCenter Single Sign On as part of the vCenter Server management infrastructure. This change affects vCenter Server installation, upgrading, and operation. Authentication by vCenter Single Sign On makes the VMware cloud infrastructure platform more secure by allowing the vSphere software components to communicate with each other through a secure token exchange mechanism, instead of requiring each component to authenticate a user separately with a directory service like Active Directory

How vCenter Single Sign-On Affects vCenter Server Upgrades

  • When you upgrade to vCenter Server 5.1, the upgrade process installs vCenter Single Sign-On first and then upgrades vCenter Server.
  • In upgrades to vCenter Server versions earlier than vCenter Server 5.1, both the local operating system users and Active Directory users that are registered with vCenter Server before the upgrade continue to work with the upgraded vCenter Server. This behavior changes in vCenter Server 5.1.
  • In vCenter Server 5.1, if vCenter Single Sign-On is running on a virtual machine or physical machine that is joined to an Active Directory domain, Single Sign-On will automatically discover the existing Active Directory domain and add it as an identity source during the Single Sign-On installation process. If Single Sign-On is not running on a virtual machine or physical machine that is in the same domain as Active Directory, you must use the vSphere Web Client to log in to vCenter Server and add the Active Directory domain to Single Sign-On.
  • If you install vCenter Single Sign-On and vCenter Server on the same physical machine or virtual machine, Single Sign-On recognizes existing local operating system users. After the upgrade, you can log in to vCenter Server with a registered local operating system user ID.
  • If you install vCenter Single Sign-On and vCenter Server on different hosts or virtual machines, the former local operating system users who managed login access to vCenter Server are not available to Single Sign-On.
  • When you install vCenter Single Sign-On in multisite mode or clustered high availability mode, all pre-upgrade permissions for local operating system users are lost. In vCenter Server 5.1, the term “local operating system users” refers to those local users in the Single Sign-On host machine instead of the vCenter Server host machine or virtual machine.
  • After the upgrade, if no super administrator remains (the administrative user or group for the root folder), you must provide a valid user or group to be used as super administrator during installation. This situation can occur due to changes in user stores from pre-5.1 to 5.1 versions of vSphere.

vCenter Single Sign-On Deployment Modes

vCenter Server provides several ways to deploy vCenter Single Sign-On to best serve your vSphere environment

You can deploy vCenter Single Sign-On in one of three modes.

  • Basic

Basic Mode installs a standalone version of vCenter Single Sign-On. Multiple vCenter Server and Inventory Service instances can point to it. If the Single Sign-On server or the virtual machine hosting the server fails, administrators cannot access vCenter Server, but ESXi hosts continue to function normally. Multiple Active Directory and OpenLDAP instances can be added as identity sources.

  • High Availability Cluster

Cluster Mode installs to two or more vCenter Single Sign-On Instances in High Availability mode. All instances use the same database and point to the same identity sources. Single Sign-On administrator users, when connected to vCenter Server through the vSphere Web Client, will see the primary Single Sign-On instance.

  • Multisite

Multisite is designed for deployments with multiple physical locations. Installing a Single Sign-On instance at each site allows fast access to local authentication-related services. Each Single Sign-On instance is connected to the local instances of the AD (LDAP) servers and has its own database with local users and groups. In each datacenter, you can install Single Sign-On in standalone or clustered mode, pointing to the identity sources in that location.

Multisite deployment is useful when a single administrator needs to administer vCenter Server instances that are deployed on geographically dispersed sites. To view all vCenter Server instances from a single vSphere Web Client, you must configure the vCenter Server instances in Linked Mode.

vCenter Single Sign On Components

vCenter Single Sign On includes these components: STS (Security Token Service), an administration server, vCenter Lookup Service, and the RSA SSPI service.

When you install vCenter Single Sign-On, the following components are deployed.

  • STS (Security Token Service)

The STS service issues Security Assertion Markup Language (SAML) tokens. These security tokens pass information about a system user between an identity provider and a web service. This service enables a user who has logged on through vCenter Single Sign-On to use multiple web-service delivered applications without authenticating to each one.

  • Administration Server

The Administration Server configures the vCenter Single Sign-On server and manages users and groups.

  • vCenter Lookup Service

The Lookup Service contains topology information about the vSphere infrastructure, enabling vSphere components to connect to each other securely.

  • RSA SSPI service

The Security Support Provider Interface ia a Microsoft Windows based API used to perform authentication against Security Support Providers such as NTLM and Kerberos.

Identity Sources for vCenter Server with vCenter Single Sign On

vCenter Server 5.1 with vCenter Single Sign On adds support for several new types of user repository. vCenter Server versions earlier than version 5.1 supported Active Directory and local operating system users as user repositories. vCenter Server 5.1 supports the following types of user repositories as identity sources.

  • Active Directory
  • OpenLDAP
  • Local operating system
  • System

Required vCenter Single Sign-On Database Users

When you use an existing database rather than the database bundled with vCenter Single Sign-On, the installation process requires database users with certain permissions.

When you install Single Sign-On installation using an existing database, the installer requires you to enter the user names and passwords of an existing database administrator and a database user.

When you install Single Sign-On with the bundled Microsoft SQL Server 2008 R2 Express database, the installer creates two users:

  • A database administrator user (for example, RSA_DBA) and password, which are used to set up the Single Sign-On database schema.
  • A database user (for example, RSA_USER) and password, which are used to perform certain steps after the installation. The installer prompts you to enter the passwords for these users.

The RSA_DB is used for creating the schema (DDL) and requires DBO Permissions. RS_USER reads and writes data (Only DML)

Prerequisite for the vCenter Single Sign On Database

  • Create a vCenter Single Sign On database, unless you plan to install the bundled database.
  • If you are using an existing database with your vCenter Single Sign-On installation or upgrade, make sure that the table spaces are named RSA_DATA and RSA_INDEX. Any other table space names will cause the vCenter Single Sign-On Installation to fail.
  • If you are using an existing database for Single Sign On, to ensure that table space is created for the database, run the script rsaIMSLiteDBNameSetupTablespaces.sql. The script is included in the vCenter Server installer download package, at

vCenter Server Installation directory\Single Sign On\DBScripts\SSOServer\Schema\msssql

  • You can run the script prior to the vCenter Server upgrade, or during the upgrade, when you are prompted by the Single Sign On installer. You can leave the installer to run the script, and resume the installer after you run the script.
  • If you are using an existing database for Single Sign On, you must create a database user (RSA_USER) and database administrator (RSA_DBA) to use for the Single Sign On database installation and setup. To create these users, run the script rsaIMSLiteDBNameSetupUsers.sql. The script is included in the vCenter Server installer download package, at

vCenter Server Installation directory\Single Sign On\DBScripts\SSOServer\Schema\msssql

Procedure

  • Log into your SQL Management Server
  • Open SQL Management Studio
  • Double click on the first script

SQLTABLE

  • This will automatically open in SQL Management Studio
  • Read the notes at the top of the script
  • There are several places you need to change paths according to your environment – see below where it says CHANGE ME

sqlscript

  • Next Click Execute on the SQL Management Studio Toolbar
  • It should say Command(s) completed successfully and you should see the newly created RSA Database

rsa

  • Next double click on the second script

SQLUSER

  • This will open in SQL Management Studio and you will need to modify the passwords as you require as per below

sqluserscript

  •  Click Execute
  • It should say Command(s) completed successfully
  • You should now see the following permissions set on the RSA Database Properties

dbperms

  • And check the Default Security in SQL Management Studio to make sure your users have been created

sqlperms2

  • Check the Properties of the RSA_USER account
  • Make sure it is mapped to the RSA Database

rsa1

  • Check the Properties of the RSA_DBA account
  • Make sure it is mapped to the RSA Database

rsa2

Procedure following the vCenter SQL Scripts

  • In the software installer directory, double-click the autorun.exe file to start the installer.
  • Select vCenter™Single Sign On and click Install.

sso_1

  • Follow the prompts in the installation wizard to choose the installer language

sso_2

  • Agree to the end user patent and license agreements.

sso_3

  • Select Create the primary node for a new Single Sign On installation.

sso_4

  • Select Install basic vCenter Single Sign On. Note: Even if you don’t want multiple instances now, you may want them in the future therefore you can keep your options open by selecting the second option – “Create the primary node for a new vCenter Single Sign-On installation

sso_5

  • Set the password for the vCenter Single Sign-On administrator account.
    The password must have at least eight characters, at least one lowercase character, one uppercase character, one number, and one special character.

sso_6

  • Select the database type for vCenter Single Sign-On. I am going to use “Use an existing supported database”

sso_7

  • Enter in the details of your previously created SSO DB and relevant users. If you are using an existing database, enter the JDBC connection information.

sso_14

  • If you get the following error, do the following

sso_9

  • Go to SQL Server Configuration Manager > SQL Server Network Configuration > Protocols for MSSQLSERVER. Double click on TCP/IP and make sure under IPAll, you have the correct SQL Port number.

sso_11

  • and you will get this box

sso_12

  • Note: I had another SQL Instance using 1433 which I had to change to another port number then change my MSSQLSERVER Instance TCP Port to 1433. Note: Restart the relevant services following these changes
  • Also check the following setting. Go to SQL Server Configuration Manager > SQL Server Network Configuration > Right click on Protocols for MSSQLSERVER. Force encryption should be No at the moment

sso_10

  • Enter the FQDN or IP address for the vCenter Single Sign-On host machine.

sso_13

  • (Optional) Enter the SSPI service account information.

sso15

  • You can use the default Windows NetworkService account, or enter the account information for a administrator user. This step applies only if you logged in as a domain account user to install Single Sign-On.
  • Choose a destination folder for installation

sso16

  • Choose your SSL Port

sso_17

  • Ready to Install > Click Install

sso_18

Useful Video Walkthrough courtesy of Christopher Wahl

http://wahlnetwork.com/2013/02/04/successfully-installing-vcenter-sso-part-1-sql-database/

VMware SSO FAQ

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034918