Single Sign On and Off (SSO) onboarding

As an Account owner,

I want to configure our account for Federated Authentication a.k.a. Single Sign On [and Off] (SSO),

So that my colleagues do not have to memorize yet another password,

And can more easily follow current best-practice data and information security practices.

Account | Settings and Permissions (new)

In a new, collapsable section titled “SSO - Single Sign On/Off” (maybe with the subtext “Federated Authentication”), an admin will be able to manage the accounts Identity Providers (IdPs). Each account, by current design, may have 1 Identity Provider (IdP) per Identity Provider Type. The provider_type (and provider_name) can not change once created.

We will provide hints (preferably as inline links [new window] to vendor documentation) as to where in the various IdP cloud dashboard one can find the information required.

Required information for creating any Identity Provider (IdP), regardless of type

• SSO Enabled: sso_enabled (a boolean on an accounts/identity_provider)

• provider type: OIDC (available now), SAML (available now)

• A list of email account domains a.k.a. identifiers

  • NOTE: There is a limitation of 50 identifiers per IdP

• A mapping of “their claim keys” to “our claim keys”

  • The values of said mappings are potentially radically different per account and are per provider type

  • Examples of ours versus theirs:

    • email = email

• Information specific to the provider type (see below for provider specific details and mocks there-of

Required information for Identity Providers of type: SAML

• metadata_url

• 

  SSO SAML form

  • identifiers: saml.corestrengths.com

  • email attribute mapping

    • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email

  • metadata url

    • NOTE: DO NOT USE THIS FOR CUSTOMERS

      • https://login.microsoftonline.com/2255232a-4dba-484e-8dad-53bf9950a79d/federationmetadata/2007-06/federationmetadata.xml?appid=96ccd567-a990-4dfc-a331-6e20d5b35291

(deprecated | see dedicated page) Onboarding onelogin.com IdP hints

• OneLogin

  • Configuration

    • Audience (EntityID): urn:amazon:cognito:sp:us-east-1_OEXwI9gqY

    • ACS (Consumer) URL Validator: https://core-cloud-dev.cognito.dev.corestrengths.com/saml2/idpresponse

    • ACS (Consumer) URL: https://core-cloud-dev.cognito.dev.corestrengths.com/saml2/idpresponse

    • Login URL: https://core-cloud-dev.cognito.dev.corestrengths.com/oauth2/authorize?redirect_uri=https://app-dev.corestrengths.com&response_type=code&client_id=438ma1rcb2sf9orgd2dg4cgi41&identity_provider=88112.6bbf08beb616&scope=email openid profile

    • SAML initiator: Service Provider

    • SAML nameID format: Email

    • SAML issuer type: Specific

  • Parameters

    • NamdID value: Email

    • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/family_name: Last Name; (checked) Include in SAML assertion

    • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/given_name: First Name; (checked) Include in SAML assertion

    • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier: Email; (checked) Include in SAML assertion

  • Users

    • TBD

  • Privileges

    • TBD

• Cognito

  • Attribute Mappings

    • 

  • Metadata URL: e.g. https://app.onelogin.com/saml/metadata/520af980-2a08-48f1-8f6c-a94bb83682d1

Required information for Identity Providers of type: OIDC

• client_id

• client_secret

• attributes_request_method

• oidc_issuer

• 

  SSO OIDC form

  • identifiers: oidc.corestrengths.com

  • attribute mapping email: email

  • client id: TODO

  • client secret: REDACTED

  • OIDC Issuer: TODO

Next steps

Once a provider type has been chosen, and the correlated required information fields have been provided, (assuming they clicked CREATE and doing so is a part of the UX), Federated Authentication should be available for this account.

Federated Authentication (SSO) workflows

There are several workflows seen in the wild supporting SSO i.e. workflows people are likely already familiar. The most common is recommended (for MVP) i.e. click a button to be brought to an “SSO login page” (versus our standard user / password / remember me fields).

Workflow: SSO Button (recommended)

Current IAM Authentication page-ish looks very similar to the following mock

Clicking on the SSO tab, for example, would bring one to a new authentication page akin the following mock

Entering an email here allows us to ask Cognito for the correct Identity Provider. Having that, we can redirect to the Federations authentication page. This page is outside of corestrengths.com and manages all the things auth related for said Federation, e.g. logging in, resetting passwords etc. If someone is already logged into this Federation, they are automatically redirected to redirect_uri with a code parameter and whatever state parameter we sent… and technical things begin to happen… ultimately leading to being redirected to our landing page… all on behalf of the person clicking SIGN IN.