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.

2FA

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.

SAML

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:

https://instana.io/auth/signIn/saml/callback?client_name=SAML2Client\

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

https://instana.io/auth/signIn/saml/callback?client_name=SAML2ClientInstana

Logout URL

We support central, IdP-initiated Logout.

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

https://instana.io/auth/signOut/saml/callback

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:2.5.4.3
  • Check if a first name was provided as one of the following attribute names: firstname/givenname/gn/userfirstname/urn:oid:2.5.4.42
  • Check if a last name was provided as one of the followung attribute names: lastname/sn/userlastname/surname/urn:oid:2.5.4.4

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.

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 @instana.com 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 @gmail.com as this would grant access to everyone with a gmail account.