@@ -418,6 +418,11 @@ This can be prevented by configuring the [NameID](#nameid) to return a consisten
Ensure that the user who is trying to link their GitLab account has been added as a user within the identity provider's SAML app.
Alternatively, the SAML response may be missing the `InResponseTo` attribute in the
`samlp:Response` tag, which is [expected by the SAML gem](https://github.com/onelogin/ruby-saml/blob/9f710c5028b069bfab4b9e2b66891e0549765af5/lib/onelogin/ruby-saml/response.rb#L307-L316).
The [Identity Provider](#glossary) administrator should ensure that the login should be
initiated by the Service Provider (typically GitLab) and not the Identity Provider.
### Stuck in a login "loop"
Ensure that the **GitLab single sign-on URL** has been configured as "Login URL" (or similarly named field) in the identity provider's SAML app.
...
...
@@ -446,3 +451,25 @@ However, self-managed GitLab instances use a configuration file that supports mo
Internally that uses the [`ruby-saml` library](https://github.com/onelogin/ruby-saml), so we sometimes check there to verify low level details of less commonly used options.
It can also help to compare the XML response from your provider with our [example XML used for internal testing](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/spec/fixtures/saml/response.xml).
### Searching Rails log
With access to the rails log or `production_json.log` (available only to GitLab team members for GitLab.com),
you should be able to find the base64 encoded SAML response by searching with the following filters: