Configure Authentication

Standard Authentication

Standard authentication with username (email address) and password is the default method securely provided by Instana.

Two-Factor Authentication (2FA)

Instana also offers 2FA to provide increased security. With 2FA activated, a QR code will be shown that should be scanned with an app like Authy, Duo, or Google Authenticator.


NOTE: Once 2FA is activated for an account, the user will have to use the second factor for every login. Please make sure to store scratch codes securely for when there is no device access. Without device and scratch codes, access to Instana is not possible.

SAML Authentication and Authorization

Currently Verified IdPs

The Instana SAML implementation is fully standard compliant and should work with all compliant IdPs. The following IdPs have been verified by our team to work out of the box.

This list is by no means complete and will grow over time as we validate other options:

Quick start guides

Please follow the next few paragraphs for IdPs without a quickstart guide.

Getting Started

Activating SAML requires the creation of a SAML-app for Instana in your IdP. Individual users will be able to access Instana after assigning the newly created app to them.

Users created through SAML will be assigned the "default" role upon creation.

NOTE: Once SAML is activated for a tenant there will be no other way to log into Instana.

We support two ways of configuring Instana and your IdP to enable SAML.

  • Mostly automated by exchanging metadata
  • Manually by entering the required values into your IdP

Both use the same configuration dialog in Instana as the only step required in Instana is to upload the IdP-metadata.

Note The accepted token lifetime for SAML-authentication is 200 days. That means your IdP can send tokens with a lifetime anywhere between 1 and 200 days. This value has been chosen since it covers all the currently known default settings for SaaS and OnPrem-IdPs.


Automatic Configuration of IdP and Instana

Some IdPs provide the capability to activate SAML via a simple exchange of metadata files.

Simply follow these steps to get going:

  1. From the link provided in the configuration dialog, download Service Provider Metadata.
  2. Upload the file to create the required SAML settings.
  3. Download the IdP-metadata from your IdP.
  4. Using the upload button in the configuration UI, provide the IdP-metadata to Instana.
  5. Start using Instana.

Manual Configuration of the the IdP

For manual configuration you will have to type in a few values. We highly recommend to copy'n'paste those values from our configuration UI (see above) to avoid confusion.

The following steps will guide you through the process:

  1. Create SAML-app in your IdP using the values provided in the setup UI.
  2. Download the IdP-metadata from your IdP.
  3. Using the upload button in the configuration UI, provide the IdP-metadata to Instana.
  4. Start using Instana.

The following paragraphs are only here for completeness sake. Please copy and paste the generated values directly from our UI.

Service Provider (SP) Entity ID

The SP entity ID Instana uses when talking to your IdP is your tenant name.

Name ID Format

The SAML Name ID Format must be set to EMAIL.

Assertion Consumer Service / Single SignOn URL

The Assertion Consumer Service (ACS) URL (also called Single SignOn URL in some cases) is a combination of a fixed part from Instana and your tenant name:\

e.g. if your tenant is called instana then the resulting URL would look like this:

Logout URL

We support central, IdP-initiated Logout.

The logout URL has no variable part and can be used directly:

User Name

The user name will be generated from SAML attributes provided by the IdP during login.

We follow the general recommendation of X500-style attributes and their well known aliases.

The following logic is applied to extract a username from the provided attributes:

  • Check if a display name was provided as one of the following attribute names: name/displayname/cn/urn:oid:
  • Check if a first name was provided as one of the following attribute names: firstname/givenname/gn/userfirstname/urn:oid:
  • Check if a last name was provided as one of the followung attribute names: lastname/sn/userlastname/surname/urn:oid:

The displayname takes precedence over all other options. If not found but a frist name, a last name or both of them are found we will use those. If nothing was found we use the the string before the @-sign from NameID (which is the user-eMail) to generate a name.

Name changes are reflected after a user has completely logged out since it requires an exchange with the IdP.

OpenId Connect Authentication and Authorization

The Instana OIDC integration is standard compliant and should therefore be supported by all current OIDC ready IdP's.


The configuration form can be found next to all other auth procedures in the settings section under Authentication -> Identity Providers -> OpenID Connect.


To configure Instana as a service provider for your IdP side application. You need the following values of your IdP.

  • ClientID - This is the identifier assigned to your application by the identity provider.
  • Client Secret - This is a token used by Instana to verify the authenticity of the response from the identity provider. This value is a secret key and should be kept secure.
  • Discovery URL or IdP Metadata - The IdP configuration can either be stored dynamically as discovery url or it can uploaded with a valid static metadata file.
  • Admin/Owner account - An email address of an OIDC account must be entered here. The owner rights are initially granted to this account after the switch to the OIDC flow, all other will be assigned the default rights.

Furthermore, the following values are important for Idp-side configuration.

  • Redirect URL - The redirect URI that you set in the IdP determines where the it sends responses to Instana.
  • End Session URL / Sign out URL - For IdP-initiated logout.

NOTE: Once OIDC is activated for a tenant there will be no other way to log into Instana.

Google Single Sign-On (SSO)

Instead of standard authentication, single sign-on can also be enabled for your organization. We currently support Google as our SSO provider.

In order to activate this authentication method for your organization, a domain filter must be specified under "Management Portal" -> "Tenant Authentication".

Users created through SSO will be assigned the "default" role upon creation.

Enter a domain filter that matches your organization's email address(es). For example, the filter is what we use. Multiple filters can be provided, separated by a comma.

Single Sign-On

To change the SSO settings, you first need to deactivate SSO and then reenable it with the desired changes.

NOTE: Single sign-on is a tenant setting, meaning that once enabled it is active for all of your organization's tenant units. Please make sure to not use a generic filter such as as this would grant access to everyone with a gmail account.