Handling Authorization With Keycloak and Kong

Hello everybody,

I am working in a project that uses Kong as API Gateway and wants to introduce Keycloak as IdP (Identity Provider), so the desired flow would be something like that:

  1. The client obtain an access token from Keycloak
  2. The client with the token in hands invoke some API putting the token in the request header
  3. The request reaches Kong before the service
  4. The Kong acts as PEP (Policy Enforcement Point) requesting Keycloak authorization services an answer
  5. Keycloak acts as PDP (Policy Decision Point) and check if the client can access the desired service based on polices and permissions
  6. Kong receive the Keycloak answer (yes or no) and check if the access can be made.

In order to achieve this objective I have developed a custom Kong plugin and adopted other called jwt-keycloak

I have found few materials about scenarios where Keycloak work together and API Gateway, so could you guys validate if the solution I made is correct.

The custom plugin and details about the architecture is here.

Hello,

the architecture sounds good to me. We built something very similar.
Are you using the community kong version ?

I’m still not sure it’s a good idea to use kong as PEP, it will considerably slow down the api manager. what do you think ?

I also think it may be painful for API developer to have to configure security on kong and in the api itself.

It’s indeed very hard to find any resources about such a use case.

Hi @sebastienm, thanks for replying.

Are you using the community kong version ?

Yes.

I’m still not sure it’s a good idea to use kong as PEP, it will considerably slow down the api manager. what do you think ?

What do you mean as “api manager” ?, would be the network traffic ?

About PEP implementation, in my point of view there are two options:

  • Handle authorization at API level, that is, each API acts as PEP:
    That would implies use an Keycloak adapter for each API.

  • Handle authorization at API Gateway level, that is, API Gateway/Kong acts as PEP:
    That would implies use a Kong plugin to handle authorization.

As in this project we have many API’s with different technologies (Java, Node, Python …), would be painful change each API. The network traffic also isn’t so high, so we decided to adopt the first option.

I also think it may be painful for API developer to have to configure security on kong and in the api itself.

We are only handling security at gateway level, as the authorization process was done by the gateway isn’t necessary to worry about it inside the API.

Hi, what did you end up doing? I am in the same boat right now and confused about where the responsibilities should lie. Also, kong seems to have the openid connect plugin only in its enterprise version. Did you evaluate that option against a community driven one? Thanks.