1. Home
  2. Kore.ai Conversational Platform
  3. Advanced Topics
  4. Bots Admin Console
  5. Security & Control
  6. Configure Single Sign-On using SAML

Configure Single Sign-On using SAML

Security Assertion Markup Language (SAML) is a standard protocol for web browser Single Sign-On (SSO) using secure tokens. SAML completely eliminates all passwords and instead uses standard cryptography and digital signatures to pass a secure sign-in token from an identity provider to a SaaS application.

SAML provides a solution to allow your identity provider and service providers to exist separately from each other. When a user logs into a SAML enabled application, the service provider requests authorization from the appropriate identity provider. The identity provider authenticates the user’s credentials and then returns the authorization for the user to the service provider, and the user is now able to use the application.

How SAML works

SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed XML documents.

Consider the following scenario: A user is logged into a system that acts as an identity provider. The user wants to log in to a remote application, such as a support or accounting application (the service provider). The following happens:

  1. The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
  2. The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
  3. The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
  4. The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
  5. The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
  6. The identity of the user is established and the user is provided with app access.

Kore.ai Implementation

There are two ways SAML can be used within Kore.ai Bots Platform:

  • For developer authentication to access the Bot Builder,
  • For user authentication to access the Bot.

Use case 1: SAML for bot builder authentication.

Enterprises can set up access to the Bot builder tool using the enterprise SSO. Bot developers and admins can log into bot builder using SSO done by the enterprise identity provider.

SSO flow from Kore.ai Bots platform: The following is the flow within the Kore.ai Bots platform once SSO is configured using SAML:

  1. The client makes a call to Kore app server (using the login URL) with user details to get identity provider info (SAML).
  2. Kore app server initiates a handshake request with the Kore idproxy server.
  3. Kore idproxy server initiates a request to the identity provider (SAML) with user details.
  4. On successful authentication, the identity provider (SAML) returns an assertion response to the Kore idproxy server.
  5. Upon verifying the response from the identity provider, Kore idproxy server initiates a request to the Kore app server.
  6. On successful authentication of the token from Kore idproxy server, Kore app server grants access to the user.

Refer below to configure SSO using SAML

Use case 2: Use SAML for end-user authentication with the bot.

In this scenario, the bot chat interface is embedded on the customer portal or Mobile app that requires user authentication via SSO.  

The Bot access is automatically limited to authenticated users.  If the task requires API invocation that requires SSO based authentication the developer can follow the below steps

  • On the client, developer needs to retrieve SSO token of the logged in user and pass it to the bot using the secureCustomPayload parameter in the Bot SDK API.
  • In the dialog task, Bot developer can write custom logic to read this token and add it as API headers for secure API calls made using service node or webhook node.

The token information on the client varies depending upon the SSO provider and the payload, accordingly the developer would need to write custom logic.

Configuring SSO using SAML

Complete the following steps to configure Single Sign-On (SSO) using Security Assertion Markup Language (SAML) protocol in the Kore.ai Bots Admin Console. Kore.ai also supports WS-Federation and OpenID Connect protocols. For more information, see Using Single Sign-On.

  1. In the Security & Control module on the Single Sign On page in the Bots Admin Console, click Enable SSO.
  2. In the Select a suitable Sign-On Protocol section, select SAML.
  3. In the Configure SSO for SAML section, select an identity provider, and then define the settings for one of:
    1. Okta – For more information, see Configure Kore.ai SSO for Okta.
      • Okta Single Sign-On URL – The SSO URL for Okta.
      • Identity Provider Issuer – The entity that provides the user identities including the ability to authenticate a user.
      • Certificate – The public certificate stored by the service provider from the identity provider used to validate a user signature.
    2. OneLogin – For more information, see Configure Kore.ai SSO for OneLogin, or in the OneLogin documentation, see Configuring SSO for Kore.ai.
      • SAML 2.0 Endpoint – The HTTP SSO endpoint for OneLogin, for example, https://app.onelogin.com/trust/saml2/http-post/sso/358111.
      • Issuer URL – The URL for the OneLogin issuer, for example,https://app.onelogin.com/saml/metadata/358111.
      • X.509 Certificate – The public certificate stored by the service provider from the identity provider used to validate a user signature.
    3. Bitium – For more information, see Configure Kore.ai SSO for Bitium.
      • Single Sign-On URL – The HTTP SSO endpoint for Bitium, for example, https://www.bitium.com/7655.
      • Issuer URL – The URL for the OneLogin issuer, for example,https://bitium.com/7655/saml/82456/metadata.xml.
      • Certificate – The public certificate stored by the service provider from the identity provider used to validate a user signature.
    4. Other – Generic SAML identity provider configuration. Select this option if you are not using a Kore.ai built-in configuration.
      • Single Sign-On URL – The URL that Kore.ai sends sign on and sign off requests using your WS-Federation identity provider.
      • Issuer URL – The URL for the WS-Federation metadata document used for authentication with Active Directory.
      • Certificate – The public certificate stored by the service provider from the identity provider used to validate a user signature.
      • In the administrative console for your Single Sign-On provider, you will also need to define the URLs that are used to exchange data between Kore.ai and your SSO provider. While the URL names may vary by SSO provider, you will need to define these URLs:
        • Assertion Consumer Service (ACS) URL or Callback URL as https://idp.kore.ai/authorize/callback. In addition to authentication values, you must pass the email address of the user as an LDAP attribute from Active Directory when using ADFS. For more information, see Attributes for ADFS.
        • Identity URL or Sign On URL as https://idp.kore.ai
  4. Click Save.

The Identity Provider information successfully updated message is displayed at the top of the page. The following illustration shows the Single Sign On page with SAML sign-on protocol selected:


Was this article helpful to you? Yes No 1