jwt credential does not have "username" but "key"

[davinwang]

Summary

The jwt credential according to its database definition, does not have username but key. The key can be used to represents the authenticated jwt_credential.

Full changelog

• X-Credential-Username is correctly set

Issues resolved

X-Credential-Username is correctly set with jwt credential.key (i.e. iss - jwt issuer) which represents the authenticated jwt credential. Therefore other plugins relying on X-Credential-Username will work.

Fix #XXX

[hishamhm]

@davinwang hi, that is indeed dead code because credential.username doesn't exist so that if statement never enters (so the if condition needs to be changed as well). What use-case do you have in mind in this? Looks like this header code was copied from the ldap-auth plugin and never really worked.

[davinwang]

@hishanmhm hi, my bad, forgot to change the credential.username in if condition ;-)
The scenario is : there is an application server behind Kong, it will extract "x-credential-username" along with "x-consumer-username" from http request header to identify the consumer and credential, regardless the detail authentication method. Some consumer may pass authentication with Basic Auth, some by Jwt Auth, etc. Much appreciate if Kong can provide a consistent behavior between plugins.

[hishamhm]

@davinwang We end up in a strange situation because the JWT key is not really a "username"... I don't know if it wouldn't cause more confusion than the benefit of consistency between plugins.

[davinwang]

@hishamhm I think the consistency is about how to define X-Credential-Username. For me, it represents the identity of the authenticated key, just like X-Consumer-Username represents for the identity of authenticated consumer. Whether its name is "key" or "username" is not the most important problem to me. Basic-auth and hmac-auth use "username", key-auth and jwt-auth use "key", unless we migrate the database schema.
And btw, the key-auth plugin is also broken.

[kikito]

Hi, we have discussed this internally and we think X-Credential-Username is not appropriate for "key" plugins. Instead we think it would be better to add a new header called X-Credential-Identifier on every auth plugin, and at the same time keep X-Credential-Username on the plugins which already use it.

[davinwang]

@kikito @hishamhm Hi, will Kong team add this 'X-Credential-Identifier' or let the community do it? Would you suggest a timeline for this feature?

[kikito]

Hi, what I was suggesting is that you changed the header in your PR to X-Credential-Identifier.

Apologies if this wasn't clear.

[davinwang]

@kikito Hi, I changed the PR according to above discussion, please feel free to advise

[kikito]

Hi @davinwang, thanks for your changes. Do you mind changing the target branch from master to next on your PR, so Travis picks it up?

[bungle]

I'll add some tests after this is merged.

[bungle]

Thank you @davinwang, the PR is now merged! Please go ahead and grab a t-shirt: https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#contributor-t-shirt

:-)