Single Sign On (SAML 2.0)

Single Sign On benefits the users and streamlines the access to the IDC content for all the users. SSO integration is good for any organization but especially larger ones with subscriptions to IDC research for their entire workforce. In this situation employes are added to the subscription automatically at the time they try to access the service for the first time. This provides a great user experience and saves the organizations for the hustle of setting up new employees.

The other benefit of SSO integration is to safeguard who can use your subscription. With employees leaving your organization the SSO access guarantees they people who left your organization will no longer be able to access your SSO subscription.

IDC supports Single Sign-On (SSO) via SAML 2.0, allowing enterprise clients to use their own Identity Provider (IdP) for authenticating users into IDC’s applications. This section describes how to integrate your SAML IdP with IDC’s systems, the requirements for the SAML assertions, and specific behaviors (like login initiation and logout).

That means that instead of each user having separate credentials for IDC’s portal, your users can log in with their corporate credentials. When SSO is enabled, IDC’s login page will redirect your users to your Identity Provider for authentication. Upon successful login, they are seamlessly logged into IDC’s site. IDC’s role here is the Service Provider (SP) trusting your Identity Provider (IdP). IDC’s SAML implementation is often referred to as the “IDC CAS” (Central Authentication Service) in documentation.

Any SAML 2.0-compliant IdP should work. Common ones among IDC clients include Microsoft ADFS, Azure AD, Okta, PingFederate, Shibboleth, etc. IDC even provides specific guidance for ADFS in this doc (as it’s a popular choice).

1. Exchange Metadata

You provide IDC with your IdP’s SAML metadata (which includes your IdP entity ID, SSO URL, certificate, etc.). IDC provides you with their SP metadata (entity ID, ACS URL, certificate). This exchange is critical for establishing trust.

2 .Configuration

IDC configures their systems to trust your IdP for your domain (often keyed by a unique company code in their system). You configure your IdP to recognize IDC as a service provider relying party.

3. Attribute Mapping

You ensure your IdP will send the required SAML attributes (user ID, email, names, etc.) that IDC needs.

4. Testing

You test logins (both SP-initiated and IdP-initiated if needed) in a lower environment (IDC usually has a test SAML environment at saml.idc.com for this purpose).

5. Production Rollout

Once verified, you or IDC switch the configuration to production, and your users can start using SSO. IDC will typically disable the old username/password login for those users to enforce use of SSO.

IDC uses a unique identifier for your organization in their SAML system. For example, if your company is “Acme Corp”, you might be assigned a code like ACME123. This code shows up in the metadata URLs and login URLs (e.g., …/saml-metadata/ACME123). It basically scopes the SSO config to your organization.

DC has at least two SAML endpoints:

• Test/Staging: https://saml.idc.com/ – used for initial testing.
• Production: https://www.idc.com/ – the live portal SAML endpoint.
  You will get metadata for both. It’s recommended to test in the test environment first, resolve any issues, then move to production.

Moving on, we will detail the required SAML attributes, how to configure ADFS (as an example), and how login and logout are handled.