Shibboleth SSO Integration Use Case

CloudCenter Support

Contact CloudCenter Support for additional information.

CloudCenter does not authenticate directly to LDAP or AD.

CloudCenter only interacts with LDAP/AD through a SSO IDentity Provider (IDP) that supports SAML 2.0 protocol (for example, Ping Identity, ADFS, Shibboleth, and so forth).

To implement SSO using CloudCenter:

  1. You must then configure the CCM to re-direct the authentication to the SSO IDP.
  2. You must also map some additional user custom properties (returned by the SAML IDP) to the user activation profile.
  3. Once you complete all these steps successfully, CloudCenter automatically assigns the proper user group membership and additional roles and permissions.


Install Shibboleth

  1. Prepare Ubuntu base image with Tomcat 6. 

    The following instructions are for Tomcat6 (as Tomcat 7 has limitations).

    You can also use Jetty 7, however, the following instruction will differ if you use Jetty.

  2. Download the latest Shibboleth IDP software from here to /shib-distro/.

  3. Unzip the archive :
    sudo unzip /opt/shib-disto/
  4. Copy files from the endorsed directory to Tomcat.
    sudo cp /shib-disto/shibboleth/endorsed/* /usr/local/tomcat6/endorsed/". 
    You may need to make this the endorsed directory:
    sudo mkdir /usr/local/tomcat6/endorsed
  5. Download tomcat6-dta-ssl-1.0.0.jar and copy to TOMCAT_HOME/lib:
    sudo cp /tmp/tomcat6-dta-ssl-1.0.0.jar /usr/local/tomcat6/lib
  6. Install Shibboleth:
    1. cd /shib-distro/shibboleth/
    2. sudo ./
    3. Press Enter to accept default install path of /opt/shibboleth-idp.
    4. Press Enter to accept the Fully Qualified Domain Name (FQDN) of server (for example,
    5. Enter a password to create the keystone.
  7. Turn Off Certificate checking for Attribute requests (see Disabling Web Server CA Validation for Attribute Requests for additional information). The alternative is to make sure certs from your SP (service provider) in our case the CCM server are trusted by Shibboleth.
    1. As root copy the Shibboleth-AnyCert.jar file, which is a security provider for java, to your JRE lib/ext directory.
      cp Shibboleth-AnyCert.jar ${JAVA_HOME}/jre/lib/ext/Shibboleth-AnyCert.jar
    2. Add the following security provider to ${JAVA_HOME}/jre/lib/security/ by adding a line to the security.provider section:

      Step c. is included in Step 8 below when you configure the whole connector. If you do not have an existing truststore, you must create a truststore first.


    3. In your ${CATALINA_HOME}/conf/server.xml file, configure the Attribute Authority Connector that needs client authentication to use the AnyCert truststore algorithm as displayed in the following example:

      <Connector  [... other settings ...]
      Although Tomcat should never use the truststore for this connector, it is also essential to specify a truststore that contains at least one certificate, even if it is a dummy certificate.
  8. Add connectors to Tomcat server.xml.
    1. sudo vi /usr/local/tomcat6/conf/server.xml
    2. Add the connector as below. Replace "PASSWORD" with the password you entered for the IDP key during installation. If you install shibboleth to a different location make sure you update the path in red.

      <Connector port="443"
  9. Instead of copying the WAR file to the ...webapps/ROOT/ location which will expand the WAR file Shibboleth recommends using a context deployment fragment.
    1. Create the file TOMCAT_HOME/conf/Catalina/localhost/idp.xml "sudo vi /usr/local/tomcat6/conf/Catalina/localhost/idp,xml
    2. Add the context information below. If you install to a different location update the path in red. 

      <Context docBase="/opt/shibboleth-idp/war/idp.war"
               swallowOutput="true" />

Configure Shibboleth

There are basically four configuration files for Shibboleth. All reside in /opt/shibboleth-idp/conf/. See IdPAuthUserPass for additional information.

  • attribute-resolver.xml is where we define our authentication sources (in this case Active Directory) and what attributes to pull for users.
  • attribute-filter.xml is where we define what user attributes to release to what SPs.  
  • handler.xml we define how we are going to handle user authentication/sessions.
  • login.config is where we define how to authenticate users.

  1. cd /opt/shibboleth-idp/conf
  2. Add the following to login.config. Update items in red, so they are correct for your active directory setup:
    1. Host is the Active Directory Global Catalog. You can enter multiple servers separated with a space to provide failover/redundancy. If you use multiple hosts for authentication use need to use the same set of multiple servers for attribute resolving
    2. Base is your search base. Update to reflect your domain name. If all users reside under the default Users folder in AD you could use cn=Users,dc=cloudcentertech,dc=local. If user accounts reside in different areas of the domain you may need to use the root or the directory.
    3. Contact CloudCenter Support for the username\password for this account.
    4.  If you need to authenticate against multiple LDAP (AD) directories or disjunctive search bases in the same directory, configure you login.config. See IdPAuthUserPass for additional information.
    5.  A sample login page is located, in the IdP distribution, at src/main/webapp/login.jsp. For information on how to customize the login page, see IdPAuthUserPassLoginPage.

      ShibUserPassAuth {
      edu.vt.middleware.ldap.jaas.LdapLoginModule required

  3. Modify handler.xml
    1. Find and enable the UsernamePassword LoginHandler. Remove the <!-- before the section and the --> after the section to enable the LoginHandler.

      <LoginHandler xsi:type="UsernamePassword"
      PasswordProtectedTransport</AuthenticationMethod> </LoginHandler>
    2. Find and disable the RemoteUser Login Handler. To comment out put <!-- in front and -->at the end of the following section:

      <LoginHandler xsi:type="RemoteUser"
  4. Edit attribute-resolver.xml
    1. Add an LDAP Data Connector to point to Active Directory used to resolve users and their attributes. Enter the following information into the file below
      <!-- LDAP Connector -->.
      The DataConnecter ID your choice, but must be unique to ensure user authentication against multiple sources so you can add more Connectors. You must also reference the ID when you add attributes to resolve users.

      <resolver:DataConnector id="cloudcenterLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
      ldapURL="ldap://" baseDN="dc=cloudcentertech,dc=local"
      <LDAPProperty name="java.naming.referral" value="follow"/>


    2. Add the Name Identifier attribute. The file has an attribute already set to use the transientId. You must set a persistent ID (mapping to the sAMAccountName) as the CloudCenter platform maps the external ID to this attribute (may cause problems if this ID is transient).
    3. Ensure to reference the connector you created under Dependency ref:

       <resolver:AttributeDefinition id="sAMAccountName" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"

              <resolver:Dependency ref="cloudcenterLDAP" />

              <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier"/>

              <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>


    4. Add Attribute Definition resolvers for all applicable user attributes: 
      • The  CloudCenter platform requires the four attributes: the user's first name, last name, email, and User ID (UID).
      • If you want to setup SSO at the root tenant-level and have it also work for first-level sub-tenants, you need an attribute to mark the tenant to which a user should belong.
      • If you want SSO to work for the second-level sub-tenants, you need one more attribute.
    5. Add this under the Data Connector you created to pull the four required attributes.

      Reference the connector created under Dependency ref=. If you use multiple connectors, you will have multiple copies of the attribute resolvers changing the Dependency ref.

      <resolver:AttributeDefinition id="mail" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
      <resolver:Dependency ref="cloudcenterLDAP" />
      <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
      name="urn:mace:dir:attribute-def:mail" />
      <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
      name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" />

      <resolver:AttributeDefinition id="givenName" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
      <resolver:Dependency ref="cloudcenterLDAP" />
      <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
      name="urn:mace:dir:attribute-def:givenName" />
      <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
      name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="givenName" />

      <resolver:AttributeDefinition id="sn" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
      <resolver:Dependency ref="cloudcenterLDAP" />
      <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
      name="urn:mace:dir:attribute-def:sn" />
      <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
      name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="sn" />

      <resolver:AttributeDefinition id="uid" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
      <resolver:Dependency ref="cloudcenterLDAP" />
      <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
      name="urn:mace:dir:attribute-def:uid" />
      <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
      name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="uid" />

    6. All the required attributes (at a minimum, the four required CloudCenter attributes) are published to the Global Catalog. Not all attributes are published automatically. If you use additional attributes, make sure that these attributes are also published to the Global Catalog.
    7. See the default attributes inside AD and include a Global Catalog column, so you can verify if it in the Global Catalog by default.
    8. To change attribute replicate, see Global Catalogs and the Partial Attribute Set.
    9. Add a new schema class or attribute definition.
    10. If you want to configure SSO to authenticate users from multiple AD domains, see IdPMultipleLDAP.

  5. Edit attribute-filter.xml:
    1. Add the following AttributeRules to release the attributes we are going to resolve to the SP (in this case, CloudCenter). Add these after the AttributeFilterPolicy to Release the transient ID to anyone
    2. If you pulled any other attributes add a rule to release them as well.

      <afp:AttributeRule attributeID="sAMAccountName">
      <afp:PermitValueRule xsi:type="basic:ANY"/>

      <afp:AttributeRule attributeID="mail">
      <afp:PermitValueRule xsi:type="basic:ANY"/>

       <afp:AttributeRule attributeID="sn">
        <afp:PermitValueRule xsi:type="basic:ANY"/>

       <afp:AttributeRule attributeID="givenName">
      <afp:PermitValueRule xsi:type="basic:ANY"/>

       <afp:AttributeRule attributeID="description">
       <afp:PermitValueRule xsi:type="basic:ANY"/>

  6. Restart Tomcat :
    cd /usr/local/tomcat6/bin ./



  • No labels