ignore alternative authorization header prefixes

[Geal]

Follow up to #4718

This PR enables the JWT plugin to ignore other auth prefixes other than the one defined in the configuration.

This enables multiple Authorization schemes to be supported, although other schemes would need to be handled in either Rhai or a coprocessor to be used with the AuthN plugin.

---

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• Changes are compatible¹
• Documentation² completed
• Performance impact assessed and acceptable
• Tests added and passing³
  • Unit Tests
  • Integration Tests
  • Manual Tests

Exceptions

Note any exceptions here

Notes

Footnotes

1. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩

2. Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩

3. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩

[router-perf]

CI performance tests

• reload - Reload test over a long period of time at a constant rate of users
• events_big_cap_high_rate_callback - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity using callback mode
• events_without_dedup_callback - Stress test for events with a lot of users and deduplication DISABLED using callback mode
• large-request - Stress test with a 1 MB request payload
• const - Basic stress test that runs with a constant number of users
• no-graphos - Basic stress test, no GraphOS.
• step-jemalloc-tuning - Clone of the basic stress test for jemalloc tuning
• events - Stress test for events with a lot of users and deduplication ENABLED
• events_callback - Stress test for events with a lot of users and deduplication ENABLED in callback mode
• events_big_cap_high_rate - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity
• events_without_dedup - Stress test for events with a lot of users and deduplication DISABLED
• xxlarge-request - Stress test with 100 MB request payload
• xlarge-request - Stress test with 10 MB request payload
• step - Basic stress test that steps up the number of users over time

[lleadbet]

The current default does the opposite, no? It will reject the request as far as I can tell.

[Geal]

yes, so it will be different from the current default. I don't want to add yet another option to keep a behaviour that did not make much sense. Do you think there are users that relied on checking the authorization header prefix instead of using the require_authentication option?

[lleadbet]

Hmm. I would guess they may use it as an expected behavior to fail if it isn't formatted correctly, including overall header structure. I can reach out to other SAs to get a gut check.

[garypen]

I think the change in behaviour is ok as long as the docs make the change clear.

[garypen]

Attempted clarification, but make sure it still makes sense.

Suggested change

	If the router encounters an authorization header with a different prefix in the value than what it expects, it will now ignore it. If the router was configured without the `require_authentication` option or without the authorization directives, then some requests that came with a different header prefix that were rejected before will now go through the router. If those options were configured, then there will be no change in behaviour.
	If the router encounters an authorization header with a different prefix to the configured value, it will now ignore it.
	If the router is configured without the `require_authentication` option or without the authorization directives, then requests that have a different header prefix, that were previously rejected, will now go through the router.
	If both of those options were configured, then there will be no change in behaviour.

[garypen]

Suggested change

	As an example, with a router configure like this:
	As an example, with a router configured like this:

[garypen]

Suggested change

	In the above, the router will ignore `Authorization: Basic <token>`, but process requests with `Authorization: Bearer <token>` defined.
	In the above, the router will ignore requests with a `Authorization: Basic <token>` header and process requests with a `Authorization: Bearer <token>` header.