Add idtoken response

[simongottschlag]

Makes it possible to configure the following two headers:

• idToken
• accessToken

If they are empty in the configuration, nothing will be added. If configured, they will be added as response headers.

Example:

vouch:
  headers:
    idToken: x-vouch-idtoken

This will make it possible to use it in nginx like this:

auth_request_set $auth_resp_x_vouch_idtoken $upstream_http_x_vouch_idtoken;

And then use the upstream header to, for example, add it to the backend:

proxy_set_header Authorization "Bearer $auth_resp_x_vouch_idtoken";

[simongottschlag]

Was required to add resource to the ADFS redirect, or else all claims won't be returned.

[bnfinet]

I suspect this should be in #68 :)

[simongottschlag]

Yes, it should! I'm going to try and move it.

[simongottschlag]

@bnfinet I've been able to add it to #68, but I don't think I'll be able to create a PR for idToken without ADFS support (since that's what I'm using).

[bnfinet]

I've been wondering if this should be sub instead of username. Do you have an opinion?

[simongottschlag]

No opinion from my side! :)

[bnfinet]

sorry for the delay in reviewing.

re: headers.idToken and headers.accessToken

could you please add corresponding entries to config/config.yml_example and describe the utility, usage and any security concerns which might be warranted?

[simongottschlag]

I've added it to the config.yml_example as well as comments

[bnfinet]

@simongottschlag thanks again for the contribution. I've made some small adjustments, mostly cosmetic. Could you please test this branch:
https://github.com/vouch/vouch-proxy/pull/new/simongottschlag-add_idtoken_response

[simongottschlag]

I tried it but didn't work. Haven't figured out why yet.
Edit: My bad, it does work - just tried it and seems fine.

[simongottschlag]

By the way, seems like this one should be idpIDToken instead of idpAccessToken: (line 360)

vouch-proxy/pkg/cfg/cfg.go

Lines 359 to 361 in c28fe55

	if !viper.IsSet(Branding.LCName + ".headers.idpIDToken") {
	Cfg.Headers.IdpAccessToken = ""
	}

Tried to change it but didn't make a difference. Need to look at it deeper another day.
Edit: Does work.

[simongottschlag]

Hi,

After testing it again today, it does seem to work. Make sure the change with viper is fixed.

[bnfinet]

thanks so much Simon, I've adjusted the branch to remove those config items. Golang by default will initlaze and element of the struct that is not set to its "zero value". For strings, the zero value is an empty string mystring == "". So it should be safe to remove those.

Could you test one more time and then I'll merge?

[simongottschlag]

Hi,

I had to add to do the following change to get it to work: #78

vouch-proxy/handlers/handlers.go

Lines 648 to 649 in 2487000

	user.IDToken = string(tokenRes.IDToken)
	user.AccessToken = string(tokenRes.AccessToken)

Please remember that I've only tested with ADFS and someone else needs to verify that it works with other providers.

[bnfinet]

Hey Simon,

I need to look a little closer at how User is getting populated and it's elements moved around. In order to extend this feature to all IdPs it may be best to establish an interface and have each ${IdP}User conform.

I'm traveling this week and next so I can't promise that it will happen in short order but I think this is going to be best for the longer term architecture of the user object.

Thanks much!

[pcaro]

+1 for this

[bnfinet]

some of this functionality was implemented in #104 by @artagel

@simongottschlag I'd love it if you cared to chime in on #111 which is more along the lines of where you were storing the info in the User object

But since the upstream tokens can now being passed in the headers I think it fulfills your original requirement. Do let us know if that's not the case.