Does Spring Cloud Function provide some kind of functionality similar to Spring Security Filter Chains ?
One particular use case is to implement CORS with AWS Lambda API Gateway in proxy integration mode. According to the AWS docs, it's function responsibility to add CORS headers to the response.
It might be more useful to do this at the integration layer and not in the business logic.
I'm using Spring Cloud Function with AWS adapter and Spring Boot.
I've browsed through the code (3.1.3 at the time of writing) but didn't find something alike.
There's one old issue showing CorsFilter registration (with Azure provider) but I doubt it really worked as Spring Cloud Function does not utilize Servlet environment.
Related
I am working on a Microservices architecture where I am using following components:
KongHQ as an API gateway
Keycloak as a IAM solution
Microservices written in Spring Boot.
My basic requirement is to completely decouple authentication/authorization from Spring boot microservices. Therefore, authentication as well as authorization of API should be done at API gateway layer.
Most of the articles and tutorials recomment to integrate Keycloak with Spring Boot as well.
I would really like to know if the requirement is feasible and if so how to do it?
I would not de-couple security from micro-services for two reasons:
access-control is a business requirement I want to unit test
spring-security is probably more powerful (expressive, testable, etc.) than any API gateway security filter
You do not have to integrate Keycloak with spring-boot (actually you should not because Keycloak libs for spring are deprecated).
Spring-security has tools for resource-servers. Sample here.
I also wrote (very) thin layers on top of spring-boot-starter-oauth2-resource-server to ease resource-server configuration. Most config options are available from properties, which save quite some Java code in micro-services. Sample there.
Following advanced tutorial, you can even build a security DSL as expressive as #PreAuthorize("is(#username) or isNice() or onBehalfOf(#username).can('greet')"). Good luck to achieve the same with an API getway.
The repo linked above also contains quite a few annotations for configuring unit-tests security-context:
#Test
#ProxiesAuth(
authorities = { "AUTHOR" },
claims = #OpenIdClaims(preferredUsername = "Tonton Pirate"))
void whenHimselfThenCanGreetFor() throws Exception {
mockMvc.get("/greet/on-behalf-of/Tonton Pirate").andExpect(status().isOk()).andExpect(content().string("Hi Tonton Pirate from Tonton Pirate!"));
}
Here is a very detailed article to introduce the use of API Gateway and keycloak：https://apisix.apache.org/blog/2022/07/06/use-keycloak-with-api-gateway-to-secure-apis/
I am working on a distributed application project where there is need for rate limiting and authentication depending on the client consuming the service on an api gateway. I am wondering the best solution for designing the gateway.
Should I go with Spring cloud gateway or Spring Cloud function/AWS Lambda to create the gateway service?
I'd argue that using AWS API Gateway will make your life easier...
The benefits of using AWS API Gateway are:
it will remove all the operational cost of maintaining, configuring, monitoring and operating a Spring Cloud Gateway instance,
it will be highly available, with failover,
it will give you instant features like rate limiting, api keys, caching, authorization, canary testing, proxying, integration mapping, environments
it is very very cheap ($3.50 x MM requests).
The benefits of using Spring Cloud Function:
Define your API's as code within the application code itself
Leverage the ecosystem integration within Spring, for example, to run it locally on a dev's PC.
Cons of using API Gateway:
Deployment of new API's will be harder than using Spring Cloud Gateway (you need to configure each new resource/method)
Your costs are now tied to the number of requests... if you have a 900.000.000 millons/months API it could get expensive
Vendor lock-in
Cons of using Spring Cloud Function:
Operative cost of maintenance
Single point of failure
You can use Amazon API Gateway.
For more info on request throttling and quotas, please refer to the docs:
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html
I will rather use Istio gateway Envoy proxy rather than both options if permitted. Keeping my operational and maintenance cost little and no code change.
In your opinion, in a hybrid architecture (WEBSOCKET + HTTP) is it good practice to use 2 gateways: Zuul for HTTP communication and Spring Cloud Gateway for WEBSOCKET communication in a Spring Boot application? Alternatively, in this scenario is it recommended to use only Spring Cloud Gateway?
Thanks.
is it recommended to use only Spring Cloud Gateway Yes because
Spring Cloud does not provide any out of the box integration with Zuul2. Gateway has many features that are not available in the public version of Zuul2 such as Rate limiting, etc. Also, with the gateway you can have custom filters defined per route and there are tons of built-in filters defined as well, which helps a lot to get started. Reference
Reference: I think SCG is the way to go due to the agreements between Netflix and Pivotal, with the former leaning more toward the spring boot/cloud ecosystem as stated in https://medium.com/netflix-techblog/netflix-oss-and-spring-boot-coming-full-circle-4855947713a0
I want to use Spring Cloud Gateway with SAML. Is this possible?
It seems that the Saml extension for spring security is based on the old Spring Stack and won't work with Gateway.
Has anybody got any experience on this?
I'm afraid SAML is not supported as of time of writing. Spring Cloud Gateway has been redeveloped using Reactive programming and is now based on Spring WebFlux. Only the following authentication methods are currently supported :
OAuth 2.0 or OpenID Connect 1.0
x509 authentication
This is stated on SCG page:
Spring Cloud Gateway is built on Spring Boot 2.x, Spring WebFlux, and
Project Reactor. As a consequence, many of the familiar synchronous
libraries (Spring Data and Spring Security, for example) and patterns
you know may not apply when you use Spring Cloud Gateway. If you are
unfamiliar with these projects, we suggest you begin by reading their
documentation to familiarize yourself with some of the new concepts
before working with Spring Cloud Gateway.
The previous gateway spring-cloud-netflix-zuul, based on Servlets and which supported SAML, has been removed from Spring Cloud 2020.
Here is an open issue on GitHub, SAML2 for reactive environment, where we can vote for asking for this to be implemented.
We have developed a software proxy based on spring boot and zuul, that is meant to govern services within our integration layer. We do not own the systems consuming the various services, nor do we own the actual services themselves. The services are SOAP based webservices at present. We make use of pre, post , error and route filters. Validations are database driven, including which client is allowed to call what webservice. All service definitions reside in the database (request endpoint, request xsd, response xsd, which clients are allowed to invoke, etc.).
The aim now is to add hystrix commands to handle service failures, as well as a hystrix dashboard.
The standard way to use hystrix commands involves annotating service methods with javanica. Is there a way to dynamically declare/register hystrix commands for these webservices at runtime after reading the configurations from the database? The hystrix interception will need to happen based on the multiple webservice endpoints being invoked from a single point.
Hoping this is achievable ...if not, I would really appreciate any alternative proposals for how hystrix commands could be declared in this way.
Thanks!
You're saying that you are already using Spring Boot and Zuul. How are you mapping the routes? Through the url param? Then you'll have to enroll your own. But if you define the routes as ribbon services and pass the routes as ribbon servers as described in the documentation you will get Hystrix for free.