authentication API Gateway Apache APISIX Keycloak Spring Security

System architecture: move authentication to the API Gateway

When exposing an application to the outside world, consider a Reverse-Proxy or an API Gateway to protect it from attacks. Rate Limiting comes to mind first, but it shouldn’t stop there. We can factor many features in the API Gateway and should be bold in moving them from our apps. In this post, I’ll show how to implement authentication at the Gateway API stage. Overall authentication flow The API Gateway doesn’t authenticate but delegates authentication to an authentication

sticky session session affinity Apache APISIX Hazelcast Spring Session Spring Security

Sticky sessions with Apache APISIX - the demo

Last week, we described the concept behind sticky sessions: you forward a request to the same upstream because there’s context data associated with the session on that node. However, if necessary, you should replicate the data to other upstreams because this one might go down. In this post, we are going to illustrate it with a demo. The overall design Design options are limitless. I’ll keep myself to a familiar stack, the JVM. Also, as mentioned in the previous post, one should on

Spring Security Open Policy Agent Architecture Solution Architecture

Make your security policy auditable

Last week, I wrote about putting the right feature at the right place. I used rate limiting as an example, moving it from a library inside the application to the API Gateway. Today, I’ll use another example: authentication and authorization. Securing a Spring Boot application I’ll keep using Spring Boot in the following because I’m familiar with it. The Spring Boot application offers a REST endpoint to check employees' salaries. The specific use case is taken from the Open