SAML SSO with GoodData

This Single Sign-On (SSO) implementation is based on SAML (Security Assertion Markup Language) and allows users of your workspaces to access GoodData without using GoodData-specific credentials. The authentication is done by exchanging authentication and authorization data between the parties, not by username and password.

SAML SSO only supports SHA-2 or higher digital signature algorithms and digest algorithms as part of the assertion. SHA-1 is not supported (see SHA-1 Signature for SAML).


Supported Scenarios

GoodData supports the following SAML federation scenarios:

  • Service Provider-initiated scenario: To access the GoodData platform, users go directly to your GoodData domain webpage (for example,, which acts as the Service Provider). They click the login button and get redirected to the login page of your Identity Provider (for example, Salesforce). After they provide their SSO credentials, they are logged in and get redirected back to the GoodData page where they initially started.

    We recommend that you use the Service Provider-initiated scenario.

  • Identity Provider-initiated scenario: To access the GoodData platform, users have to first go to your Identity Provider webpage (for example, Salesforce). They log in using their SSO credentials and get redirected to the GoodData page that you have set up as the target page to go after a successful login.

Supported SAML Authentication Services

The GoodData platform supports Identity Provides who support SAML 2.0.

The following authentication services are often used:

Implementation Process

A complete implementation requires actions on both sides, yours and GoodData’s.

This article assumes that you access your workspaces at

If you are a white-labeled customer, replace with your white-labeled domain in procedure steps or examples.

The whole process consists of the following steps:

  1. You build an XML file with SAML Identity Provider (IdP) metadata (such as the IdP name, certificate, endpoints).
    You can use any free online tool for building this file. Some authentication services generate this file for you and let you download it.
  2. You send a request to GoodData Support to create an SSO provider.
    In the request:

    • Specify the scenario that you want to use: Service Provider-initiated (recommended) or Identity Provider-initiated.

    • Include the IdP metadata file and the name of the SSO provider that you want to use.

      Pick the SSO provider name that clearly identifies you. Include your domain name (if you are a white-labeled customer, include your top-level white-label domain name), and optionally include a saml/okta/fluig/adfs/auth0 prefix. If you do not provide the SSO provider name, we may use the value of the entityID keyword in the XML file with the metadata.

      The SSO provider name must be lowercase.


      Once created, the SSO provider name cannot be updated.

    • Specify whether you want to allow Just-in-Time provisioning (see Use SAML Just-in-Time User Provisioning in a SAML SSO Environment). If you have multiple SSO providers, you can have JIT provisioning enabled for some or all of them.

    • If the metadata does not contain the md:AssertionConsumerService parameter, include the IdP-Initiated Login URL.
  3. GoodData deploys your SSO provider to the production environment. You receive a unique SSO parameter to use in user provisioning.
    This parameter is named SSOProvider and is used in the API for managing users. Usually, it is the same as your SSO provider name.

    Only a domain administrator can create a user with the ssoProvider parameter specified or modify the ssoProvider parameter for an existing user.

  4. You configure an SSO environment on your side.

    • SAML version: 2.0
      Versions 1.0 and 1.1 are not supported.

    • Post back URL (destination):
      This is the URL where the SAML response and assertion is consumed.

    • Recipient:
      This is the URL of the assertion consumer.

    • Single logout service URL:
      This is the URL that you configure in your Identity Provider to log out a user from GoodData when the Identity Provider initiates Single Logout (SLO).
    • Audience restriction: GoodData

    • Name ID format: EmailAddress

    • Sign response: Yes
      The signing certificate may have a validity period set. If the certificate expires, deliver the renewed certificate or metadata to GoodData.

    • Sign assertion: Yes
      If you are not able to sign the assertion, choose 'No' to let GoodData know.
      The signing certificate may have a validity period set. If the certificate expires, deliver the renewed certificate or metadata to GoodData.

    • Encrypt response: No

    • SSO Init type: Service Provider-initiated (recommended) or Identity Provider-initiated

    • RelayState: {destination_URI}
      This is the URI in GoodData where the user is redirected after a successful login.

  5. (Optional) If your domain is white-labeled, you can customize your SSO configuration (for example, set up your own "Not authorized" or "Log out" page; see Customize the White-Labeled Domain).

Example: SAML Message

The following is an example of the SAML message consumed by the GoodData side (to download this message as an XML file, click here):

    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination="" ID="RESPONSE_ID" IssueInstant="2014-12-09T09:33:15.284Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">ISSUER_ID</Issuer>
  <ds:Signature xmlns:ds=""><ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm=""/>
      <ds:SignatureMethod Algorithm=""/>
      <ds:Reference URI="#RESPONSE_ID">
      <ds:Transform Algorithm=""/>
      <ds:Transform Algorithm=""/>
    <ds:DigestMethod Algorithm=""/>
      <KeyInfo xmlns="">
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
      <Assertion ID="ASSERTION_ID" IssueInstant="2014-12-09T09:33:15.284Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <ds:Signature xmlns:ds="">
        <ds:CanonicalizationMethod Algorithm=""/>
        <ds:SignatureMethod Algorithm=""/>
        <ds:Reference URI="#ASSERTION_ID">
        <ds:Transform Algorithm=""/>
        <ds:Transform Algorithm=""/>
          <ds:DigestMethod Algorithm=""/>
        <KeyInfo xmlns="">
       <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">GOODDATA_USER_LOGIN</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData  NotOnOrAfter="2014-12-09T09:38:15.284Z" Recipient=""/>
     <Conditions NotBefore="2014-12-09T09:33:15.284Z" NotOnOrAfter="2014-12-09T10:33:15.284Z">
      <AuthnStatement AuthnInstant="2014-12-09T09:33:15.191Z" SessionIndex="ASSERTION_ID">
Powered by Atlassian Confluence and Scroll Viewport.