I am using AWS API Gateway and would like to construct multiple API's for a set of Spring Boot micro-services that exist behind the scenes, but do so automatically.
For example, lets say I have a User and Contract Micro-service and they expose a simple CRUD, I would like to make 2 API representations inside the API Gateway for these 2 micro-services however they will be in the context of an Admin and a User.
The Admin API would have full access to all operations (CRUD) of both micro-services, however, the User API would only allow Read from both micro-services.
My question is about maintaining the representation of these 2 API contexts (Admin and User) is there any way to easily generate the swagger(s) that I would need that I can synchronize the API Gateway with without having to manually maintain this? Or is there a better approach that others are doing that im missing?
I have found spring fox which I was able to use and generate the swagger defs for the API at the microservice levels, but this only satisfies the Admin Use case and not the User one from what I can tell.
Has anyone found an elegant solution to this?
Related
i have a spring boot application that provides an API consumed by a frontend app (CRUD operation). This spring boot app is based on oauth2.0 authentication standard to verify the JWT access token received in the header of each API against an authorization server. I want to provide another API to be consumed by a backend (M2M usage). This API will rely on same database (same entities) but it will be slightly different (only Read operations are allowed here and responses contain more fields). Also this new API will rely on an another authorization server to verify the JWT token.
Firstly, i was thinking to provide both API with the same spring boot application, but it looks like it will a hack to support both (for instance issuer uri of the token are diferent, port can be different, path of API are different..).
So, I'm now thinking to separate the 2 APIS into 2 different spring boot application, so that the apps are isolated by nature, but i'm not sure it's a good practice at the end? For instance, what about the concurrency issues that can occur with such design ? In the opposite, can i build easily teh 2 spring boot apps that share the same code repo (some code should be common for both apps). Those are the questions i have, so any suggestion will be appreciated.
You can try with multiple authentication providers. Example given in following -
Java Spring Security config - multiple authentication providers
I wanna refactor a monolithic spring boot application basically a web app with login and functionalities for customers. We already have a Security implementation which works with a session id stored as a cookie but I dont have much knowledge about it at all and im completetly new to this topic. It seems JWT is a better solution for Microservices because of an independent authentication service.
So my questions are:
is it alot of work to create a JWT authentication service and exchange the session id implemenation? (since im doing it for my bachelor thesis and have a clear deadline)
can I stay at the session ids while using microservices?
are there maybe other ways to implement authentication?
is it alot of work to create a JWT authentication service and exchange
the session id implemenation? (since im doing it for my bachelor
thesis and have a clear deadline)
This question is hard to answer, as it depends how tightly coupled your particular implementation is. It's certainly not trivial.
can I stay at the session ids while using microservices?
Yes, but you need to figure out how to federate sessions across the microservices (i.e. how to get the information in the session from one service to the other). Overall, this represents a risk of tight coupling between services, so I'd recommend treating this as a transitionary step only.
are there maybe other ways to implement authentication?
As many as the day is long. That being said, without specific reason to do otherwise, I generally prefer to stick to the middle of the road.
Typical user sessions is not recommended in microservices.You should use Stateless architecture and tokens (Tokens stored in database or JWT).
It's better to use Spring Boot OAuth2.
You should implement an Authorization server and Resource servers with Spring Boot.
Authorization server:
Choose the token storage method (JWT,Jdbc,...)
Configure client details
Add a RESTful Api for user info or enable /oauth/check_token api.(Called by Resource servers)
Resource servers:
Set user-info-uri or token-info-uri in Spring boot OAuth2 properties.
Extends ResourceServerConfigurerAdapter class for securing url mappings.
I saw in many tutorials that we need to go back to gateway and generate an entity after generating a microservice application with the same entity.
Can someone explain me, the architectural benefits of doing so?
What is the goal of generating those entities again in Gateway?
One of the points of doing that is to implement the Backend for Frontend pattern.
Basically you proxy all calls from your front-end to your microservices through the gateway. For convenience reasons the frontend is packaged together with the gateway.
JHipster just adapted the exisiting entity generators from monoliths to let users generate the backend and front-end of an entity separately on microservices and gateways respectively. Of course this is an optional feature and you are free to use it the way you want.
You can use different ways for different purposes to reach the service a microservice is offering to you. As mentioned here you don't have to use AngularJS or Angular, but you can also use React and/or Ionic.
In general you can use more than one gateway to all or only a choice of microservices per gateway (a very good example implementing different gateways is shown here).
I am having 4 different micro-services in my application. The technology stack that I am using for the development of applications is SBT stack(Scala,Akka and Play web framework). For external clients to communicate with my micro-services, I have security mechanisms such as authorization and authentication of users using Oauth protocol, White-listing Allowable Http Methods and performing input validation. However, I wanted to know 2 things
1) Is it necessary to implement security mechanisms when one microservice calls another microservice internally
2)And if required, how to implement security on messages passed from one micro service to other. Any help would be highly appreciated. Thanks in advance !!!
I have a RESTful API built with Spring 3.1, using Spring Security as well. I have a web application, also a Spring 3.1 MVC application. I am planning to have mobile clients accessing my REST API. So my API is the central place to authenticate, get data served from, etc.. It all makes sense so far.
Now what I cannot wrap my head around is how to add Spring Social in an easy and smart way. How did you do it? Did you maybe only move the ConnectionRepository to the API? Or did you have the API do it all? I want to prevent double-authorization for each client-technology by all means (preventing double-authorization meaning userA connects to facebook in the webapp, and then starts using our mobile client and should NOT be asked to connect to facebook again just b/c userA is using a different client).
Thanks for sharing your thoughts!
The solution we use it to secure our rest-webservices using spring security, with a cookie based remember me service. This uses well documented traditional spring-security techniques.
We then plugged in spring-social to our system, which then simply logs in the user as normal using spring secruity. The social api looks up the, for example, facebook id in your db table, if it finds existing connection logs the user in using their account on your system (and can redirect to sign up page etc).
I suggest breaking down the question into more specific areas.