fix(key-auth): add missing www-authenticate headers

[nowNick]

Summary

When kong returns 401 Unauthorized response it should return WWW-Authenticate header with proper challenge. Key auth was missing this header on some responses. This PR also adds a possibility to configure an optional parameter - realm (defaults to null).

Related PRs:

• https://github.com/Kong/kong/pull/11791
• https://github.com/Kong/kong/pull/11792
• https://github.com/Kong/kong/pull/11795
• https://github.com/Kong/kong/pull/11820
• https://github.com/Kong/kong/pull/11833

RFCs & Materials

• https://httpwg.org/specs/rfc7235.html#status.401
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate

Checklist

• [x] The Pull Request has tests
• [x] A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
• [x] N/A ~~There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE~~

Full changelog

• add WWW-Authenticate header to all key-auth 401 response

Issue reference

• Fix #7772
• KAG-321

[bungle]

@nowNick,

How does this behave in AND/OR scenario? E.g. basic-auth AND/OR key-auth (or do we just skip that complexity for now)?

[nowNick]

Hey @bungle !

When I was thinking about it I came to the conclusion that it's not necessary to handle those scenarios or it's impossible to do them, but my understanding could be wrong.

Basically when it comes to OR I think we do not need to handle the WWW-Authenticate since the response should be 200 unless there's request termination plugin turned on that forbids anonymous access.... well... now that I think of it maybe we should add proper WWW-Authenticate headers to that plugin as well. Will it be possible to look up what auth plugins the request has fallen through so that we could create a proper WWW-Authenticate header at the request termination plugin turn? I'm basing my understanding on this: https://docs.konghq.com/gateway/latest/kong-plugins/authentication/reference/#multiple-authentication

Now when it comes to AND scenario I wonder whether it's possible to return all of the challenges. Correct me if I'm wrong but if there's the so called AND condition - when a single auth plugin fails and it returns 401 will another auth plugin code execute or will the request be terminated since the AND condition already failed (basically an early exit)? If so I concluded that it's impossible to incorporate other challenges to certain plugin 401 response if there's AND condition between them. Is my understanding correct?

[locao]

@nowNick there conflicts preventing us from merging this PR, can you check, please?

[bungle]

Hey @bungle !

When I was thinking about it I came to the conclusion that it's not necessary to handle those scenarios or it's impossible to do them, but my understanding could be wrong.

Basically when it comes to OR I think we do not need to handle the WWW-Authenticate since the response should be 200 unless there's request termination plugin turned on that forbids anonymous access.... well... now that I think of it maybe we should add proper WWW-Authenticate headers to that plugin as well. Will it be possible to look up what auth plugins the request has fallen through so that we could create a proper WWW-Authenticate header at the request termination plugin turn? I'm basing my understanding on this: https://docs.konghq.com/gateway/latest/kong-plugins/authentication/reference/#multiple-authentication

It is possible at least in theory, but I agree it feels like a stretch. Not part of this PR. We would need to modify all auth plugins to add/append something in context. So lets skip it for now.

Now when it comes to AND scenario I wonder whether it's possible to return all of the challenges. Correct me if I'm wrong but if there's the so called AND condition - when a single auth plugin fails and it returns 401 will another auth plugin code execute or will the request be terminated since the AND condition already failed (basically an early exit)?

The other plugins (that come after) access phase will not be executed if one auth plugin terminates. But they are still collected, so their header_filter will still be called. And in header filter it is possible to do something like this. But again, complicates the thing and all our auth plugins need to implement header_filter phase too. Which is probably not a good idea.

[team-gateway-bot]

Successfully created cherry-pick PR for master:

• https://github.com/kong/kong-ee/pull/8567