I'm building a microservice system using Micronaut + Consul + Token Propagation, so now I want add a API Gateway and my first choice is Netflix Zuul, but Zuul proxies the request using a Netty and Micronaut is a server built on netty too, how can a manage this? if I use ad hoc Zuul (without Micronaut) I loose Token Propagation.
since token propagation is just about forwarding headers downstream you can configure Zuul to do so. See https://cloud.spring.io/spring-cloud-netflix/multi/multi__router_and_filter_zuul.html#_cookies_and_sensitive_headers
Related
I would like to deploy this on Kubernetes. Would it make sense for both the Auth Server and the Policy engine to talk to the API Gateway independently or is it more accurate for only the Auth Server to talk to the API Gateway and the OPA to talk to the API Gateway only via the Auth Server
At Curity we have some good resources related to this. Usually the first key consideration is around components that use data sources:
APIs
Authorization Server
These are always deployed with a reverse proxy / gateway in front of them, so that an attacker has to breach 2 layers to access data sources - this is covered in our IAM Primer.
In addition the gateway can then provide some interesting capabilities:
Token Introspection and Caching
Dynamic Routing
In terms of OPA it depends how you will use it - here are a couple of possible options:
Gateway calls OPA to perform high level checks to grant or deny accesx as in this OPA use case
The API calls OPA and passes it a Claims Principal, then uses the response to decide how to filter results, as described in our Claims Best Practices article
I am using JHipster 6.4.1 to generate an Oauth2 (Okta) Microservice application with a React UI / API Gateway.
I understand that the Microservice application/s can support multiple instances under the same
Registry and will use a round-robin approach to load balancing and in this way can horizontally scale.
My understanding is that the Gateway application with Oauth2 uses a stateful Spring Security implementation (JSESSIONID cookie), so the same stateless scalability approach cannot work here.
Are there any recommended solutions for applying scalability to the Gateway application?
You can use Spring Session to share your sessions between gateway instances, there's usually nothing wrong being stateful if the state is small, can be easily replicated and does not contain business data.
I've been looking into developing a microservice architecture using SpringBoot and some netflix libraries such as Eureka, Zuul, Ribbon; however, I appear to be hung up with the security design.
My goal is to use a third party web based service such as Okta.com to manage all my users and applications. Okta uses Oauth2 which I believe would make my application stateful. My goal is to keep my application stateless for load balancing purposes.
I would be using the following service module architecture,
Gateway Service
Auth Service (Authenticate against Okta)
Microservice 1 (role_admin, role_sales)
Microservice 2 (role_admin, role_employee)
My understanding is when the gateway has requested routing to Microservice 1 or Microservice 2, a token would need to be forwarded along with the request and if no token is present, a request to the Auth Service at the gateway would need to be made in order to obtain a token from Okta using Oauth2.
My next piece of understanding is while using oauth2, when the token is present and has been forwarded along to Microservice 1 or Microservice 2, the token would need to validated against okta again. The groups would be contained within the token.
My question is could Okta be used solely for the purpose of Authenticating and Authorization, but rather than passing around the stateful oauth2 tokens generated by Okta, create a stateless JWT which would contain roles and user info and pass that back to the microservices?
I'm just wondering how to use a service like Okta in a microservice architecture, but still keep my microservices stateless and I'm not sure my thought process is correct.
I have a Microservices based architecture where Microservices are running in Cloud Foundry and expose REST interfaces. These REST interfaces are invoked by browsers.
I have a requirement that REST calls originating from browsers should be authenticated while requests made from one Microservice to another need not be authenticated.
Since I'm using OAuth2, the REST calls originating from browsers would carry JWT and the microservice is expected to verify this JWT. However, requests originating from microservices will not carry JWT and the peer microservice is expected to detect that the request is originating from within Cloud Foundry and hence allow it to pass through. We are using Spring Security filters.
How can a microservice detect if the request is originating from outside Cloud Foundry?
After reading the article How To Control User Identity Within Microservices I've been trying to implement such access control scheme (Value and Reference Tokens), but after going through multiple other topics and examples in GitHub related to Spring Security + OAuth + Zuul, I couldn't find concrete examples on how this can be achieved. All the examples that involve JWT return User Details when the token is returned, and that is what I would like to avoid. The User Details should never reach the Client directly but should be passed to the backend services instead. The tutorial Spring Security + AngularJs has a lot of information on how to evolve an application towards a secure one, but uses an Access Token or mentions the possibility of getting the User Details directly via JWT.
This SO question, Using Zuul as an authentication gateway by #phoenix7360, is exactly the approach I've been trying to implement but it only supplies a brief overview of the configuration required to carry out this kind of security approach for microservices. Please refer to the image in this question for a clear picture of how it would go.
I can't fully get my head around how the Zuul Pre-Filter should be configured and what the Authorization Server's configuration should look like. As stated in both the article and the SO question, the flow would go something like this:
External (HTTPS)
The client authenticates against OAuth2 Server
OAuth Server returns an opaque Access Token (a UUID with no other information)
The client sends the request to the API Gateway with the Access Token in the Authorization header
API Gateway requests User Details to the OAuth Server with the Access Token in the Authorization header
OAuth Server checks the Access Token is valid and returns User Information in JSON format
Internal (HTTP/S)
API Gateway creates a JWT with User Details and signs it with a private key
API Gateway adds the JWT to request and forwards it to Resource Server
Resource Server verifies the JWT using API Gateway's public key
Note: API Gateway should return an error if OAuth Server indicates Access Token is no longer valid.
How would the ZuulFilter work? Does a new request need to be issued against the OAuth Server (for instance, via RestTemplate), or are these schemes supported with the current implementation? Is there any particular configuration required for the JavaConfig classes for both OAuth and Zuul? If someone knows of a working example that would be really helpful and would be great for future reference regarding this topic.
I'm using Spring Boot (1.4.0-M3) + Spring OAuth + Spring Cloud (Eureka, Ribbon, Zuul)
I know this question is very similar to the one linked previously, and if this is not the right way of doing it I apologize, but I thought a new thread would be better than asking for help on a SO thread that aimed at solving another problem.
Thanks in advance!
JHipster does a pretty good job in handling this issue. If I want to tell the login process briefly, first you do login, in time you fetch every information you need to pass to your below services (such as username,email,etc) then you pass them to your microservices.
you can see the link below from okta for more information
https://developer.okta.com/blog/2018/03/01/develop-microservices-jhipster-oauth