Is keycloak behind api gateway a good practice?

Question

What are good arguments in favor to use or not to use Keycloak behind Api gateway (Kong)?

Cherycherye

Answer 1

There is a tradeoff to putting it behind the proxy: you will not be able to easily protect all of your services by applying the OIDC plugin on the global level. Instead, you will need to individually configure every service with its own OIDC plugin. This is because you will need at least one service that is not protected by the OIDC plugin so that user-agents can authenticate through that service. Unless you're planning to implement some other form of security on that service or need some other services that Kong can easily implement as requests pass through it, I don't see the point of putting Keycloak behind the proxy. That's not to say there aren't good reasons to do it, I'm just not aware of them.

I've set Keycloak up outside of the proxy, and have had good results. Here's what it looks like:

I'm writing a blog post about this set up now which I will release next week. I will try to remember to update my answer here when it is complete.

Edit

Links to blog: Part 1, Part 2

Sojourn

I guess you can now update this post with links to your blog? :) – Mazzard

I've also seen companies put reverse proxies like Kong in a DMZ, if that helps anyone. – Sojourn

Answer 2

It is not good practice, in fact I would suggest to put it outside, in the DMZ. In this way that IDP can be leveraged by all APIs that you want to publish and authenticate using the API gateway. This is an example of applying such authentication flow with Keycloak: https://www.slideshare.net/YuichiNakamura10/implementing-security-requirements-for-banking-api-system-using-open-source-software-oss

Your concern might be then: how do I protect such a critical resource like an IDP authenticating all my services? Reasonable concern which you can address by:

• ensuring autoscaling of the IDP based on authentication request
• configuring all the needed threat mitigation options on Keycloak (https://www.keycloak.org/docs/latest/server_admin/#password-guess-brute-force-attacks)
• add a WAF in front of the IDP with feature such as DDOS prevention and Intelligent Threat Mitigation based on traffic patterns
• IP or Domain whitelisting, if you know where all your customers are connecting from
• restrict port exposure for the IDP

Cassation

Answer 3

Kong is an API gateway that'll be in the "hot path" - in the request and response cycle of every API request. Kong is good at efficiently proxying lots of requests at very low latency.

Keycloak and other IAM offerings can integrate with Kong - but they aren't placed in the hot path. Keycloak is good at managing users and permissions and providing this information to systems like Kong, when requested.

Perhaps these links will be helpful https://github.com/ncarlier/kong-integration-samples and https://ncarlier.gitbooks.io/oss-api-management/content/howto-kong_with_keycloak.html

Brindle

Answer 4

Is not a good practice, a good Enterprise API Gateway has the obligation to meet (or give you the access to customize) all the advanced authentication and authorization standards available in KEYCLOAK.

But in some circumstances, If you already have a API Gateway with a lot API´s configured (with transformation rules, route rules) and this Gateway can´t provide advanced features for authentication and authorization (ex. 2 factor authentication or Oauth2 authorization code/openId / SAML) and you need more security ASAP, go ahead while looking for a gateway that best meets your needs

Crosseyed

What i understand that service like Keycloack / Gluu / Okta is needed any way, the only question is whether to use behind the api gateway or aside of the api gateway. Have never heard of gateways which have everything in one package and i don't think that's a good thing. Let me know where you think i am wrong. – Cherycherye

Keycloak is a IAM suite, can play different roles in different scenarios (behind, side, before API Gateway). Can you describe your architecture? FIY: Many authentication and authorization features in an IAM suite have already been incorporated by other types of tools such as API Management Tools (eg Axway, Apigee or CA Layer 7) where Keycloak or otka is not required because its easy to manipulate multiple Identity Providers and create APIs and IAM flows through policies and protect resources. – Crosseyed

Kong (Mashape) actually is like Apigee or Axway. So i still need some IAM. Architecture was something i am not sure about. Basically initially user not authenticated, so some routes are not accessible via Kong. So after user needs to authenticate via Keycloak. I am not sure where to keep the Keycloak service, behind Kong (open route) or as a separate service , wihout Kong proxy. My assumption is that keeping it behind the Proxy is a better solution. – Cherycherye