Skip to main content
Kubex provides the capability to authenticate users through external identity providers, that support the OpenID Connect specification. OpenID provides a framework for communicating between an identity provider and the OpenID acceptor, such as Okta and Microsoft Azure AD. When authenticating users externally, authentication of Kubex users is first delegated to an external identity provider. A user can be authenticated in one of two ways:
  • Local user—The account is created and validated within Kubex. For on-premise deployments, you can configure a local account linked to a Windows® Active Directory™ account to access Kubex. Windows® Active Directory™ is not supported for SaaS deployments.
  • Externally authentication—These users are authenticated through an external identity provider, that support the OpenID Connect specification. Only the following external identity providers are supported:
Once Open ID is enabled, users must exist in their OpenID provider before they can access Kubex. Users that are created in the Kubex user management console must use the same email address as their user ID in Azure, Okta or Google.
Once configured you can access either the Kubex Console or the Analysis Console using the configured connection.
The one exception is Google OpenID. When using Google Open ID, only the Kubex Console is supported. If you try to access the Analysis Console, the connection request will fail. If you need to access the Analysis Console, use AzureAD, Okta or Ping.

Prerequisites

Identity Provider Requirements

Before you can configure the feature in Kubex, you must register Kubex with your identity provider. You need to provide information about the application type, login/logout URLs etc. This is a standard procedure across all applications using OpenID for authentication. Kubex supports: Google OpenID, Microsoft Azure AD, Okta and Ping as external identity providers.

Setting

Description

Application Type

Select Single Page Application (SPA) with Implicit grant type enabled. You must also allow ID Token and Access Token.

If the ID Token or Access Token options are not available, please consult your Identity Provider’s administrator to determine where these are specified, or if they are implicitly set as a part of registering an SPA application with Implicit grant type.

Login redirect URIs:

This is the callback URL to your Kubex instance where the identity provider redirects the user after they have been authenticated.

https://<my-kubex-instance>:443/

The HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with “https”. This prevents tokens from being intercepted during the authorization process.

Logout redirect URIs:

A logout URL is a URL in your Kubex instance that the identity provider can return to after the user has been logged out of the authorization server.

  • https://<my-kubex-instance>/ (for the Kubex Console)
  • https://<my-kubex-instance>:443/admin (for the Analysis Console)
  • https://<my-kubex-instance>:443/openIdError

When using Google OpenID Connect only the following is required:

  • https://<my-kubex-instance>:443/openIdError

Required Scopes

  • Profile
  • Email – If not available, Kubex will use the preferred user name (preferred_username) value of the claim to verify that the user is registered with Kubex. Kubex assumes this is an email address.

Kubex User Configuration

The user’s login ID returned from the identity provider must be in the form of an email address, and this email address must correspond to the email address in the Kubex user ’s profile.

Authentication Code Workflow

When this option is enabled, rather than transmit the user details, the identity provider sends a special, one-time-use authentication code that can be exchanged for an access token. This exchange includes the client_id and client_secret in addition to the authentication code. The Kubex user, attempting to access Kubex is still redirected to their identity provider’s login screen where they enter their credentials. The user must be registered with the identity provider and must have valid credentials to access Kubex. Upon successful login, Kubex validates the user using the ID token returned by the identity provider, as defined by the OpenID Connect specification. Additionally, the identity provider returns an authorization code to the browser. The Kubex web server now uses the supplied authorization code to request an access token. The identity provider validates the authorization code and sends the access token. Validation is completed by Kubex when a user profile with an email address that matches the user’s email address is located in the Kubex database.

Configuring Authentication Code

  1. You must first register Kubex with your identity provider. This is a standard procedure across all applications using OpenID for authentication. See Configuring External User Authentication, above
  2. You now need to provide the following information to Kubex. These settings are all configured for you by Kubex. Contact [email protected] for details.
  • Enable OpenID Connect Authentication
  • OpenID Connect Identity Provider
  • OpenID Connect Authentication Mode
  • OpenID Connect Login URL
  • OpenID Connect ID Token Issuer
  • OpenID Connect Client ID
  • OpenID Connect Client Secret
  • Use static page for OpenID Connect logout
Once the configuration has been completed, both Kubex and the user are verified by your authentication provider and then permitted access to Kubex, upon user login.

Validation Failure

If user validation fails at any point the user is re-directed to a login failure page. This page is configured and managed by the identity provider. Similarly all session timeouts result in a session timeout call to the external identity provider and users are re-directed to the session time out page, that is configured and managed by the identity provider. This feature only applies to the Kubex application and is not applicable to Kubex’s REST API. Validation is only performed on the mandatory fields defined in the OpenID Connect specification. The next section contains the following topics: