Is something like this good approach in securing microservices with api-keys?
In spring gateway I will secret in application.yaml named api-keys, which will contain all api keys for all of microservices(containing which service it is for, roles, permissions) and store this secret somewhere on 3rd party service like aws, GitHub etc?
Afterwards filter requests etc..
Is this safe?
Related
Looking for suggestions on how to go about with microservices authorisation.
I'm using the spring/spring boot for all them microservices
I'm able to authenticate via spring cloud gateway before reaching the actual microservices using JWT tokens however when it comes to authorisation i'm unsure on how to do it.
I would like handle the authorisation internally for each of the endpoints in the business microservice.
Is there a way to pass the JWT token to the microservice or do i need to call the authserver to get the roles within the user ?
Actually, both works.
You can put the roles in the token, when you need it, decode it. Or decode it in the gateway and pass it all the way.
If you don't want to put too much data in the token, you can call the auth server as needed.
I am working on a Spring Boot application where existing user authentication is based on Oauth2 with 2FA. Now, I would like to call the APIs in my application from the third-party client as well, say from another service.
Basically, I would like to develop one auth API, where on providing a valid client name, valid API key, and API secret, the client will get an auth token, which will be valid for say 1 hour. Then this auth token can be passed in all successive API invocation until the token gets expired.
I found a few articles here:
a. Securing Spring Boot API with API key and secret
b. How to secure spring Boot API with API key and secret
c. how to implement api key secure in spring boot?
d. How to config multiple level authentication for spring boot RESTful web service?
But, I am not getting any concrete idea regarding, how to achieve this.
Could you please suggest how can I achieve this? Thanks
This could sound like a very noob question, so let me apologies first.
We have multiple lambda services (JavaScript) added that uses AWS cognito. I know that AWS cognito is majorly designed for authentication and authorisation in serverless architecture.
But now I have a microservice written in Java using spring boot which is deployed behind the AWS api gateway. The gateway is running as a proxy to the service's resources. So our client app authenticates users using cognito and used Authorization and api key to access our services which have AWS_IAM and api key authenticating every request to the service on the gateway.
To perform some tasks in the service cognitoIdentityId is required. In case of JS lambda services we receive it in the event json in its context field. But I could not find any way for the spring-boot service to receive it. Neither HttpSession nor HttpServletRequest have that info. Requests are not directly authenticated with the service so spring SecurityContext's principal is also empty/anonymous. The documentation on cognito with http services is very bleak and most of the discussions starts and ends with Lambda.
Can anyone point me to the right direction as how to get the id?
Thanks in advance.
microservices architecture
I have a micro service(userservice:user related microservice) but in Zuul API gateway application i want to authenticate requests for all microservices and use spring security. I have to create signin and signup requests(AuthController) in Zuul application which require datasources,userRepository all things in zuul application.
If i use userservice(microservice user related)for other user related requests then i have use same datasource and create duplicate beans and repository for same data source which i already created in zuul api gateway application ?
I don't feel it would be a good design to authenticate usenames and passwords at gateway level. Instead what you can do is, you can add JWT tokens which can validate the request itself in zuul filters. This can be one level of verification at gateway level.
Second, you can implement caching at api level which would significantly increase the throughput of your backend security api.
I am trying out JHipster based on the supported Microservice architecture. I have created a Registry, Gateway, and a Microservice (based on JWT authentication) as described in documentation and everything works. However I am not sure why a Gateway in JHispter need to have a database. Questions that are still unanswered for me:
1- Why does a Gateway need a database? In which scenarios would you create a Gateway with/without a database?
2- Do the Gateway and Microservice use the same database? Or should they use separate database instances?
Ok, I did a bit more research on JHipster-Gateway and the inner workings of it. Below is a summary, related to my question:
1- A Gateway using a JWT or Oauth2 type only needs a database if the User related entities and backend code are also generated in the Gateway codebase. This is the case for a default JHipster Gateway, but does not have to be like this. As indicated in JHipster documentation a JHipster Gateway is actually a monolithic application and can be used as a monolithic application:
You will have the choice either to generate an new entity normally (a gateway is also a standard JHipster application, so this would work like for a monolith application), or use an existing JHipster configuration from a microservice.
When you create a JHipster Gateway, it creates the User entity related backend in Gateway codebase as default. But you can choose to have all the Backend code (including User) be placed/generated in Microservice codebase.
In such case there is no need of a database in JHipster Gateway application. Gateway working purely as a gateway to pass requests to microservices only needs to have the /api configurations properly set.
In the default case of a JHipster Gateway the User entity backend code is also generated in Gateway part, that is the reason why a database is needed. But you can move the backend code to Microservice and replace it by a proper /api configuration.
1) A gateway using JWT or OAuth2 auth types need a database to store users and their account details. A gateway using UAA auth type does not need a database, because the UAA microservice handles users and authentication.
2) Gateways and microservices should use their own database instances. You can use the same database instance in dev, but in prod each should have their own.
You can generate a docker-compose or kubernetes config for your gateway/microservices with the JHipster subgenerators, and in the generated YML files you will see each app has its own database instance.