Authentication & SSO

This article covers single sign-on (SSO) configuration for both of the following:

• Admin and Member users of the Kentik portal (see About Users).

• Users assigned (by a Kentik customer) to a tenant of the My Kentik Portal.

Notes:

• You must be a Super Admin user (see About Super Admin Users) to administer Authentication and SSO. If you don’t already have a Super Admin user in your organization, please contact [email protected].

• For more detail, see SSO Configuration Overview.

About Authentication & SSO

Password expiration and single sign-on (SSO) are two user authentication methods for enhancing your Kentik account’s security. You can configure both at Settings » Authentication & SSO, which has two main parts:

• Password Expiration Policy: Set a duration for how long passwords remain valid before a reset is required (see Password Expiration Policy).

• Single Sign-on: Set up access to the portal through an external authentication service (see About SSO).

Notes:

• To maintain security, user sessions for Admin and Super Admin accounts automatically expire after 8 hours of inactivity (excludes passive actions like auto-refresh).

• For Member accounts, sessions do not expire due to inactivity. This allows for continuous use in scenarios such as Network Operations Center (NOC) dashboards, where a user might need to view real-time data without manual interaction.

Password Expiration Policy

Kentik’s password policy enforces rules to align with SOC-2 compliance. Password complexity is checked for alll new passwords, whether for new accounts or during password resets. Passwords can also be set to expire after a certain number of days to reduce the risk of unauthorized access. The system prevents password reuse by maintaining a history of the five most recent passwords (see Account Activation UI).

Password Policy UI

The Password Expiration Policy pane contains the following UI elements:

• Password Expiration Duration: A dropdown to set the duration before a password must be reset.

• Disable Password Expiration:

  • If Off (default), password-only users must reset their password according to the configured expiration duration.

  • If On, users won’t be required to reset their password.

About SSO

Single sign-on (SSO) lets Kentik users access the portal with the same credentials they use for other SSO-enabled applications, providing seamless access with one login.

Kentik’s SSO implementation uses the standard SAML2 protocol, also known as “Federated Identity Management.” In this terminology:

• Kentik is the service provider (SP).

• Your SSO is the identity provider (IDP).

SSO Identity Providers

Kentik’s SSO implementation has been successfully tested with the following identity providers (IDPs):

How SSO Works

SSO is a straightforward authentication process. When a user attempts to log in, Kentik redirects them to your organization's IDP for verification. The IDP authenticates the user and sends a SAML2 response back to Kentik. If the response confirms a successful authentication, Kentik logs the user in. If the IDP can't authenticate the user, access to the portal is denied.

SSO Config Prerequisites

To configure your Kentik account for SSO, you must meet the following two requirements:

• Identity provider account: You must have one of the following:

  • Existing identity provider account: An account with an existing SAML2 identity provider (e.g., Okta, OneLogin, Ping Federate, Google G Suite, Duo) and a directory of users.

  • In-house identity management: A self-operated SAML2-compatible IDP or identity gateway, such as Shibboleth.

    Note: For users requiring LDAP or Active Directory as an authentication backend, we recommend Shibboleth, which has open source LDAP and AD extensions.

• Kentik Super Admin user: At least one user in your organization must be Super Admin.

About Super Admin Users

Super Admin have the same capabilities as Admin users, with the following additional privileges:

• Can configure SSO from the portal’s Authentication & SSO page (Settings » Authentication & SSO).

• When SSO is required, Super Admins are the only ones who can still use non-SSO login (e.g., username + password, or username + password + 2FA), allowing a Super Admin to disable SSO in case of an identity provider failure.

• Can turn other users into Super Admin users.

To prevent a single point of failure, we recommend that you set up two Super Admins so that when one is unavailable you can still reach the other. We don’t recommend more than two, however, because it’s wise to restrict the number of users that are allowed to log in using the traditional username/password approach.

Any Admin-level user in a given organization can check who the Super Admin users are by looking at the Level column in the User List (Settings » Users). If no user is assigned a Super Admin role, contact Kentik support ([email protected]) to request that a Super Admin be designated for your organization.

Note: If your organization signed up with Kentik prior to October 2017, the first user registered to your account will be automatically set as a Super Admin (to change, go to Settings » Users).

Kentik SSO Configuration

Configuration of single sign-on (SSO) in Kentik is covered in the following topics.

Note: You must be a Super Admin user to configure SSO in Kentik.

SSO Types

Kentik enables two distinct types of SSO for two distinct groups of Kentik portal users:

• Direct-user SSO: SSO that is managed from Kentik's portal Settings » Authentication & SSO page for Admin and Member users (see About Users).

