. Docs  . Admin Guide  . Single Sign On

Single Sign On

On the Kora Single Sign-On page, in the Security section of the Enterprise Admin Console, you can configure Single Sign-On (SSO) authentication for your enterprise users using any of the following:

  • OpenID Connect
  • Security Assertion Markup Language (SAML)
  • WS-Federation sign-on protocol.

With SSO, your users can log on once, for example, to your company account and the same login credentials can be used by the system. SSO enables easy access to the Kora application using your existing identity provider.

For example, using the WS-Federation sign-on protocol, you can enable a user to sign on to the Kora application using Microsoft® Active Directory® server credentials.

OpenID Connect

Complete the steps in the following procedure to configure SSO using Open ID Connect protocol in the Security module of the Enterprise Admin Console.

  1. In the Security module on the Single Sign-On page in the Enterprise Admin Console, click Enable SSO.
  2. In the Select suitable Sign-On Protocol section, select OpenID Connect.
  3. In the Configure SSO for OpenID Connect section, Configure the settings by selecting an identity provider:
    • Google Sign in
      • No additional configuration is necessary.
      • In order to use certain features in Kora like email lookup, drive lookup and accessing email distribution lists in your domain, service account needs to be configured on behalf of G-Suite System administrator in Google cloud platform and required scopes need to be added for domain-wide delegation of authority. See here for how. Once the given steps are completed, enable the “Configure service account for your G-Suite domain” option and enter the following details:
        • Client Email
        • Private Key
        • Admin Email.
      • You can also enable “Enable Kora users to add auto-generated Google meet link for scheduling meetings” so that while scheduling a meeting, an auto-generated Google Meet link would be added.
    • Office 365 – there are two ways to enable SSO using O365:
      • Authorize Kora azure ID application in your domain – this does not need any further configuration at Kora end. Reach out to your O365 admin to provide required consent for the entire tenant, as needed. For more information – visit this link.
      • Create your own Azure AD client application for Kora and configure the same here. You need to enter the Azure supplied Client Id and Secret. See here on how to register the Kora app with Azure and obtain the required credentials.
      • Additionally you can enable “Enable Kora users to add auto-generated Teams meeting link for scheduling meetings” option for auto-generated meeting links when scheduling meetings.
  4. Click Save.
  5. The Identity Provider information successfully updated message is displayed at the top of the page.

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.

Steps in Configuring SSO using SAML

Complete the following steps to configure Single Sign-On (SSO) using Security Assertion Markup Language (SAML) protocol in the Enterprise Admin Console.

  1. In the Security module on the Single Sign-On page in the Enterprise 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, Configure the settings by selecting an identity provider, and then define the settings for one of:
    • Okta
      1. Single Sign-On URL – The SSO URL for Okta this is to enable Service Provider initiated SAML flow.
      2. Identity Provider Issuer – The entity that provides the user identities including the ability to authenticate a user.
      3. Certificate – The public certificate stored by the service provider from the identity provider used to validate a user signature.
        See here on how to obtain the above values.Okta:
    • OneLogin:
      1. SAML 2.0 Endpoint – The HTTP SSO endpoint for OneLogin to enable Service Provider initiated SAML flow, for example, https://app.onelogin.com/trust/saml2/http-post/sso/358111.
      2. Issuer URL – The URL for the OneLogin issuer, for example,https://app.onelogin.com/saml/metadata/358111.
      3. X.509 Certificate – The public certificate stored by the service provider from the identity provider used to validate a user signature.
        See here on how to obtain the above values.
    • Bitium:
      1. Single Sign-On URL – The HTTP SSO endpoint for Bitium to enable Service Provider initiated SAML flow, for example, https://www.bitium.com/7655.
      2. Issuer URL – The URL for the OneLogin issuer, for example,https://bitium.com/7655/saml/82456/metadata.xml.
      3. Certificate – The public certificate stored by the service provider from the identity provider used to validate a user signature.
        See here on how to obtain the above values.
    • Other – Generic SAML identity provider configuration. Select this option if you are not using a Kora built-in configuration.
      1. Single Sign-On URL – The URL that Kora sends a sign on and sign off requests using your selected identity provider. This is to enable Service Provider initiated SAML flow.
      2. Issuer URL – The URL for the service provider metadata document used for authentication.
      3. Certificate – The public certificate stored by the service provider from the identity provider used to validate a user signature.
      4. 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 Kora and your SSO provider. While the URL names may vary by SSO provider, you will need to define these URLs:
      5. Assertion Consumer Service (ACS) URL or Callback URL as https://idp.kora.ai/authorize/callback.
      6. 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.
      7. Identity URL or Sign-On URL as https://idp.kora.ai
  4. Click Save.
    The Identity Provider information successfully updated message is displayed at the top of the page. To test the configuration, log off the Kora Enterprise Admin Console, and log on again. The configured provider portal should be displayed.

WS-Federation

Complete the steps in the following procedure to configure Single Sign-On (SSO) using the WS-Federation protocol in the Security module of the Enterprise Admin Console.

  1. In the Security module on the Single Sign-On page in the Enterprise Admin Console, click Enable SSO.
  2. In the Select suitable Sign-On Protocol section, select WS-Federation.
  3. In the Configure SSO for WS-Federation section,
    • Configure the settings by selecting an identity provider, and then define the settings for:
      • Windows Azure®
        1. Azure AD Sign-On End Point URL – The URL that Kora sends a sign on and sign off requests using Azure. The response for the authentication is sent to the Reply URL defined in your Azure Active Directory configuration settings.
        2. Azure AD Federation Metadata Document – The URL for the federation metadata document used for authentication with Azure Active Directory.
      • Other – Generic WS-Federation identity provider configuration, other than Azure
        1. AD Sign-On End Point URL – The URL that Kora sends a sign on and sign off requests using your WS-Federation identity provider.
        2. AD Federation Metadata Document URL – The URL for the WS-Federation metadata document used for authentication with Active Directory.
  4. Click Save.
    The Identity Provider information successfully updated message is displayed at the top of the page. To test the configuration, log off the Kora Enterprise Admin Console, and log on again. The SSO provider portal should be displayed.
  5. 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 Kora and your SSO provider. You will need to define these URLs (the URL names may vary by SSO provider):
    • SAML 2.0
      • LDAP Attribute: nameId
      • Claim Attribute: uri
    • SAML 1.1
      • LDAP Attribute: nameId
      • Claim Attribute: emailAddress
    • Assertion Consumer Service (ACS) URL or Callback URL as https://idp.kora.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.

Attributes for ADFS
When you configure Single Sign-On using LDAP for ADFS, in addition to authentication attributes, your third-party SSO provider can send additional attributes to Kora through the Assertion Consumer Service (ACS) URL or Callback URL.
If you are using a built-in Kore.ai app for SSO, such as Windows Azure for WS-Federation protocol, or OneLogin for SAML protocol, required attributes are already configured for Kore.ai when you add the Kore.ai app to your SSO provider admin console.
The following data is an example of attribute data passed to Kore.ai in the callback URL.

<Attribute Name="FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="First Name">
<AttributeValue>Michael</AttributeValue>
</Attribute>
<Attribute Name="LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Last Name">
<AttributeValue>Mehra</AttributeValue>
</Attribute>
<Attribute Name="DisplayName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Display Name">
<AttributeValue>Michael Mehra</AttributeValue>
</Attribute>
<Attribute Name="EmailAddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Email">
<AttributeValue>michael.mehra@acme.com</AttributeValue>
</Attribute>

These attributes are optional except for the EmailAddress, which is required. The Email Address attribute uses the following nameId format:

SAML 2.0:
NameID Format="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
SAML 1.1:
NameID Format="urn:oasis:names:tc:SAML:1.1:nameid:format:emailAddress

Mapping Attributes in ADFS

ADFS is a service provided by Microsoft as a standard role for Windows Server that provides a web login using existing Active Directory credentials. When using SAML or WS-Federation protocols to log on with ADFS, you can pass other values in addition to the authentication values.

The attribute values are defined as Claim Rules in the Relying Party Trust dialog in the SQL Server admin console. To edit the Claim Rules, select the Relying Party Trusts folder in ADFS Management, and then click Edit Claim Rules from the Actions sidebar. To add a new rule, click Add Rule, and then select the Send LDAP Attributes template. Enter the following mapping values:

  • SAML 2.0
    • LDAP Attribute: nameId
    • Claim Attribute: uri
  • SAML 1.1
    • LDAP Attribute: nameId
    • Claim Attribute: emailAddress