Authentication redirect loop

[RubyLangdon]

Issue Summary:

We are suddenly in a redirect loop with gitlab auth.

Cloud Provider(s):

AWS

Environment:

Spinnaker v1.18.12
Halyard v1.31.1
Oauth provider is Gitlab
Authz provider type is FILE

Feature Area:

Authentication / authorization

Description:

We suddenly notice that we cannot log in to the spinnaker UI. The browser has a too many redirects error. We've changed nothing, it was working one day and not the next.

If we upgrade to 1.19.10 or 1.20.3 it works fine. (We'd prefer not to upgrade at the moment due to #5701).
When we downgrade back to 1.18.12 it's broken again. The issue also occurred when we tested versions 1.15.5, 1.16.7, and 1.17.10.

We tried flushing the redis cache which didn't help.
We can't see any error logs in any spinnaker pods. Gate debug logs are attached.
gatelogs.txt

Steps to Reproduce:

Contents of gate-local.yaml

security:
  oauth2:
    client:
      clientId: xxxxxx
      clientSecret: xxxxxx
      userAuthorizationUri: https://gitlab.com/oauth/authorize
      accessTokenUri: https://gitlab.com/oauth/token
      scope: read_user openid
      preEstablishedRedirectUri: <our-gate-base-url>/login
    resource:
      userInfoUri: https://gitlab.com/api/v4/user          
    userInfoMapping:        
      email: email
      firstName: ''
      lastName: name
      username: username

Additional Details:

[bcornils]

Hello @RubyLangdon Thanks for filing the issue. Unfortunately, no one is available to work on this at the moment, but we welcome contributions from our community. We strongly encourage you to discuss your plans here or on the SIG's slack channel before you start working on the issue. Additionally, I encourage you to leverage our community in slack. Use the search functionality to find users who have a similar experience, or post a message in #general or another related channel. If no one is able to assist please let us know here. Thank you.

[bcornils]

Hi @RubyLangdon just wanted to check in to see if you found folks to assist in troubleshooting this and/or finding more information regarding root cause.

[RubyLangdon]

Hi @bcornils, so far we haven't made any progress and I haven't managed to find anyone with a similar issue.

[bcornils]

Hi @RubyLangdon I'll bring this to the Security SIG this thursday, please feel free to join us to discuss further.

[alchen99]

@RubyLangdon your scope read_user, userInfoUri, and userInfoMapping is not correct. This will cause an endless redirect loop. Also some tomcat overrides are usually needed. Please try the following in gate-local.yml

server:
  tomcat:
    httpsServerPort: X-Forwarded-Port
    internalProxies: .*
    protocolHeader: X-Forwarded-Proto
    remoteIpHeader: X-Forwarded-For

security:
  oauth2:
    enabled: true
    client:
      clientId: xxxxx
      clientSecret: xxxxx
      accessTokenUri: https://gitlab.com/oauth/token
      userAuthorizationUri: https://gitlab.com/oauth/authorize
      scope: openid,email
    resource:
      userInfoUri: https://gitlab.com/oauth/userinfo
    userInfoMapping:
      email: email
      firstName: name
      lastName: ''      
      username: nickname

[RubyLangdon]

Hi @alchen99, when I try that config I get a gitlab error The redirect URI included is not valid.

In gate-local.yml I also have preEstablishedRedirectUri: https://<my-gate-url>/login and in the gitlab application I have the callback URL set to http://<my-gate-url>/login which works in version 1.19 and 1.20.

[alchen99]

@RubyLangdon unless you have a typo shouldn't your callback URL be https:///login? Is security.apiSecurity.overrideBaseUrl in the ~/.hal/config the same as https:// ? While you are in the redirect loop go to https:///auth/user in the same session. It should return a JSON with some info in it. Check to make sure username is populated.

[RubyLangdon]

That wasn't a typo, we have always had the gitlab application callback URL set to http, and it's https in the hal config overrideBaseUrl.

However if I change the callback URL to https and set everything up as in your example we are back in the same situation of endless redirects.

At the user endpoint https://gitlab.com/api/v4/user I can see that username is populated. At https://gitlab.com/oauth/userinfo I get a 401. I'm actually not sure what the difference is between those two and when they should be used.

[alchen99]

Hmm normally the callback URL should be https if using OAuth/OIDC. I'm actually surprised it allowed you to use http for anything other than localhost as the callback.

Seems like we might have different implementations of the GitLab Applications/Oauth since https://gitlab.com/api/v4/user returns a 401 for me. If https://gitlab.com/api/v4/user returns something for you then you should be fine using it. Just make sure the username is mapped to a field that will never be null.

So it looks like the setup I gave you does not work in 1.18 but does work in 1.19 and onwards. Given that you and I have to use a different userInfoUri and that you said that it just suddenly stopped working I'm guessing that something changed on the GitLab side.

I think you will need to upgrade if you want OAuth to work.

[spinnakerbot]

This issue hasn't been updated in 45 days, so we are tagging it as 'stale'. If you want to remove this label, comment:

@spinnakerbot remove-label stale

[spinnakerbot]

This issue is tagged as 'stale' and hasn't been updated in 45 days, so we are tagging it as 'to-be-closed'. It will be closed in 45 days unless updates are made. If you want to remove this label, comment:

@spinnakerbot remove-label to-be-closed

[spinnakerbot]

This issue is tagged as 'to-be-closed' and hasn't been updated in 45 days, so we are closing it. You can always reopen this issue if needed.