• Tenant SSO: SSO for users who are assigned by your organization to a tenant of the My Kentik Portal (see About Tenancy).

  • SSO for all tenants in your organization is managed from the My Kentik Portal Single Sign-on page. Click the Settings button on the My Kentik Portal Page (Main Menu » My Kentik Portal) and then select Tenant SSO from the left menu.

SSO Configuration Overview

Some of the configuration steps described in the topics below are performed in your identity provider’s management app while others, depending on SSO type (direct-user SSO or tenant SSO), involve one of the portal pages mentioned in SSO Types.

The settings available on the two SSO configuration pages in the portal are nearly identical, with the following exceptions:

On both pages, the settings include both switches and fields. Before configuration, check that the SSO Enabled switch (at the top of the page) is set to Off (default), so that you can complete the settings before actually turning on SSO.

Complete all of your settings as described in the topics below to begin using SSO by setting the SSO Enabled switch to On. If needed, you can turn SSO Off at any time without losing the settings you’ve made.

Add Kentik to Your IDP

SSO involves two-way communication between Kentik and the identity provider, which requires that each is aware of the other. The information you’ll need to configure your IDP to recognize Kentik as a service provider (SP) is found in the first two fields, which are read-only:

• Service Provider (SP) Entity ID: A unique identifier for Kentik.

• Service Provider (SP) Assertion Consumer Service (ACS) URL: The endpoint of the Assertion Consumer Service at Kentik, which is the URL to which the IDP should posts its response.

Use the button at the right of each field to copy the field's contents so you can paste it into the appropriate form in your IDP.

Note: If you are configuring tenant SSO, you will likely also need (depending on the configuration process for your IDP) the IDs listed in the Tenant ID Name column of the Tenants List on the My Kentik Portal page.

Note that some IDP solutions, including Shibboleth, can take the needed information (SP Entity ID and SP ACS URL) from an XML configuration file. We’ve provided a ready-made config file for that purpose, which you can download directly from the Authentication & SSO page via the Download Kentik SP metadata button.

Configure IDP Settings in Kentik

Once you’ve added Kentik to your IDP, go back to the Authentication & SSO page to set IDP-related settings. As described in How SSO Works, when Kentik requests authentication for a given user, the IDP will return a response. The following controls tell the IDP which fields in that response to use for certain pieces of information, so that when Kentik gets the response, we know where the information will be:

• Identity Provider (IDP) SSO Entry Point URL (required): The name of the field in which the IDP should return the IDP entry-point URL, which is the IDP URL to which Kentik redirects the browser when a user initially attempts to log in.

• Profile Attribute for User Email (required): The name of the field in which the IDP should return the IDP’s email attribute key, which tells Kentik where to find the user’s email in the IDP’s response to an authentication request.

• Profile Attribute for Tenant ID (required; present only for tenant SSO configuration): The name of the field in which the IDP should return the tenant ID, which tells Kentik which tenant the user is associated with.

  Note: Tenant ID is indicated in the Tenant Name column of the Tenants List on the My Kentik Portal page.

• IDP requires encrypted assertions (default = Off): Specify whether or not you want SAML assertions (authentication, attribute, and/or authorization decision statements) in a response from the IDP to be encrypted.

• IDP Public Signing Key (required): The name of the field in which the IDP should return the IDP’s public signing key.

  • If a signing certificate is provided in this field, Kentik will reject any response for which there is either no signature or a signature that can’t be verified.

  • If no signing certificate is provided, then Kentik will not require a signature or attempt to verify signed responses.

  • Notes:

    • Kentik recommends that the value entered in this field be formatted with this web-based tool.

    • The IDP Public Signing Key is required for SSO configuration as of January 27th, 2025.

Configure User-level Behavior

If you are configuring direct-user SSO (not tenant SSO, see SSO Types), in addition to the controls described above you may also want to set the optional Profile Attribute for User Level, which is a field to enter your IDP’s user-level attribute key. If the IDP’s response to an authentication request includes an IDP-specified user level, this setting tells Kentik where to find it. That allows user levels to be managed from the IDP:

• If this field is left blank, or the field is specified but the IDP-provided value is invalid, then the field will be ignored, meaning that the user level will be determined by Kentik’s internal user-level value for the user. The only valid (Kentik-recognized) values for the key are 0 (Member) and 1 (Admin).

• If the IDP does provide a valid level for a given user, at login Kentik’s internally stored user-level value for that user will be overwritten with the IDP-provided value.

  • For example, if a user registered as an Admin in Kentik is identified by IDP as a Member, then that user will become a Member and no longer have access to Admin privileges.

