Internal - CCM and SSO (Single Sign On)

July 30, 2018

Single sign-on (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications.

SAML - Security Assertion Markup Language, XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. Customer must send their metadata for SAML2 IdP to the CCM dev team so they can include it.

Training Video for SSO:

The documentation is here:


The process starts from SAML2 Metadata exchange. So first of all we would need their Identity Provider Metadata (IdP) and we will put in our Service Provider (SP) on instance where they are. (Now we have SP in front of and Than, we will need to share our SP metadata in order to set up their end. Once it is done, SuperAdmin will need to configure IdP on CCM and enable it for a customer. From that moment, customer will be able to invite their users into CCM.

To summarize:

1. Request Customer IdP Metadata and platform used.

2. Send it to Development Team, we will create WCR for Infra to install IdP Metadata onto SP.

3. We will send our SP Metadata to Customer.

4. They will confirm it has been installed to IdP.

5. Super Admin will configure IdP on CCM instance.

6. Super Admin will assign the IdP to a customer account.

7. They are ready to use the integration.


In order to start testing Super Admin need to configure the feature. Here are the steps which need to be done:
1. Go to SuperAdmin/Settings/IdPs
2. Open needed IdP for Edit
3. Enable "Multi-factor Authentication" feature
4. Provide exact name of the attribute received by Comodo Service Provider from InCommon IdP
"Auth Method Class Name" and value which is required for MRAO/RAO login "Auth Method Class Name"
5. Save settings
After configuration complete, CCM will not allow login for MRAO/RAO until IdP provide required attribute and exact value.
The feature was implemented based on this document:
Example attribute name and value which has been used on our environment for test:
Auth Method Class Name=authnContextClassRef
Auth Method Class Name=urn:oasis:names:tc:SAML:2.0:ac:classes:Password


Incommong have integrated Comodo's IdP ( into their metadata. it is a special case since they have something - which we can call "IdP Aggregator"


2Toyota Financial Servicescert-manager.comLIVE
3Mayo Cliniccert-manager.comLIVE
5Johnson & Johnsonhard.cert-manager.comLIVE




Things we have learned about CCM's SSO offering

ForgeRock / OpenAM – ~ version 13, does not send a NameFormat as part of an attribute statement. CCM needs NameFormat to be set to urn:oasis:names:tc:SAML:2.0:attrname-format:basic

The alleged reason as to why it is not sent, is because the SAML spec says it is optional:

Per the SAML 2.0 specification, the NameFormat field is “optional” -- ; Section Your configuration is not following the SAML 2.0 specification and defaulting to “urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified” when that element is not present. None of our other SSO applications have required that field, and so our IdP is not configured to send it.

as of 13 Feb 2018, Sal is still researching this item.

Optimal IdM (v4.1) requires specifying the NameFormat too under RelyingParty Claims.

IdP will need to send at the very least to CCM: (might be derived from:

Attribute NameRelation in CCMAdditional Notes
eduPersonPrincipalNameAdmin's "IdP Person Id"

This field is CASE SENSITIVE; [email protected] is not the same as [email protected]

This field is only visible IF an IDP is set on their account by an SA & the privileged admin sets the admin to use an IdP

mailAdmin's email address within CCM
givenNameAdmin's First/Fore Name in CCM
snAdmin's Last Name in CCM