I am currently working on a project which has a GraphQL service that takes care of handling all client requests and communicates with other microservices as needed be. This GraphQL service is the only service exposed to the client, basically kind of like an API gateway.
Taking this into account, I was wondering if all microservices are required to have authentication/authorization handlers, as well as input and data validation. Since these microservices can only be accessed by the GraphQL service and are never exposed to the public, is there any risk to not performing these mentioned tasks on them? Can't the main GraphQL service simply take care of all the authentication, authorization and input validation and then proceed to only send requests to the microservices having these steps occurred successfully?
Related
I am new to spring microservice world. As I am in learning phase, I tried and implemented the following things.
Authentication/Authorization as a separate microservice
Routing (Able to route using Spring cloud gateway)
Load balancing (Netflix Eureka)
Rate Limit and Circuit Breaker (Resilience4j)
I just need certain clarification and suggestion on what to do in these situations:
As I already had created Authentication/Authorization as a separate microservice centralized.
Now how can I implement such that every request must contain jwt token and pass-through API gateway to call other microservice also it should check which user has permission to access API in other microservice
If some has same good source so that I can learn please do share or if someone has a basic skeleton on GitHub.
Requests from outside your cluster should be intercepted/validated by Zuul (example) will be your gatekeeper which will pass the request to the request checker in this case would be your authentication service where the acquired token will be validated (this should exists at the header of the request). One tokens are validated, the request will be routed to the authorization service to check if the user has access to particular endpoint based on your rules defined for access.
All of my Micro Services, checking client access token validation using Rest API call to against my Authorization micro service which make a coupling between all the services to the Authorization Micro Service. The problem is that the token located only on the Authorization service Database. Is there a better way to do it instead of rest api?
Usually i prefer amqp over Rest API to avoid coupling but i can't see other option. Could someone help with that?
We have micro-services with the following architecture:
web-ui <-> graphQL <-> n * back-end services
We are implementing PACT consumer driven contract tests which is working well between the back-end services.
However there are questions on how to implement this through the graphQL layer. In reality this is a consumer of the back-end services, and a provider to the web-ui.
As the consumer, GraphQL doesn't have the domain information for the actual required json that is initiated from the web-ui service. Then the web-ui service doesn't test against the back-end providers (as the graphQL layer is its provider) - and it hasn't got that association / knowledge of the back-end services.
Is it that graphQL should create a PACT interaction with each back-end provider containing all its potential values with each service. Then this demonstrates that those interfaces remain compliant. Thus the real request (interaction) from the user (web-ui) has pacts with the GraphQL service (with mocks of the back-end services), so implicitly would work all the way through the stack.
Has anyone got advice of how this works across this aggregation layer?
I need to use activemq to communicate between micro-service and the system has access control to limit the user action. I already check the user from restful endpoint by spring security. After authentication, I send message to queue. Do I need to verify the user again? If yes, how can I pass the user credential by activemq.
If it is microservices architecture already. And as what you said you have an authentication/Authorization micro-service then there is no point duplicating the checks all over again.
The best approach is to let the Gateway-Service do the authentication/authorization thing.
Usually it is bound to the Zuul implementing service. So that all calls to specific service URL got intercepted by that gateway and apply whatever security policies you have
I am developing a web app which will consist on two different deployments: one containing the service layer (services, database access, etc.) with a REST endpoint, and on the other hand a UI layer that only has a presentation layer based on the data retrieved by consuming the REST endpoint of the service layer.
I am using Spring to develop both apps, so the natural idea would be to secure the application using Spring Security.
But how would I go to achieve that? I guess the login page should be on the UI layer but how do I share security concerns through both apps? Is there any bibliography on a similar case?
Note that these two deployments do not necessarily reside in the same container.
usually the REST service layer runs on a separate server with a notion of authentication, for example Basic or Digest authentication that spring security supports out of the box.
Clients of the REST service will either use a REST login service to authenticate themselves and make further requests by passing a session token alongside the request, or more frequently sign each request with a REST API key, that was pre-assigned to each client.
In this case the client of the REST service is the frontend server that serves the login page and any other pages of the web application, as well as replies to the pages ajax requests, that cannot go directly to the REST server due to the same origin policy.
This way there are two separate setups of spring security: Basic Authentication/Digest/custom authentication on the REST side, and form-login authentication on the frontend server side.
The user identifies itself to the frontend server, and the frontend server identifies itself to the REST server. The data served to a page might be a combination of several REST calls.