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: https://www.dropbox.com/s/uih2u6be1f64ygr/2017-03-15%2010.15%20CCM%20SSO%20Demo.mp4?dl=0

The documentation is here: https://enterprise.comodo.com/security-solutions/digital-certificates/certificate-manager/certificate-manager-support-docs/pdf/Comodo_Certificate_Manager_IdP_integration.pdf

___________________________________________________________________________________________________________

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 cert-manager.com and hard.cert-manager.com). 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: https://docs.google.com/document/d/1QqbPxPdNfY1ZknJhNRJBNnzoQBtk9FJodzYxEoMNlaQ/edit
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 (heimdall.comodo.net) into their metadata. it is a special case since they have something - which we can call "IdP Aggregator"

________________________________________________________________________________________________________

#	Customer	Instance	Status	Date
1	InCommon	cert-manager.com	LIVE
2	Toyota Financial Services	cert-manager.com	LIVE
3	Mayo Clinic	cert-manager.com	LIVE
4	Brinks	cert-manager.com	LIVE
5	Johnson & Johnson	hard.cert-manager.com	LIVE
6	Pearson	hard.cert-manager.com	LIVE
7	Starbucks	hard.cert-manager.com	POC

__________________________________________________________________________________________________________

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” -- http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf ; Section 2.7.3.1 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: https://spaces.internet2.edu/display/InCFederation/Supported+Attribute+Summary)

Attribute Name	Relation in CCM	Additional Notes
eduPersonPrincipalName	Admin'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
mail	Admin's email address within CCM
givenName	Admin's First/Fore Name in CCM
sn	Admin's Last Name in CCM