The purpose of this article is to address some potential problems which you might encounter during the SSO implementation or in the production itself. We have picked the top 10 topics raised by our customers.
1. How do I connect SSO with GoodData? What kind of SSO provider should I choose?
Are you considering implementing Single-sign-on (SSO) within your domain, but don’t know where to start and what type of SSO provider setup would suit your needs?
For that, we have created a very useful community article called Getting started with SSO that will help you to explore all the SSO scenarios which GoodData supports and pick up the best possible option for your use-case.
2. GoodData Support assistance is needed
If you struggle to troubleshoot your SSO production issues, or you are stuck in your implementation - GoodData Support Team is always here to help you.
However, we strongly recommend you to include some basic necessary information when contacting us. This way you will increase our ability to assist accordingly and also speed up the investigation process.
What we always need:
-
SSO provider name (String specifying the name of your SSO provider)
-
Domain which the particular provider is tied to.
What we might need given the nature of particular issue:
-
SSO issuer you are using (e.g Auth0, Okta, Azure, etc.)
-
error ID / error quote
-
particular user who is trying to log in via SSO
-
timestamp of the logging attempt
3. SSO implementation is self service
No action or technical involvement is needed from the GoodData side during the whole implementation process. If you are creating an SSO record on our end or if you wish to update an existing SSO setup, everything can be configured by your own Domain Admin via our SSO provider API.
4. Expiration/validity of your SSO public key
Please note that GoodData isn’t aware of (doesn’t check) your SSO public key expiration date. It is our customers sole responsibility to generate a new public key and update it on our end before the current key expires. We strongly recommend you to do this in advance to prevent any possible production issues.
5. Both SSO access & standard password access within the same domain?
Customers are often asking whether there is a possibility to have both SSO and Standard authentication options in their GoodData domain at the same time - meaning there would be both SSO & non SSO users. This is definitely possible.
All users in the domain have a specific setting authenticationModes which distinguishes how a particular user can be authenticated. Three options can be set: ‘SSO’, ‘Password’ or both. This way you can divide users who will authenticate via SSO or standard password (or both two options).
If you use multiple SSO providers on your domain (which is also possible), you can specify in user settings multiple SSO providers where the user is assigned to. E.g it would look as follows:
("ssoProvider": "sso_provider_1, sso_provider_2").
6. Authentication modes hierarchy: User > Domain
Do you need to set SSO only access for your whole domain? The setting authenticationModes can be applied on a user level, but also on a domain level. It is important to note that if you need exceptions for some users, user setting is superior to a domain setting. Meaning - you can set a default global authentication mode for a domain but at the same time, particular users can have their own authorisation mode set via Update user API.
7. Password reset is not working
This is related to the same topic as points 5 & 6. There are cases when users aren’t able to log in. When they trigger the password reset function in the UI, no email is sent. This issue is very often caused when user setting authenticationModes is set only to ‘SSO’.
With this setting, users can only log in through their assigned SSO provider(s). They wouldn’t be able to login via standard password method and also no password reset email can be triggered.
NOTE: Domain admin is an exception here, as he can always use standard password authentication no matter the ‘authenticationModes’ setting.
8. Auth0 + GoodData -> Skip assertion or signature check
While creating a SAML SSO provider on our side via API, one of the parameters allows to either skip message or signature check:
“skipAssertionSignatureCheck”: (true/false)
“skipMessageSignatureCheck”: (true/false)
If you are using Auth0 as an issuer, please keep in mind that this SSO provider isn’t able to sign both assertion and message at the same time. Therefore, given your particular implementation, you will need to either skip assertion or message signature check in the above setting. Otherwise, HTTP 400 error is received:
“We cannot login user because the HTTP request doesn't contain valid SAML response”
9. Error: This user cannot be authenticated with provided SSO provider - HTTP 403
Please keep in mind that in order to be able to log into GoodData via SSO, the particular user must have the SSO provider assigned to them in their user settings. Otherwise, the above error will be received as GoodData wouldn’t be able to link a particular user with a particular SSO provider. The above error also occurs when a user tries to authenticate with a different SSO than the one they have assigned to them.
Your Domain Admin can assign an SSO provider to a user with with the following Update user API.
10. Third party cookies in the user's browser
Have you successfully implemented SSO; everything looks correct but for some reason your users cannot access your embedded environment? Perhaps seeing the HTTP 401 error with the below message?
”This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required."
The very root cause might lie in your browser setting. Some modern browsers are now blocking third-party cookies by default. Many web services like GoodData rely on third-party cookies for authentication purposes when offerings are embedded in other sites. You can find more information and how to overcome this issue in the following documentation: Blocking Cookies May Make Embedded GoodData Inaccessible.