User name not put into headers

[sciphilo]

When I use this with Okta , while it authenticates, I am unable to get the username in the x-lasso-user header passed to my proxied server. As far as I can see I'm following the instructions laid out in the wiki. I'd just like to verify whether this 'should' work and whether anyone has any ideas what may be wrong here.

Thanks,
Phil

[aaronpk]

Did you configure the generic OIDC provider in the Lasso config? Make sure the user info URL is set there: https://github.com/LassoProject/lasso/blob/master/config/config.yml_example#L80

Also make sure that this bit is set up as well: https://developer.okta.com/blog/2018/08/28/nginx-auth-request#bonus-who-logged-in

[sciphilo]

Thanks for getting back to me.

Here's how I have lasso configured:

oauth:
  # configure only one of the following


  # Generic OpenID Connect
  provider: oidc
  client_id: XXX
  client_secret: YYYY
  auth_url: https://1111.oktapreview.com/oauth2/default/v1/authorize
  token_url: https://1111.oktapreview.com/oauth2/default/v1/token
  user_info_url: https://1111.oktapreview.com/oauth2/default/v1/userinfo
  scopes:
    - openid
    - email
    - profile
  callback_url: https://myhost:9090/auth

That all works- I can successfully authenticate. It's this part which seems to not have any effect:

auth_request_set $auth_user $upstream_http_x_lasso_user;

here's my nginx config:

upstream ds {
	server 10.80.9.11:9999;
}
server {
    listen 9090 ssl;
    server_name myserver;
        ssl_certificate /data/keys/myserver.crt;
    ssl_certificate_key /data/keys/myserver.key;
    location / {
       proxy_set_header Host myserver;
       proxy_pass http://127.0.0.1:9091;
    }
}

server {
    listen 443 ssl;
    server_name myserver;
    ssl_certificate /data/keys/myserver.crt;
    ssl_certificate_key /data/keys/myserver.key;
    add_header Strict-Transport-Security max-age=2592000;

# Any request to this server will first be sent to this URL
auth_request /validate;

location = /validate {

  # This address is where Lasso will be listening on
  proxy_pass https://myserver:9090;
  proxy_pass_request_body off; # no need to send the POST body

  proxy_set_header Content-Length "";
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  # these return values are passed to the @error401 call
  auth_request_set $auth_resp_jwt $upstream_http_x_lasso_jwt;
  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_x_lasso_user $upstream_http_x_lasso_user;
}

error_page 401 = @error401;

# If the user is not logged in, redirect them to Lasso's login URL
location @error401 {
  return 302 https://myserver:9090/login?url=https://$http_host$request_uri&lasso-failcount=$auth_resp_failcount&X-Lasso-Token=$auth_resp_jwt&error=$auth_resp_err;
}



  location / {

	 proxy_pass http://ds;
       proxy_set_header X-Lasso-User $auth_resp_x_lasso_user;
      proxy_set_header X-test mytest;
  }
}

My x-test header gets through fine. But I see no X-Lasso-User in the proxied server, hence my fear that $auth_resp_x_lasso_user isn't populated.

[bnfinet]

I've run into similar issues and it appears to be related to the scope of the variables in the nginx location blocks.

could you try copying

  auth_request_set $auth_resp_jwt $upstream_http_x_lasso_jwt;
  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_x_lasso_user $upstream_http_x_lasso_user;

into the location / block just before the proxy_set_header directives?

[bnfinet]

to verify that the X-Lasso-User header is being set you can browse directly to https://myserver:9090/validate after having logged in once

[sciphilo]

Oh wow, that fixed it. Thanks so much. I needed the block you suggested in the location / block

  location / {

  auth_request_set $auth_resp_jwt $upstream_http_x_lasso_jwt;
  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_x_lasso_user $upstream_http_x_lasso_user;

         proxy_pass http://ds;
        proxy_set_header X-User $auth_resp_x_lasso_user;
        proxy_set_header X-test mytest;
  }

[bnfinet]

So glad that worked, feels like an nginx quirk that should be better documented. My suspicion is that any variables set in a block below / (such as /validate in this case ) are not available to other locations that are above it. However why it works for the @error401 case doesn't seem to be consistent with that notion. Perhaps there's a bug in the overall data structure that the location directives get interpreted into at runtime.

[sciphilo]

Out of interest: Are there other pieces of information (last name etc) that lasso surfaces back into nginx that we can pass on upstream in headers?

[bnfinet]

No not currently though that could be an interesting feature. Please feel free to open an issue to suggest the enhancement.

…

On Thu, Sep 27, 2018, 2:29 PM Phil ***@***.***> wrote: Out of interest: Are there other pieces of information (last name etc) that lasso surfaces back into nginx that we can pass on upstream in headers? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNK67oGFWE3rdFVlNlDEoriVzBA_PjJks5ufUNTgaJpZM4W84Pg> .