Too many redirects issue

[pmspire]

I looked through what appear to be related (closed) issues, but was not able to find a solution to my problem. I hope you can help.

I have Lasso (compiled binary, not docker container) running on one host, proxied behind NGINX with SSL, with its own hostname (lasso.[domain].com). I have a basic NGINX static site for testing with Lasso, running on a separate host, with its own hostname (foo.[domain].com), also with SSL. I've tried to follow several guides for configuring both NGINX and Lasso. Here's what I see:

When I hit the static site in Chrome, I'm redirected to the Google "Sign in" page. In my static site's NGINX access.log, I see the expected 302 redirect to Lasso; Lasso shows no jwt found in request, a 401 from /validate, then a 302 from /login. Back in the browser, I enter my email address and password (I've got allowAllUsers: true in my Lasso config.yml, along with a whitelist specifying my email address). My address bar shows https://accounts.youtube.com/accounts/SetSID for a bit, then I get a "too many redirects" error. In the logs, I see a long series of duplicate 302 redirects on the static-site side to that https://accounts.youtube.com/accounts/SetSID address, and on the Lasso side a google userinfo body JSON block that appears to be correct information about my account, but followed by a long series of /auth -> no jwt found in request -> /validate -> /login -> google userinfo body -> [loop]. I have some Lasso debug log output, too, and nothing looks like an error.

Here are what I hope are the relevant portions on my configs:

Static site nginx.conf:

http {

  server {

    listen 443 ssl http2;
    server_name foo.[domain].com;
    root /usr/share/nginx/html;

    ssl_certificate /etc/pki/nginx/server.crt;
    ssl_certificate_key /etc/pki/nginx/private/server.key;

    auth_request /validate;

    location /validate {
      proxy_pass https://lasso.[domain].com;
      proxy_pass_request_body off;
      proxy_set_header Content-Length "";
      auth_request_set $auth_resp_err $upstream_http_x_lasso_err;
      auth_request_set $auth_resp_failcount $upstream_http_x_lasso_failcount;
      auth_request_set $auth_resp_jwt $upstream_http_x_lasso_jwt;
      auth_request_set $auth_resp_x_lasso_user $upstream_http_x_lasso_user;
    }

    error_page 401 = @error401;

    location @error401 {
      return 302 https://lasso.[domain].com/login?url=$scheme://$http_host$request_uri&lasso-failcount=$auth_resp_failcount&X-Lasso-Token=$auth_resp_jwt&error=$auth_resp_err;
    }

    location / {
      auth_request_set $auth_resp_x_lasso_user $upstream_http_x_lasso_user;
      proxy_set_header X-Lasso-User $auth_resp_x_lasso_user;
    }

  }

}

Lasso nginx.conf:

http {

  server {
    listen 443 ssl http2;
    server_name lasso.[domain].com;
    ssl_certificate /etc/pki/nginx/server.crt;
    ssl_certificate_key /etc/pki/nginx/private/server.key;
    location / {
      proxy_set_header Host lasso.[domain].com;
      proxy_pass http://127.0.0.1:9090;
    }
  }

}

Lasso config.yml:

lasso:
  logLevel: debug
  allowAllUsers: true
  whiteList:
  - [address]@[domain].com
  jwt:
    secret: ...
    issuer: Lasso
    maxAge: 1
    compress: true
oauth:
  provider: google
  client_id: ...
  client_secret: ...
  callback_urls:
    - https://lasso.[domain].com/auth

Any ideas where I might be going wrong here?

[bnfinet]

I'm traveling atm but just quickly...

Could you try turning allowAllUsers: true to allowAllUsers: false. If you're using a whitelist, then you don't want allowAllUsers on.

If that doesn't work I can take a closer look tomorrow

[pmspire]

Hi Ben, thanks for responding. I tried allowAllUsers: false, but I still fall into the redirect loop.

I had set allowAllUsers: true with the thought that that, combined with whiteList entries, would let me authenticate a selected set of users from any domain, without setting anything under domains. Is using allowAllUsers: false, no domains section, and a whiteList section the right configuration choice for that?

[bnfinet]

'domains' are the ones that you are managing and is required in this case. It's where the lasso cookie will be set.

…

On Tue, Nov 13, 2018, 4:45 PM Paul Madden ***@***.*** wrote: Hi Ben, thanks for responding. I tried allowAllUsers: false, but I still fall into the redirect loop. I had set allowAllUsers: true with the thought that that, combined with whiteList entries, would let me authenticate a selected set of users from any domain, without setting anything under domains. Is using allowAllUsers: false, no domains section, and a whiteList section the right configuration choice for that? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNK64gbDsQII-4sMPUwaKyaosRMMMFyks5uu1mcgaJpZM4YcfG3> .

[pmspire]

Aha, that's the ticket. Now my (simplified) config works fine:

lasso:
  domains:
    - [domain].com
  whiteList:
    - [my gmail address]
  jwt:
    secret: [secret]
    maxAge: 10080
oauth:
  provider: google
  client_id: [google oauth2 client id]
  client_secret: [google oauth2 client secret]
  callback_urls:
    - https://lasso.[domain].com/auth

Thank you for the clarification. And thanks for Lasso!

[bnfinet]

Glad that it's working. Feel like there's either a documentation bug or possibly a configuration bug here. I'll look at that angle

…

On Tue, Nov 13, 2018, 4:59 PM Paul Madden ***@***.*** wrote: Closed #42 <#42>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNK64apWBeuxUbfvjlA07xT8gIaZ3DCks5uu2rhgaJpZM4YcfG3> .

[brettp]

EDIT: Disregard. I had misunderstood the domains options. Once I set it for ONLY the common top level domain (se.domain.com, instead of domain.com, se.domain.com, and login.se.domain.com) everything worked as expected.

The documentation here is a little confusing in this regard, because it makes it sound like those are the valid domains for callback URLs:

valid domains that the jwt cookies can be set into
the callback_urls will be to these domains

---

I've run into the same problem of infinite redirects, but the solution here (setting the domains) doesn't resolve it. Any suggestions would be appreciated.

The initial redirect to /auth works and resolves the user, but it looks like the forward back to the original URL loses the JWT by the time it hits the /validate endpoint.

Here are relevant logs:
vouch.log
nginx.log

And config files:

Vouch

# vouch config
# bare minimum to get vouch running with OpenID Connect (such as okta)

lasso:
  logLevel: debug
  # domains:
  # valid domains that the jwt cookies can be set into
  # the callback_urls will be to these domains
  domains:
    - se.domain.com
    - login.se.domain.com
    - domain.com

  # - OR -
  # instead of setting specific domains you may prefer to allow all users...
  # set allowAllUsers: true to use Vouch Proxy to just accept anyone who can authenticate at the configured provider
  allowAllUsers: true

oauth:
  # Generic OpenID Connect
  # including okta
  provider: oidc
  client_id: CLIENT_ID
  client_secret: SECRET
  auth_url: https://dev-123456.oktapreview.com/oauth2/default/v1/authorize
  token_url: https://dev-123456.oktapreview.com/oauth2/default/v1/token
  user_info_url: https://dev-123456.oktapreview.com/oauth2/default/v1/userinfo
  scopes:
    - openid
    - email
  callback_url: https://login.se.domain.com/auth

Nginx

log_format hostcombo '$remote_addr - $host - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent"';

server {
    listen 80 ssl http2 default_server;
    server_name se.domain.com;

    access_log  /var/log/nginx/access.log hostcombo;
    error_log /var/log/nginx/error.log debug;

    ssl_certificate /certs/localhost.pem;
    ssl_certificate_key /certs/localhost.key;

    root /usr/share/nginx/html;

    index index.html;

    # send all requests to the `/validate` endpoint for authorization
    auth_request /validate;

    location = /validate {
        internal;

        # Vouch Proxy can run behind the same nginx-revproxy
        # May need to add "internal", and comply to "upstream" server naming
        proxy_pass http://vouch:9090;

        # Vouch Proxy only acts on the request headers
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";

        # pass X-Vouch-User along with the request
        auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user;

        # these return values are used by the @error401 call
        auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt;
        auth_request_set $auth_resp_err $upstream_http_x_vouch_err;
        auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount;
    }

    # if validate returns `401 not authorized` then forward the request to the error401block
    error_page 401 = @error401;

    location @error401 {
        # redirect to Vouch Proxy for login
        return 302 https://login.se.domain.com/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$auth_resp_err;
    }

    # proxy pass authorized requests to your service
    location / {
        proxy_pass http://www.comain.com;
        #  may need to set
        auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user;
        #  in this bock as per https://github.com/vouch/vouch-proxy/issues/26#issuecomment-425215810
        # set user header (usually an email)
        proxy_set_header X-Vouch-User $auth_resp_x_vouch_user;
    }
}

# forwards to vouch
server {
    access_log  /var/log/nginx/access.log hostcombo;

    listen 80 ssl;
    server_name login.se.domain.com;

    ssl_certificate /certs/localhost.pem;
    ssl_certificate_key /certs/localhost.key;

    location / {
       proxy_set_header Host login.se.domain.com;
       proxy_pass http://vouch:9090;
    }
}

[bnfinet]

Usually this is cookie related. Try turning on vouch.testing and make sure the callback, host header, vouch and the domains all align. If that doesn't help please post config, nginx config and logs.

…

On Sat, Jan 26, 2019, 8:05 AM Brett Profitt ***@***.*** wrote: I've run into the same problem of infinite redirects, but the solution here (setting the domains) doesn't resolve it. Any suggestions would be appreciated. The initial redirect to /auth works and resolves the user, but it looks like the forward back to the original URL loses the JWT by the time it hits the /validate endpoint. Here are relevant logs: vouch.log <https://github.com/vouch/vouch-proxy/files/2799176/vouch.log> nginx.log <https://github.com/vouch/vouch-proxy/files/2799177/nginx.log> And config files. config.yml.txt <https://github.com/vouch/vouch-proxy/files/2799179/config.yml.txt> nginx.conf.txt <https://github.com/vouch/vouch-proxy/files/2799178/nginx.conf.txt> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNK67_1lw5IXNfxV9gdIqNVKP1ujJzeks5vHHzRgaJpZM4YcfG3> .

[bnfinet]

Ha! Well you can tell I read that one before I had finished my coffee. Sorry I didn't see the configs and logs in the email. I won't be able to take a look at this closer til tomorrow. Thanks for offering those.

…

On Sat, Jan 26, 2019, 9:24 AM Benjamin Foote ***@***.*** wrote: Usually this is cookie related. Try turning on vouch.testing and make sure the callback, host header, vouch and the domains all align. If that doesn't help please post config, nginx config and logs. On Sat, Jan 26, 2019, 8:05 AM Brett Profitt ***@***.*** wrote: > I've run into the same problem of infinite redirects, but the solution > here (setting the domains) doesn't resolve it. Any suggestions would be > appreciated. > > The initial redirect to /auth works and resolves the user, but it looks > like the forward back to the original URL loses the JWT by the time it hits > the /validate endpoint. > > Here are relevant logs: > vouch.log <https://github.com/vouch/vouch-proxy/files/2799176/vouch.log> > nginx.log <https://github.com/vouch/vouch-proxy/files/2799177/nginx.log> > > And config files. > config.yml.txt > <https://github.com/vouch/vouch-proxy/files/2799179/config.yml.txt> > nginx.conf.txt > <https://github.com/vouch/vouch-proxy/files/2799178/nginx.conf.txt> > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#42 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABNK67_1lw5IXNfxV9gdIqNVKP1ujJzeks5vHHzRgaJpZM4YcfG3> > . >

[brettp]

It was a non-issue. I had misunderstood the domains options (see edit).

Sounds like we both missed our coffees this morning ☕️