You are viewing our older product's guide. Click here for the documentation of GoodData Cloud, our latest and most advanced product.

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 SAML Authentication Services

The GoodData platform supports Identity Provides who support SAML 2.0.

While not a complete list, the following authentication services are often used:

Fluig (see Setting up Fluig Single Sign-On)
Okta (see Setting up Okta Single Sign-On)
Auth0 (see Setting up Auth0 Single Sign-On)
Salesforce (see Configure Identity Provider with Salesforce)
AD FS (see Configuring Windows Server with AD FS for GoodData SAML SSO)

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, https://example.com/, 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.
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.

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

Implementation Process

As a domain administrator, you can configure SSO for your workspaces and users through the SSO Providers API.

Access the API endpoints through your GoodData subdomain https://{your-subdomain-name}.gooddata.com. For example, https://example.gooddata.com. If your workspaces use whitelabeling, use your domain address. For example, https://example.com.

Identity Provider-initiated Scenario

The Identity Provider-initiated scenario can be completed from start to finish by a GoodData domain administrator.

Follow these steps:

Build an XML file that contains your 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. The contents will look similar to the following example, but different services may format the content differently:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://samlsso.example.com">
    <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor use="signing">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>MIICSjCCAbOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBCMQswCQYDVQQGEwJjejEO
MAwGA1UECAwFUHJhaGExDTALBgNVBAoMBFRlc3QxFDASBgNVBAMMC2V4YW1wbGUu
Y29tMB4XDTIyMDYxMDA3MzgwOFoXDTIzMDYxMDA3MzgwOFowQjELMAkGA1UEBhMC
Y3oxDjAMBgNVBAgMBVByYWhhMQ0wCwYDVQQKDARUZXN0MRQwEgYDVQQDDAtleGFt
cGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoOiG42600uYrSKZr
/jTK9junQ3ZahRHNByM3Vx0sJ3l0b+fUM44r1Ub/OHrJVM2V973E95sOCPBKfprl
yjPtqBt+1PDlSlqYQE0FIgQiKfFiFLvM14MwdwhpMMq9zlLqOWhy4EIsgTT0Akn7
twamuS89jDmqvRNq2oxGObqVmqsCAwEAAaNQME4wHQYDVR0OBBYEFHGPmgWQAtpB
Mu8oP33rzyB+3Q25MB8GA1UdIwQYMBaAFHGPmgWQAtpBMu8oP33rzyB+3Q25MAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQENBQADgYEAfHfkIYycE1/pALkdtP+GMF2/
jwoS5vyGEtHelRMv8xo2lk86w6PpaqWl8i7s9emu0Rg/XvHCgDukgBy1LVdDCM+z
dsdyW0mK0dp4hQnVD5W8ey4d2tTAafW4D0ThPuRkm0w3FBMqjDasGvXycp0CJzkK
GP2HUgFE0C5sk9UpJFx=</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.example.com/cloudpass/IdPInitPost/example"/>
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://www.example.com/cloudpass/IdPInitRedirect/example"/>
    </md:IDPSSODescriptor>
</md:EntityDescriptor>

Configure the ssoProvider parameter by modifying the following template according to your site parameters from the XML file you generated, and submit a POST request to the endpoint https://{your-subdomain-name}.gooddata.com/gdc/domains/{domainId}/authentication/providers:
```
  {
    "samlProvider": {
      "name": "string",
      "publicKey": "string",
      "issuer": "string",
      "loginUrl": "string",
      "skipAssertionSignatureCheck": false,
      "skipMessageSignatureCheck": false,
      "serviceProviderInitiatedUrl": "string"
    }
  }
```
Where:
- name (String) Specifies the name of the SSO provider. This value becomes a possible value for the ssoProvider parameter. While this value does not need to be the same as the entityID from your SSO XML metadata file, it can be. The SSO provider name must be lowercase and can contain only letters, numbers, dots, and dashes. For example:
```
samlsso.example.com
saml-my.example.com
auth0-my.example.com
```
- publicKey (String) Specifies the value of the public key for your SSO service. This value can be found between the <ds:X509Certificate> tag in the metadata file. Remove any line breaks in the certificate to make it one line. The beginning and end of the certificate must be padded with -----BEGIN CERTIFICATE-----\n and \n``-----END CERTIFICATE-----. If your certificate already includes the beginning and ending declaration tags, you must still add the newline escape \n. For example:
```
"publicKey": "-----BEGIN CERTIFICATE-----\nMIICSjCCAbOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBCMQswCQYDVQQGEwJjejEOMAwGA1UECAwFUHJhaGExDTALBgNVBAoMBFRlc3QxFDASBgNVBAMMC2V.....\n-----END CERTIFICATE-----",
```
  If you do not have a public key, you can omit the public key and update the ssoProvider later. For example:
