Skip to content

SAML (Legacy)

Introduction

SAML (Security Assertion Markup Language) is an open standard for exchanging authentication and authorization data between parties, specifically between an identity provider (IDP) and a service provider (SP). Statista uses SAML to allow users to log in using their institutional credentials, with the statista platform acting as the service provider, integrating with the customer's identity provider.

Technological Overview

The SAML integration is based on both systems, i.e., the Statista platform as the SP and the customer's identity provider, knowing each other through configuration on both sides. However, there is no direct communication between the two systems; instead, the communication occurs via redirects in the user's browser.

SAML supports two methods: SP-initiated SSO and IdP-initiated SSO. In the SP-initiated SSO, the user authentication flow is started in the service provider. In the IdP-initiated SSO, the user starts with a link to the IdP. With the move to the Auth0 login process, the IdP-initiated SSO is used, and SP-initiated SSO is no longer supported.

The SAML integration is currently implemented in the monolith using the lightSAML Bundle, which was last released in 2019.

The following steps illustrate the SAML login flow as implemented on the Statista platform:

  1. The user accesses a SAML login route with an IdP-initiated SSO link pointing to the customer's identity provider.
  2. The user enters their credentials on the identity provider's login page if they are not already authenticated.
  3. Upon successful authentication, the identity provider sends a SAML response (the SAML assertion) to the monolith.
    • The SAML assertion is a message that confirms a user's identity to the service provider. It contains all necessary information for the service provider to verify the user's identity, including the assertion's source, issuance time, and validity conditions.
  4. The monolith validates the SAML assertion.
    • The lightSAML library extracts the username from the SAML assertion and checks if the user exits in the Statista platform using the configured provider that simply queries for the login field of the user.
    • If the user does not exist, a new user is created in the Statista platform with the information provided in the SAML assertion and linked to the group account, see SamlUserCreator
    • LightSAML persists the mapping between the SAML assertion and the Statista user in the database table 'samlIdEntries' using the SamlIdEntry and the IdStore
  5. After successful validation the user is redirected to the sso/idlogin endpoint to initiate the Auth0 ID login process.
    • The id login uses the group account id which is contained in the Id field of the SAML EntityDescriptor. So the login is executed with the group account id.

SAML Login Flow

Configuration

The SAML integration consists of the following configuration components:

  1. Configuration in statista platform:
    • The SAML configuration is provided by the customer in form of an EntityDescriptor. This file is added to the configfrontend under app/Resources/saml/.
    • To enable the SAML entity for a specific customer in a specific environment, the customer's SAML configuration is added to the env specific saml configuration file in the configfrontend, e.g. saml_prod.yaml for production.
    • All configuration required for the lightsaml integration is configured in the saml firewall config section in security.yml file
  2. Configuration in identity provider:
    • The customer configures the statista platform as a service provider in their identity provider system, see SAML 2.0 Confluence page.
  3. Routes: Routes for SAML login are defined in Resources/config/i18n.yml as SAML firewall configuration.

SAML discovery endpoint

The SAML discovery endpoint was the SP initiated SSO link to the customer's identity provider. It is not supported anymore. Now it can be used to check if the customer SAML configuration is valid. The URL looks like https://www.statista.com/samldiscovery/<clientId> and will open the discovery page for that specific client. The page contains a link to the customer's identity provider.

Problems with the current implementation

The current implementation has several problems that need to be addressed in the future:

  • One invalid SAML certificate breaks all SAML logins; automated checks are missing.
  • The lightSAML library has been inactive for years; no documentation is available.
  • ~~Only a group account login is executed at the moment; no differentiation between group account and single user account is possible.~~
  • The SP-initiated login is not supported anymore, which would provide a better user experience.
  • Debugging is hard at the moment.
  • The current implementation uses the ID field of the EntityDescriptor to store the userId, which misuses the intended purpose of the ID field. According to the SAML specification, the ID field is meant to be a document-unique identifier for the element, typically used as a reference point when signing. Storing the userId in this field can lead to issues with SAML validation and interoperability, as the ID field is expected to contain a unique identifier for the SAML document, not user-specific information.
  • Changing/adding customer configurations requires a deployment of the monolith.
  • There is no monitoring on SAML login usage; outdated certificates may not be used anymore.
  • Users are able to request a password reset if they are registered with a randomly generated password. This happens when employees need to have individual accounts while still linked to the group account. This only affects their registration within Statista and is not synced to the activity status on their company/university IDP. (Mitigated to an extent here)

Additional Information

For more details about SAML and its implementation, refer to the official documentation:

  • https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
  • https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
  • https://web.archive.org/web/20160515184903/http://www.lightsaml.com/SP-Bundle/Getting-started/ (archived version of library documentation)

Testing

You can use a link, pretending this is provided by the client's company, where you can log in with the personal "company credentials". We are using Okta to simulate the client's IDP.

Access to our Okta Developer Account

We maintain a developer account that is connected to our test environments. You will need to log in to that account e.g. to assign new users that are able to log in via SAML or to enable/disable applications.

[!NOTE] Note: You will need to enter a MFA OTP token. This can be retrieved from Bitwarden as well.

You can log in to that account with the credentials stored in Bitwarden under the "Okta Developer Account" entry in the "CPE_Internal" folder. Look out for the user name "technik@statista.com".

[!NOTE] Note: We currently can only have five active applications enabled with our free account. Whenever you want to enable an additional application, you might need to disable one first.

Development

Watch out! This application might be disabled in Okta due to our account limitations. Please login to Okta and confirm the "Legacy SAML Local" application is active.

On your local machine you can use the following account:

The application name in Okta is: Legacy SAML Local

Stage / Feature Envs

For our stage environment you can use the following account:

The application name in Okta is: Legacy SAML Stage

Production

Credentials for a production SAML login are stored in the CPE_Internal collection in Bitwarden.

Please contact the UAS team if you need to test SAML in production.

The application name in Okta is: Legacy SAML Production

Test Cases

  • Users can log in via SAML on their company's SAML access web page and are logged in with the correct user.
  • Users receive an error message upon entering a wrong username or password on their company's SAML access web page
Last updated: March 24, 2026 at 10:39
By: Axel Tetzlaff