OAuth-based Enterprise SSO with Okta or Azure AD

Content Catalyst supports OAuth SSO via Okta or Azure AD Identity Providers (IdPs). 

OAuth-based SSO is suitable for customers who want to control their own authentication and want secure seamless access to services across a range of providers. 

If you want to control authentication to your Content Catalyst site and maybe other services you offer via your own authentication portal for all of your customers, our other proprietary publisher SSO framework will be more suitable.

 

As a first step to trial and setup OAuth SSO, please ask us to enable the required features. 

The following needs to be set on the client side:

• enabling the domain-based registration option
• enabling the account-level SSO option
  
  

OAuth SSO is set up on a per-account basis with one or more domains associated with that account using our trusted domains feature with "enabled for registration" checked.

• For example, the account 123interactive might have the trusted domains 123interactive.com and 123interactive.co.uk, both enabled for registration.
• A domain may be trusted in any number of accounts, but each domain can only be configured for registration in a single account.  i.e. a domain cannot be used for registration into more than one account.

Provisioning, where the user is created in the account if the said user does not already exist, is the default and expected behaviour. 

Setting up SSO for an account

1. To set up SSO for an account raise a ticket with the following information:

Please can we add SSO for a new company?

Company account name: e.g. company456

Identity Provider: Okta or AzureAD

User email domains / trusted domains:  e.g. @company456.com, @company456.org

2. We will generate a unique identifier, and share back with you a callbackURL that you can share with your customer.

3. Your customer will then create an app in their IdP using one of these guides:

Okta: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard_OIDC.htm

Azure AD:

https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app

4. Your customer will then securely share back the IdP configuration settings for you to share with Publish Interactive.

discoveryUrl - used to query provider's configuration.

clientId – the public identifier for the 'app’.

clientSecret – a secret known only to the application and authorisation servers.

5. We will generate the account-specific SSO Keys and finalise the configuration.

Testing the SSO integration

The integration can be tested by going directly to Publish Interactive's SSO auth endpoint using the callbackURL

Deploying the SSO integration

Communicate with your customer that the SSO integration has been set up and tested.

Your customer then grants permission to the relevant users in the company.  This varies by IdP, but generally involves assigning users or user groups to the "app".

Finally, you will enable SSO on that account.

The 'default' claims are enough i.e. the integration works with no further configuration beyond what comes 'out of the box' both for Okta and AzureAD. For reference, these are: name given_name family_name sub email (if Okta) preferred_username (if AzureAD)

As you can see, there is a difference between Okta and AzureAD in how the user's email (used by Content Catalyst as the user's UserID) is passed through. Note that additional claims will be ignored and whilst they will not break the integration it is best practice not to send/include them.