```
"publicKey": "",
```
- issuer (String) Specifies the entityID. This value must match the value of entityID in the metadata file.
- loginUrl (String) Specifies the address that the user can access the SSO login. This value should match the URL specified within the Location portion of the HTTP-Redirect SAML binding in your XML file. For example:
```
https://www.example.com/cloudpass/SPInitRedirect/example
```
- skipAssertionSignatureCheck (true|false) Specifies whether to skip the validation of the signature contained within the assertion. Set this option according to whether your SSO provider configuration requires the assertion to be validated. For security reasons, if you select true, you should select false for skipMessageSignatureCheck.
- skipMessageSignatureCheck (true|false) Specifies whether to skip the validation of the signature contained within the response. Set this option according to whether your SSO provider configuration requires the message to be validated. For security reasons, if you select true, you should select false for skipAssertionSignatureCheck.
- serviceProviderInitiatedUrl (String) Specifies the address to connect through for SSO user login from within the GoodData platform. When configuring the SSO service for the Identity Provider-initiated scenario, this value is the same as the loginURL.
  For example:
```
{
  "samlProvider": {
    "name": "samlsso.example.com",
    "publicKey": "-----BEGIN CERTIFICATE-----\nMIICSjCCAbOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBCMQswCQYDVQQGEwJjejEOMAwGA1UECAwFUHJhaGExDTALBgNVBAoMBFRlc3QxFDASBgNVBAMMC2V......\n-----END CERTIFICATE-----",
    "issuer": "https://samlsso.example.com",
    "loginUrl": "https://www.example.com/cloudpass/IdPInitRedirect/example",
    "skipAssertionSignatureCheck": false,
    "skipMessageSignatureCheck": false,
    "serviceProviderInitiatedUrl": "https://www.example.com/cloudpass/IdPInitRedirect/example"
  }
}
```
(Optional) Update your security settings by modifying the following template according to your site parameters, and submit a PUT request to the endpoint https://{your-subdomain-name}.gooddata.com/gdc/domains/{domainId}/securitySettings. Because the security settings are cached, it can take as much as two hours from the time you make the update for the settings to refresh with your changes:
```
{
  "securitySettings": {
    "samlSsoProvisioningProviders": [
      "string", "string"
    ],
    "serviceProviderInitiatedSSOProviders": [
      "string"
    ]
  }
}
```
Where:

samlSsoProvisioningProviders (string) Specifies whether to enable Just-in-Time user provisioning for the ssoProvider. More than one ssoProvider can be specified.
serviceProviderInitiatedSSOProviders (string) Specifies the SAML ssoProvider to use for the Service Provider-initiated scenario. There can be only one ssoProvider defined at a time.
For example:
```
{
  "securitySettings": {
    "samlSsoProvisioningProviders": [
      "samlsso.example.com"
    ],
    "serviceProviderInitiatedSSOProviders": [
    ]
  }
}
```

Configure the SSO environment on your side.
- SAML version: 2.0 Versions 1.0 and 1.1 are not supported.
- Post back URL (destination): https://{your-subdomain-name}.gooddata.com/gdc/account/samllogin This is the URL where the SAML response and assertion is consumed.
- Recipient: https://{your-subdomain-name}.gooddata.com/gdc/account/samllogin This is the URL of the assertion consumer.
- Single logout service URL: https://{your-subdomain-name}.gooddata.com/gdc/account/samllogout 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 If you are not able to sign the response, 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.
- 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. For example, /dashboards.
(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).
Use the ssoProvider parameter when provisioning users through the API for managing users. The value is the name of the SSO provider configured during step 2.
Only a domain administrator can create a user with the ssoProvider parameter specified or modify the ssoProvider parameter for an existing user.

Service Provider-initiated Scenario

The Service Provider-initiated scenario can be completed from start to finish by a GoodData domain administrator.

A domain can have only one Service Provider-initiated SSO provider.

Follow these steps:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://samlsso.example.com">
    <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor use="signing">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>MIICSjCCAbOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBCMQswCQYDVQQGEwJjejEO
MAwGA1UECAwFUHJhaGExDTALBgNVBAoMBFRlc3QxFDASBgNVBAMMC2V4YW1wbGUu
Y29tMB4XDTIyMDYxMDA3MzgwOFoXDTIzMDYxMDA3MzgwOFowQjELMAkGA1UEBhMC
Y3oxDjAMBgNVBAgMBVByYWhhMQ0wCwYDVQQKDARUZXN0MRQwEgYDVQQDDAtleGFt
cGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoOiG42600uYrSKZr
/jTK9junQ3ZahRHNByM3Vx0sJ3l0b+fUM44r1Ub/OHrJVM2V973E95sOCPBKfprl
yjPtqBt+1PDlSlqYQE0FIgQiKfFiFLvM14MwdwhpMMq9zlLqOWhy4EIsgTT0Akn7
twamuS89jDmqvRNq2oxGObqVmqsCAwEAAaNQME4wHQYDVR0OBBYEFHGPmgWQAtpB
Mu8oP33rzyB+3Q25MB8GA1UdIwQYMBaAFHGPmgWQAtpBMu8oP33rzyB+3Q25MAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQENBQADgYEAfHfkIYycE1/pALkdtP+GMF2/
jwoS5vyGEtHelRMv8xo2lk86w6PpaqWl8i7s9emu0Rg/XvHCgDukgBy1LVdDCM+z
dsdyW0mK0dp4hQnVD5W8ey4d2tTAafW4D0ThPuRkm0w3FBMqjDasGvXycp0CJzkK
GP2HUgFE0C5sk9UpJFx=</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.example.com/cloudpass/IdPInitPost/example"/>
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://www.example.com/cloudpass/IdPInitRedirect/example"/>
    </md:IDPSSODescriptor>
</md:EntityDescriptor>

Configure the ssoProvider parameter by modifying the following template according to your site parameters from the XML file you generated, and submit a POST request to the endpoint https://{your-subdomain-name}.gooddata.com/``gdc/domains/{domainId}/authentication/providers:
```
{
  "samlProvider": {
    "name": "string",
    "publicKey": "string",
    "issuer": "string",
    "loginUrl": "string",
    "skipAssertionSignatureCheck": false,
    "skipMessageSignatureCheck": false,
    "serviceProviderInitiatedUrl": "string"
  }
}
```
Where:
- name (String) Specifies the name of the SSO provider. This value becomes a possible value for the ssoProvider parameter. While this value does not need to be the same as the entityID from your SSO XML metadata file, it can be. The SSO provider name must be lowercase and can contain only letters, numbers, dots, and dashes. For example:
```
samlsso.example.com
saml-my.example.com
auth0-my.example.com
```
- publicKey (String) Specifies the value of the public key for your SSO service. This value can be found between the <ds:X509Certificate> tag in the metadata file. Remove any line breaks in the certificate to make it one line. The beginning and end of the certificate must be padded with -----BEGIN CERTIFICATE-----\n and \n``-----END CERTIFICATE-----. If your certificate already includes the beginning and ending declaration tags, you must still add the newline escape \n. For example:
```
"publicKey": "-----BEGIN CERTIFICATE-----\nMIICSjCCAbOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBCMQswCQYDVQQGEwJjejEOMAwGA1UECAwFUHJhaGExDTALBgNVBAoMBFRlc3QxFDASBgNVBAMMC2V.....\n-----END CERTIFICATE-----",
```
  If you do not have a public key, you can omit the public key and update the ssoProvider later. For example:
```
"publicKey": "",
```
- issuer (String) Specifies the entityID. This value must match the value of entityID in the metadata file.
- loginUrl (String) Specifies the address that the user can access the SSO login. This value should match the URL specified within the Location portion of the HTTP-Redirect SAML binding in your XML file. For example:
```
https://www.example.com/cloudpass/SPInitRedirect/example
```
- skipAssertionSignatureCheck (true|false) Specifies whether to skip the validation of the signature contained within the assertion. Set this option according to whether your SSO provider configuration requires the assertion to be validated. For the Service Provider-initiated scenario, this must be set to false.
- skipMessageSignatureCheck (true|false) Specifies whether to skip the validation of the sigature contained within the response. Set this option according to whether your SSO provider configuration requires the message to be validated. For security reasons, if you select true, you should select false for skipAssertionSignatureCheck.
- serviceProviderInitiatedUrl (String) Specifies the address to connect through for SSO user login from within the GoodData platform. When configuring the SSO service for the Service Provider-initiated scenario, this value is the URL specified within the Location portion of the md:AssertionConsumerService element in your XML file. If the md:AssertionConsumerService element does not exist in your metadata, then this value is the same as the loginURL.
  For example:
