Support for multiple auth methods for single consumer

[zeridon]

Hi Guys,

While playing around i reached the following:

• Single API
• Single consumer
• Basic auth credentials for this consumer (more than one set)
• Keyauth - more than one set
• Keyauth was enabled first

This leads to basic auth being unusable. E.g. when authing with user/pass combos it says i need a keyauth also. Is this intended effect?

Is it possible to configure stuff like this. E.g. auth either with basic or key.

[subnetmarco]

To better understand your question, would you like to chain multiple authentication systems together? May I ask what's your use case?

[zeridon]

Chaining is currently what happens. I want to be able to use any of the available.

I.e. use user/pass (aka basic) for one system (e.g manual tester/qa) OR keyauth (aka hash/header) with other system (production)

[subnetmarco]

Do you think it's reasonable to have two APIs on Kong? One production and one development, with different plugin configurations?

[zeridon]

Reasonable yes, unfortunately not really feasible. Main driver behind this setup is we are migrating to an API style auth (e.g. header, with some magic value (even if statically configured)). We were wondering if we could use kong as both LB frontend and cheap auth implementation.

[subnetmarco]

For the Load Balancer part, this is referenced to #157.

When I mentioned "two APIs on Kong", doesn't necessarily mean two different APIs on your side, but two different API objects in Kong that point to one API on your side. Like:

curl -d "name=test-production&public_dns=test-production.com&target_url=http://my.api/" ...
curl -d "name=test-staging&public_dns=test-staging.com&target_url=http://my.api/" ...

Where both APIs point to the same target_url (or path, if you are using the path resolver), but on Kong's side you can configure the authentication plugins independently for each of them.

[neilalbrock]

I think it would be useful to enable optional authentication using any one of the available methods, for a single API. I say this would be useful because I have existing code authenticating using basic auth but would like to deploy new code using key auth and gradually migrate to that over time. In the meantime, having to choose one or the other is a little inflexible.

[zeridon]

Yes indeed it would be usefull for exactly this migration scenario

[sonicaghi]

+1

[thibaultcha]

I am closing this in favor of #590 which I slightly updated to also reflect the concerns described here.