Page History

...

 Log out, select an appropriate IdP server from the list of dropdown (in the default case it will be only one, pre-selected) and enter the domain where your account is, the default domain is the ROOT or / domain. Click on SAML SSO button which will redirect you to the IdP log in page, where upon successful authentication you'll be redirected to CloudStack UI with your user account logged in.

As a compatibility requirement, the SAML SP implementation in CloudStack need to adhere to the SAML profile: http://saml2int.org/profile/current/

There is a strict policy on timestamps and cryptographic token checking using IdP server's public key and SP (CloudStack's) private key, so sometimes upon successful authentication the UI may not get logged in - in this case simply re-login using SAML SSO. By default when the management server starts for the first time, SAML certificates are created and stored in cloud.keystore table.

On every SAML SSO attempt, an entry is recorded in CloudStack's cloud.saml_token table to protect against spoofed log-in attempts or an IdP initiated log in where CloudStack won't know in specific domain the user wishes to log in. Every SAML Request (AuthnRequest) is a XML encoded HTTP-POST request as per the saml2int.org profile, the XML consists of the issuer information (SP information, name, entity ID), a unique ID (securely generated random string) and some security enforcement on how to authenticate the user. In cloud.saml_token table, we store the IdP we will redirect the user to, along with the unique ID used in the XML and the domain name to be later referenced. After successfully authenticated from the IdP/federation login system, a SAML Response is sent to the CloudStack SAML Plugin either as a HTTP-Redirect (GET) or HTTP-POST (POST) request that consists of an XML that has issuer information (IdP entity name, timestamp etc), response information (saml token ID, response to ID), authentication status (success, failure etc) and encrypted and unencrypted attributes. The response ID in the SAML Response is same as the unique ID we generated for the SAML request, this ID can be used to verify from cloud.saml_token table if we generated any authentication response or not, along with the IdP and domain selected if we did request it. Using this information and user attributes parsed from the XML's encrypted or unencrypted attribute nodes, we get the user details (username, domain and IDP name) and if the user is authorized we log in the user by setting appropriate cookies and redirect the browser to CloudStack's UI which checks these cookies and logs in the user. We return error, in case the user is found to be not authorized i.e. either the user was not SAML enabled or not enabled for the specific IdP or just does not exist in the chosen domain.

it consists of   Using saml_token table, we can know if a user wants to access a specific domain upon successful log in, this is useful in case a user has multiple user account with same "username" across several domains. The saml_token table can be flushed after a timeout period.

The SAML IDP metadata of the IDP/Shibbotleth server can be accessed from: https://idp.bhaisaab.org/idp/shibboleth

The SAML SP metadata can be accessed from CloudStack: http://localhost:8080/client/api?command=getSpMetadata

  Using saml_token table, we can know if a user wants to access a specific domain upon successful log in, this is useful in case a user has multiple user account with same "username" across several domains.