Generic SAML login flow

Simpplr can accommodate any Identity Provider (IDP) supporting SAML 2.0. Currently, our native SSO capabilities are tailored for Okta, Azure, Google, OneLogin and Workday.

However, if your org requires SSO with DUO or JumpCloud for example, Simpplr doesn't need to develop dedicated integrations. With a generic SAML 2.0 framework, we can seamlessly support any IDP via a metadata URL.

Simpplr can support and SAML 2.0 or OpenID Connect (OIDC)/OAuth 2.0 identity provider not mentioned above. There are over 100 such SSO/IAM systems, including:

• • Auth0

  • Ping Identity

  • ForgeRock

  • Centrify

  • SecureAuth

Note:

From now on, we will generate read-only values such as the default relay state, ACS URL and Assertion encryption certification (optional) during the SSO setup in Simpplr. Utilizing these values will assist in the correct configuration of the SAML app, eliminating the need for manual creation of the relay state using any encoding tool.

 

SAML 2.0 integration configuration

The following would be required for integration with Zeus:

• Vendor name
• Identity provider entity ID
• Request Signature Method
• Login URL
• Service provider entity ID
• Certificate
• Login identifiers

As your org's Simpplr App manager get started by heading to Manage > Application > Security.

1. In the External IdP (SSO) section, select Custom from the list.
   
2. Fill in the details for:

   • Vendor name

   • Identity provider entity ID

   • Request Signature Method

   • Login URL

   • Service provider entity ID

   • Certificate

   • Login identifiers
     

3. Click Save.

When performing a Custom SSO setup, the following fields are mandatory:

• Vendor name: This should represent the IdP name for which we are configuring the SSO, such as Okta, Azure, JumpCloud, Workday, or Google

Note:

IdP name must be in the correct case like [camelCase or PascalCase].

• Identity provider entity ID: This should be the Identity Provider issuer we received during the setup of the SAML app. For example, when configuring the SAML app in Okta, we obtain the IdP here:
  
• Login URL: This is the login URL generated during the setup of the SAML app

• Certificate: Upload the IdP Certificate for SAML assertion

• Login identifiers: Select at least one login identifier from users' credentials they can use to log in with

These fields are optional: 

• Request Signature Method: This determines the signing algorithm used to digitally sign the SAML assertion and response. By default Simpplr will set it to SHA-256

• Service provider entity ID: This is the application-defined unique identifier that is the intended audience of the SAML assertion. This is most often the SP Entity ID of your application (i.e. Simpplr)

Note:

The SP Entity ID should be setup in this format only - urn:simpplr-app:saml-sp:<tenant-Id>

Read-only values utilized in setting up the SAML App

ACS (Assertion Consumer Service) URL: Previously, we employed a tenant-masked ACS URL on the SAML app, for instance: https://prince.dev-api.simpplr.xyz/v1/accounts/login/saml.

However, moving forward, we will utilize tenant-agnostic URLs, such as https://api.dev.simpplr.xyz/v1/identity/accounts/login/saml?accountId=c309e80d-077f-4e26-aa91-45a646088392. This approach is adopted to streamline the setup of the SAML App and mitigate potential challenges in the event of future custom domain changes.

For example, when configuring the ACS URL in any IdP, like Okta:

Default Relay State: This will be automatically generated on the Simpplr UI for Custom SSO and can be copied and added to the IdP directly.

For example, Adding Default Relay State in any IdP, like Okta:

Assertion Encryption Certificate (Optional): Has identity service’s public key and can be uploaded in the IdP portal for assertion encryption. This is generally an optional setting in the IdP. Identity service would decrypt the assertion if encrypted with the private key it holds. We store the private key in AWS SM as of now.