SAML SSO with GoodData

This Single Sign-On (SSO) implementation is based on SAML (Security Assertion Markup Language) and allows your application to sign in an existing GoodData user. 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 Scenario

GoodData supports SAML Identity Provider-initiated scenario only:

Supported SAML Authentication Services

The GoodData platform supports the following authentication services:

Implementation Process

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

This article assumes that you access your projects 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, include the following:

    • The IdP metadata file
    • 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.


  3. GoodData deploys your SSO provider to the production environment. You receive a unique SSO parameter to use in user provisioning.
    This parameter is SSOProvider 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.

    • 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: Identity Provider-initiated

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

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">