```
{
  "samlProvider": {
    "name": "samlsso.example.com",
    "publicKey": "-----BEGIN CERTIFICATE-----\nMIICSjCCAbOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBCMQswCQYDVQQGEwJjejEOMAwGA1UECAwFUHJhaGExDTALBgNVBAoMBFRlc3QxFDASBgNVBAMMC2V......\n-----END CERTIFICATE-----",
    "issuer": "https://samlsso.example.com",
    "loginUrl": "https://www.example.com/cloudpass/IdPInitRedirect/example",
    "skipAssertionSignatureCheck": false,
    "skipMessageSignatureCheck": false,
    "serviceProviderInitiatedUrl": "https://www.example.com/cloudpass/IdPInitRedirect/example"
  }
}
```
Update your security settings by modifying the following template according to your site parameters, and submit a PUT request to the endpoint https://{your-subdomain-name}.gooddata.com/gdc/domains/{domainId}/securitySettings. Because the security settings are cached, it can take as much as two hours from the time you make the update for the settings to refresh with your changes:
```
{
  "securitySettings": {
    "samlSsoProvisioningProviders": [
      "string", "string"
    ],
    "serviceProviderInitiatedSSOProviders": [
      "string"
    ]
  }
}
```
Where:
- samlSsoProvisioningProviders (string) Specifies whether to enable Just-in-Time user provisioning for the ssoProvider. More than one ssoProvider can be specified.
- serviceProviderInitiatedSSOProviders (string) Specifies the SAML ssoProvider to use for the Service Provider-initiated scenario. There can be only one ssoProvider defined at a time.
  For example:
```
{
  "securitySettings": {
    "samlSsoProvisioningProviders": [
      "samlsso.example.com"
    ],
    "serviceProviderInitiatedSSOProviders": [
    ]
  }
}
```
Enable the showServiceProviderInitiatedLogin by setting its value to 1. You can change the setting by using the API call described in the white labeling setting API documentation.
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): https://{your-subdomain-name}.gooddata.com/``gdc/account/samllogin This is the URL where the SAML response and assertion is consumed.
- Recipient: https://{your-subdomain-name}.gooddata.com/``gdc/account/samllogin This is the URL of the assertion consumer.
- Single logout service URL: https://{your-subdomain-name}.gooddata.com/``gdc/account/samllogout 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
- RelayState: {destination_URI} This is the URI in GoodData where the user is redirected after a successful login. For example, /dashboards.
(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).
Use the ssoProvider parameter when provisioning users through the API for managing users. The value is the name of the SSO provider configured during step 2.
Only a domain administrator can create a user with the ssoProvider parameter specified or modify the ssoProvider parameter for an existing user.

Just-in-Time Provisioning

With Just-in-Time provisioning (JIT), you do not have to create and configure users in advance. JIT creates users when they log in for the first time. For more information, see Use SAML Just-in-Time User Provisioning in a SAML SSO Environment.

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):

<samlp:Response
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination="https://example.on.gooddata.com/gdc/account/samllogin" 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="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha256"/>
      <ds:Reference URI="#RESPONSE_ID">
    <ds:Transforms>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    </ds:Transforms>
    <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256"/>
    <ds:DigestValue>DIGEST_VALUE</ds:DigestValue>
      </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>SIGNATURE_VALUE=</ds:SignatureValue>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <ds:X509Data>
      <ds:X509Certificate>CERT_VALUE</ds:X509Certificate>
    </ds:X509Data>
      </KeyInfo>
      </ds:Signature>
      <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
      </samlp:Status>
      <Assertion ID="ASSERTION_ID" IssueInstant="2014-12-09T09:33:15.284Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>ISSUER_ID</Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha256"/>
        <ds:Reference URI="#ASSERTION_ID">
          <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          </ds:Transforms>
          <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256"/>
          <ds:DigestValue>ASSERTION_DIGEST_VALUE</ds:DigestValue>
        </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>SIGNATURE_VALUE</ds:SignatureValue>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <ds:X509Data>
        <ds:X509Certificate>CERT_VALUE</ds:X509Certificate>
          </ds:X509Data>
        </KeyInfo>
     </ds:Signature>
     <Subject>
       <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="https://example.on.gooddata.com/gdc/account/samllogin"/>
      </SubjectConfirmation>
     </Subject>
     <Conditions NotBefore="2014-12-09T09:33:15.284Z" NotOnOrAfter="2014-12-09T10:33:15.284Z">
       <AudienceRestriction>
         <Audience>example.on.gooddata.com</Audience>
        </AudienceRestriction>
      </Conditions>
      <AuthnStatement AuthnInstant="2014-12-09T09:33:15.191Z" SessionIndex="ASSERTION_ID">
        <AuthnContext>
          <AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
        </AuthnContext>
       </AuthnStatement>
  </Assertion>
</samlp:Response>

Setting up Fluig Single Sign-On