Username prefix only available for fallback

[nkostoulas]

Is there any reason that the username claim prefix (oauth.fallback.username.prefix) is only configurable for the fallback username (oauth.fallback.username.claim) and not the primary one (oauth.username.claim)?

The question is mainly focused around Strimzi Brokers but I thought it would be more relevant to ask here. We basically want to use different OAuth ingress listeners that connect to different OAuth servers. Using a different prefix on each OAuth listener would allow to set up authorisation more easily.

I guess it is still technically possible by setting oauth.username.claim to something that might never be there.

[mstruk]

The original use case for adding the fallback prefix configuration was the difference in JWT token claims in tokens obtained from some authorization servers when authenticating with client_credentials vs. refresh_token or password.

I never thought of your use case. It sounds legitimate.

The workaround is exactly like you described.

[nkostoulas]

I noticed you've added oauth.username.prefix prefix in 0.15, thanks! I'll be waiting for it to get adopted by the latest strimzi operator.

I noticed that if oauth.username.claim is set to the empty string then it is ignored, sub isn't used and the fallback is used instead. It wasn't very clear in the docs but I've verified this in Strimzi 0.33. This behaviour really suits us but I wanted to double-check if that is the case.

[mstruk]

Yes. This issue has been addressed by #230.

Can you be more specific about the exact configuration you have?

[nkostoulas]

I have the following configuration in Strimzi:

userNameClaim: ""
fallbackUserNameClaim: "test"
fallbackUserNamePrefix: "prefix_"

I assume this corresponds to:

oauth.username.claim = ""
oauth.fallback.username.claim = "test"
oauth.fallback.username.prefix = "prefix_"

I would have thought that based on documentation if oauth.username.claim is not set then the default sub claim would be used but it seems that when explicitly setting it to "" then the fallback is selected directly.

Well unless my tokens don't even have the sub claim (will check).

[nkostoulas]

Nope - sub is populated on the JWT.

[mstruk]

This is the algorithm which the code should agree with:

• If oauth.fallback.username.claim is configured, but not the oauth.username.claim, it is ignored.
• If neither oauth.username.claim, nor oauth.fallback.username.claim are configured, then sub claim is used as the user id.
• If oauth.username.prefix is configured, but not oauth.username.claim, it is ignored.
• Similarly, if oauth.fallback.username.prefix is configured, but not oauth.fallback.username.claim, it is ignored.
• If oauth.username.claim is configured, it is looked up in the JWT token or Introspection endpoint response.
• If the claim is found and oauth.username.prefix is configured, then the value of the claim is added to the prefix and a result is the user id, otherwise value of the claim becomes the user id as-is.
• If the claim is not found and oauth.fallback.username.claim is configured, then that claim is looked up in the JWT token or the Introspection endpoint response. If that claim is found and oauth.fallback.username.prefix is configured, then the value of that claim is added to the prefix and a result is the user id, otherwise value of that claim becomes the user id as-is.
• If User Info Endpoint is configured and Introspection Endpoint is configured, then if by this point user id has not been established, the request is made to User Info Endpoint and response is processed using the same logic described for the Introspection endpoint response above.
• If after all that the user id has still not been determined, then sub claim is used.

The addition of oauth.username.prefix has not changed current behavior of existing configurations in any way (since they are not using it).

To comment on your example configuration specifically ...

You setting the oauth.username.claim makes it possible for oauth.fallback.username.claim to take effect. With the newly added oauth.username.prefix you could as well rewrite your configuration into:

oauth.username.claim = "test"
oauth.username.prefix = "prefix_"

If you want to use sub claim but also have it prefixed, then you would configure the sub claim explicitly rather than leave it as the final fallback:

oauth.username.claim = "test"
oauth.username.prefix = "prefix_"
oauth.fallback.username.claim = "sub"
oauth.fallback.username.prefix = "prefix_"

Alternatively, we could think here about changing oauth.username.prefix behavior in such a way that it is also applied to the final fallback to sub, but then if oauth.fallback.username.prefix is used, why not use that one when falling back to sub. That isn't intuitive, so I prefer usage of oauth*.username.prefix to be linked to the corresponding oauth*.username with sub fallback completely separate.

In the future the new option will be integrated into Strimzi Operator as userNamePrefix.

[nkostoulas]

ok, thanks!

I only want to use the fallback for now and until the Strimzi Operator supports the userNamePrefix.

I wasn't sure whether setting userNameClaim to "" would cause it to be ignored and look for the sub claim instead or just look for a "" claim that won't exist. It seems to be the latter and that is what I wanted to confirm. I suppose it's not possible to use empty claim names in a JWT token.

[nkostoulas]

@mstruk I think 10d3c0e might have not fixed the issue. I've just upgraded to the 0.40 Strimzi Operator which uses the 0.15 version of this lib and the fallback prefix is still failing.

[nkostoulas]

If oauth.fallback.username.claim is configured, but not the oauth.username.claim, it is ignored.

This might be the reason? I'm trying to validate now.

Before this was introduced I would set oauth.username.claim to "" and the fallback would still work.

[nkostoulas]

Ok it seems setting oauth.username.claim to a random value does the trick 🙂