Skipper: Make query parameter to be passed to OIDC provider on oauthOidc filters redirect

[rraraujo]

Is your feature request related to a problem? Please describe.
No. It is just a feature that would help us.

Describe the solution you would like
We need a way to pass dynamically a query parameter and value to the OIDC provider when the filters do the redirect to the provider.
Our OIDC provider accepts the query parameter "login_hint". The value passed in the parameter will be already set as the username, avoiding the need for it to be typed again.
For a possible simple solution, I was thinking about having a logic near here that could load every query parameter from the Request into authCodeOptions.
As a more elaborated option, we could have a filter field that would have a list of parameters that, if present, should be sent to the provider.

Describe alternatives you've considered (optional)
The user will need to add its username on the OIDC provider page although we already have it.

Would you like to work on it?
Yes

[szuecs]

The link to the code is for configuring a filter, so here you can’t read the query from a request but do you suggest that you add an authcodeoption that if set would read a query from the request to pass it to the auth server?
If so sounds reasonable to me.
I am not sure what the spec says about the usage of authcode options but sounds reasonable to me.

[rraraujo]

Thank you @szuecs. You are right. Maybe it should be inserted here then?

Something like this:

    queryValues := ctx.Request().URL.Query()
    for k := range queryValues {
      f.authCodeOptions = append(f.authCodeOptions, oauth2.SetAuthURLParam(k, queryValues.Get(k)))
    }

[szuecs]

@rraraujo sounds good to me.
@universam1 what do you think about it?

[universam1]

Sounds like a great idea!
I wonder if this would need to be guarded by a feature flag in case the idP does not deal well with potentially included application queries?

[szuecs]

@universam1 as far as I understand the solution will use authCodeOptions to pass it as user input to the filter.
@rraraujo did I understand correctly?

[rraraujo]

Thank you @szuecs and @universam1. Yes, using authCodeOptions was one of the options I mentioned. But, @universam1 is right, the code on my last post was not reflecting this option.

I will create a PR using authCodeOptions then. But just to see if you both have any suggestions, let me explain a possible solution with authCodeOptions.

If an application needs to send the username to idP as a query "login_hint", the filter could have authCodeOptions "login_hint=skipper-request-query". So, skipper will know that "skipper-request-query" is just a placeholder and it should replace it by a request query with the same name before redirecting to the idP.

Would that be good?

[szuecs]

For me this sounds like the best solution. It’s opt-in so we don’t risk any problem others could get as side effect.
We can change it to the default behavior in skipper v1 or after some time doing a poll in slack and mailing list, if nobody cares we can default to it. Please create a follow up issue if you like to have it as default later.

[AlexanderYastrebov]

@rraraujo Should we close this or is there something else left to implement?

[rraraujo]

Yes, sure. Thank you all for this great project!