The fact that all values other than 0 (Member) and 1 (Admin) are ignored prevents an existing user level in Kentik from being overwritten with an invalid level from the IDP. It also means (because there is no valid value representing the Super Admin level) that a user’s level can’t be changed to Super Admin via IDP (this is intentional to discourage the automatic creation of excessive Super Admin users).

Keep the following in mind when considering how to manage Kentik user levels with your IDP:

• If the IDP provides a valid user-level profile attribute, then any user level that is changed directly in Kentik (via portal or API) will be reset to the IDP-provided level at the next SSO login.

• If a Super Admin user is included in an IDP group whose user level is collectively set via an IDP user-level profile attribute, then that user will lose Super Admin privileges.

• In cases where the user-level values used by your IDP are not Kentik-valid (e.g., true and false rather than 1 and 0) your IDP may enable you to configure a transform that makes the value Kentik-valid before including it in the SAML assertion sent to Kentik.

Configure Auto-provisioning

The Allow auto-provisioning of new users switch (default = Off) determines what happens when sign-on is attempted by someone who is successfully authenticated by the IDP but is not already registered with Kentik as a user (not listed in Settings » Users):

• If set to On, login will be allowed and the user will be automatically registered with Kentik.

• If Off, login will be denied.

If you decide to use auto-provisioning, you’re most likely to achieve the expected results by considering the following:

• If the Profile Attribute for User Level field is blank or a valid user-level key is not found in the IDP response, then the user level assigned to auto-provisioned users will be Member.

• There is currently no mechanism to auto-provision the Full Name field in Kentik’s internal record for each user. Instead, the Full Name of auto-provisioned users will be set to the IDP-provided email address (see Profile Attribute for User Email in Configure IDP Settings in Kentik), then it can be changed directly in Kentik (portal or API).

• You can’t “auto-deprovision” a user. In other words, removing a user from the IDP does not remove that user from Kentik’s internal list of the organization’s users. That has to be done from the portal (Settings » Users) or via Kentik’s User APIs.

Additional Configuration Options

In addition to the settings above, the following settings can be used to customize the configuration to your organization’s specific needs:

• SSO Required (default = Off):

  • If set to On, all users (except for Super Admins) will be required to log in via SSO.

  • If Off, users may log in with either SSO or standard login.

• Disable 2FA when user has authenticated via SSO (default = Off):

  • If On, two-factor authentication will be disabled whenever SSO is enabled.

  • If Off, 2FA users who sign on via SSO will still need to input a one-time password from their 2FA source (e.g., Google Authenticator or any OTP client).

• Sign outgoing authentication requests (default = Off):

  • If On, all outgoing authentication requests (AuthnRequests) to your IDP are signed with Kentik’s certificate.

  • If Off, all outgoing authentication requests remain unsigned (SAML2 SSO usually requires this to be option to be Off).

    Note: If this setting is enabled, you must update your IDP's configuration annually. Kentik rotates the certificate used for signing requests on October 15th of every year (see Signed Certificate Rotation Process).

• Omit requested authn context from outgoing authentication requests (default = Off):

  • If On, outgoing authentication requests do not contain “authnContext”.

  • If Off, outgoing requests contain “authnContext”.

Signed Certificate Rotation Process

SSO Login Process

Once SSO is enabled, logins will take place at a newly created URL that is specific to your organization. In the following example, company_shortname is a placeholder for the actual value, which is the last segment of the URL shown in the Service Provider (SP) Entity ID or Service Provider (SP) Assertion Consumer Service (ACS) URL field (see Add Kentik to Your IDP):

https://portal.kentik.com/login/sso/company_shortname

When users land on your Kentik SSO login gateway page:

• If they already have a valid active session (as defined by the IDP) they will be automatically logged into the Kentik portal.

• If they don’t already have a current session, they will be redirected to their IDP’s login screen and then back to Kentik Portal upon successful authentication.

Migrating to SSO

The following procedure is the recommended way to transition from plain authentication to SSO:

1. Configure SSO with SSO Required set to Off (default). Perform all of the needed tests and validate the optional features with a single user, typically the staff member (a Super Admin) in charge of SSO.

2. Send an announcement to your organization’s Kentik user base. Include the following:

   1. A clear date on which Kentik access will become SSO-only.

   2. Contact info for the Super Admin, so that users can ask for help before the cutoff date.

   3. The new login URL for Kentik access via SSO [replace the company_shortname placeholder with the last segment of the URL shown in the Service Provider (SP) Entity ID or Service Provider (SP) Assertion Consumer Service (ACS) URL field]:
      https://portal.kentik.com/login/sso/company_shortname

3. On the cutoff date, flip the SSO Required switch to On, after which Kentik users will only be able to log in using the SSO URL.

   Note: Once SSO is required, users attempting non-SSO access (https://portal.kentik.com/login) will be denied access.