Allow multiple authentication methods per API and/or Consumer

[ahmadnassri]

as an API provider, I need to protect my end users through an authentication scheme (such as basic auth) but also provide a developer/partner level authentication (such as key auth)

Kong needs to authenticate both consumer objects (representing both the end user and the developer/partner)

[esatterwhite]

👍

[sonicaghi]

This exact use case was presented today during a Kong POC meeting.

[thibaultcha]

We need #505 (and we need it to be done right) for this.

[thibaultcha]

Some other issues mentioned similar concerns and reference this one. It is worth also browsing them for additional concerns and requirements for multiple authentication methods.

[t1tcrucible]

Hi, i just want to provide some additional information which can be useful.
In one the services we expose through Kong, the need was there to add the following policies:

• JWT because we need to setup a user context
• OAuth2 Auth grant because we need the user to grant the application with scopes enforced by the service
• Key-auth because we want the application consumer to have a trust relation with the service
• ACL because we want only this application to use this specific service

When we add up all those policies, server side receives following headers:

{"name": "apikey", "value": "7a30437b-935a-4807-93fc-0ed1750fe64d"}, = key-auth
{"name": "authorization","value": "Bearer ad9996391ae842e8c2a4e61b43e6e2b9" }, = OAuth2 token

--the followin are due to the JWT
{"name": "x-consumer-id","value": "2df4a7c1-710a-46b6-c6ee-2343e95a16a4"},
{ "name": "x-consumer-custom-id","value": "michallis"},
{ "name": "x-consumer-username", "value": "michallis"},
--the oauth scopes and authenticated user
{"name": "x-authenticated-scope", "value": "basic extended full"},
{"name": "x-authenticated-userid","value": "michallis"},
--the JWT pass-through
"queryString": [{ "name": "jwt","value": "eyJhbG....qqQKRSsavw"}],

What I now miss -in order to setup an tenant/application context-, is the consumer-id of the consumer for key-auth. Because of the use of JWT, my consumer-id will be set with the consumer for the JWT token.

can we prioritize policies in an order to apply?

regards,

[t1tcrucible]

+1

[gschlect]

👍

[djMax]

Would love to see an update on this... Has been quite a long time since there was action and there is no proposal for how it will work.

[faabiosr]

Well, maybe if we create a plugin with high priority and this plugin is responsible for manage the auth chain, when you enable this plugin, you should set the list of auth types and the order of this list is the priority, see the example bellow:

curl -X POST http://kong:8001/apis/{api}/plugins \
    --data "name=auth-chain" \
    --data "config.auth=key-auth, jwt, basic-auth"

It's necessary to enable authentication plugins first.

[Tieske]

The new 0.10RC has multiple auth, in a logical OR fashion. In that case if it remains unauthenticated, it will still proxy, but will set a header that it is an anonymous user (you can set which consumer to use as the 'anonymous' one)

see https://github.com/Mashape/getkong.org/pull/309/files

[firegrass]

@Tieske is there anyway to configure the API so that at least one auth methods must have succeeded to proxy?

[Tieske]

not yet, but that could be done with #2051

If you'd attach that to the consumer defined as anonymous, it would terminate any unauthorised request

[sven4all]

That feels a bit hackish to me. Would be really nice if you can a only_allow_access_if_authenticated to an api, but would be difficult to implement with the really nice modular structure of plugins that is now in use.

[nvx]

I noticed #2051 is merged now, what more remains for that functionality @Tieske?

[Tieske]

implemented using the anonymous consumer. In 0.10 already...

[nvx]

I've had a bit of a play and while it seems to work, if you don't provide any authentication and you're using the ACL plugin you get an error (#2547).

If you wish to have an authenticated API secured by one of two methods and disallowing anonymous auth you'd expect a HTTP 401 response if you hit the endpoint without supplying credentials (which is what happens if you're hitting an API secured by only one auth method), but this doesn't happen currently.

Aside from the ACL bug (arguably it should look up the anonymous consumer id which would let a proper ACL lookup happen), that would then return a HTTP 403 if that issue is resolved. There should be a way to differentiate between an API that allows anonymous access, key login and basic auth from an API that allows key login and basic auth but disallows anonymous auth.

[Tieske]

@nvx #2547 was just closed, fixed by #2722 in 0.11RC2.

If you wish to have an authenticated API secured by one of two methods and disallowing anonymous auth you'd expect a HTTP 401 response if you hit the endpoint without supplying credentials (which is what happens if you're hitting an API secured by only one auth method), but this doesn't happen currently.

You should configure the anonymous consumer you created by attaching the request-termination plugin to that consumer and have it terminate the request with a 401. As documented here https://getkong.org/docs/0.10.x/auth/#multiple-authentication (warning at the bottom)

[nvx]

Ah that'll do it. So enable the request termination plugin for that API and the anonymous consumer? Does sound like a better option than relying on a side effect of the ACL plugin.