Consumer identification without authorization

Hello guys. This is my first time here in the community, and I’m glad to be here :slight_smile:

I am introducing Kong to a customer, which already has its own authentication process (a very complex one btw), and I could not integrate their authentication to Kong’s yet, and maybe I will not be able to do it.
So what I want is to be able to explicitly tell Kong what is the consumer id or name of a request, in a custom header of something like that, in order to user other features such as rate-limiting.

Is it possible? Do you have any suggestions for that?

Thanks in advance

Hmmm, I mean you could use something like basic auth with password or oauth or any real token to identify the consumer and make sure thats the auth type the proxy has enabled for it, then every consumer that has a basic auth or oauth creds could call it. that gives you no authorization and still identifying the consumer(basically an ALL consumer have access sort of setting). What prevents the consumers from passing an auth header or query parameter signifying who they are to kong? If they cannot do that and Kong has 0 ways to identify them you cannot apply a plugin such as ratelimiting to an unknown I don’t think. Maybe someone from Kong team has an idea but a gateways primary purpose is to provide authn/authz and to not leverage any of that makes me wonder what benefits you are really getting(maybe some metrics and global rate limiting but that would not be worth the latency hop IMO).

I agree with @jeremyjpj0916 - you are proposing a curious way of using Kong.

Did you see that Rate Limiting doesn’t require an identified consumer? You can, instead, rate limit by IP address.

Hey guys, thanks for your posts and I´m sorry for the late reply.

I know it´s not a common scenario I´m facing, but there are client´s restrictions preventing me to use Kong for main authentication process. And another unusual requirement in my client is to use kong behind other proxy, so I cannot use rate-limiting by IP either.

What I did to workaround it is to enable basic authentication in Kong and keep both processes working.

It´s a work in progress to refactor this architecture anyway…