Page History

...

• Dependencies:
  • OpenSAML: Apache 2.0 license

Dev-Testing

For testing the plugin, you may use one of publicly available IdP servers such as SSOCircle etc. or download the IDP ova appliance:

http://packages.shapeblue.com/langur/saml/
http://peoplehome.apache.org/~bhaisaab~rohit/cloudstack/saml/

The IDP appliance has a pre-configured Shibbotleth 2.4.0 server and OpenLDAP.

...

LDAP admin: admin
LDAP password: password 
Hostname: idp.bhaisaab.org
IP: 172.16.154.200

The hostname idp.bhaisaab.org is A record to IP 172.16.154.200, if you need to change the IDPServer appliance IP (say in KVM, VMWare Fusion, VirtualBox), add an entry in your hosts files for idp.bhaisaab.org domain. .org domain. 

Note: After starting the IDP VM, run "sudo ntpdate pool.ntp.org" to update its date/time and make sure that the management server host has same effective time as the IDP server. In case time/date mismatches, the IDP server on single-sign-on will state security errors and fail.

LDAP interface: idp.bhaisaab.org/phpldapadmin
Shibboleth IdP Metadata: idp.bhaisaab.org/idp/shibboleth

To test, build CloudStack, deploydb and deploydb-saml. The SAML plugin is located in the source directory at this location: "plugins/user-authenticators/saml2/"

The deploydb-saml will automatically configure ldap and saml auth plugin in CloudStack to use with this appliance.

...

Import users from LDAP or add them manually. Next authorize the user(s) to use SAML SSO against a IdP server by choosing the correct entity ID.

 Log out , and 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.

...

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. On Firefox, SAML tracer add-on can be used to view the SAML tokens that get exchanged. 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.

Image Added

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.

 Image Added

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.

...