Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In my microservice architecture project ,it would have oauth service to authenticate the user and the gateway work as the front end api.
My question is where to write the register logic ?
In the oauth service or in the gateway?
Finally solution:
I do that in the user service and call from the gateway. Everything seems to work fine！
I believe best way is to place all authorization logic into library that is shared across microservices via private artifact repository. This library can configuration beans that can be component scanned when this JAR library is on classpath. component scan might be automatic, if you structure your packages wisely. Or you may want to make that scanning or including this shared logic explicit.
This way you might remove OAuth authorization logic duplication, which would otherwise be present.
Of course I am assuming that your microservices are Spring/Java based. If your microservices would vary programming languages, your authorization logic will be duplicated.
BTW, via shared library, you can cover also other cross cutting concerns of your Java/Spring microservices (monitoring, error hangling...). I've seen this working very well for teams working on 20+ microservices.
EDIT: Original response container workd "authentication", but I meant "authorization". Sorry for that confusion. "Authentication" should be in OAuth performed by separate dedicated service. This is not cross cutting concern, because there will be only one service accepting crendentials and returning back Oauth token. The best solution is to use third party OAuth provider, because you don't need to deal with credentials -> less security concerns for you. "Authorization" is cross cutting concern.
User registration is a separate bounded context so a separate microservice is the best approach. There is a blog post about this here.
Authentication is a cross cutting concern that could be handled by the API Gateway. This would free the upstream microservices of this responsibility - their main job is not verifying that a user is who he claims to be.
Authorization should be the responsibility of a dedicated microservice. It could be called by the API Gateway or by individual microservices.
P.S. My answer assumes that the microservices are not directly accessible from the outside, they can be reached only by the API Gateway.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 months ago.
Improve this question
My question is theoritical (I am not asking the steps about scaling) and related to keep the same performance.
For example our web site (Spring Boot based) is visited 100 person / day and after a year is şs started 1.000.000 visit per day. In this situation, I have the following ideas basically, but need to know more and if these ideas are good or bad:
Using Cloud services
LOad balancer
Using microservices and applying distributed system techniques.
If read operations are much more than write or update, a NoSQL db can be used.
If we use jwt token for authentication, dstributed system would not a problem for security auth side I think.
... etc.
Could you pls share your ideas and comment the idea above? Any help would be appreciated.
There have been several POC( proof of concept ) and proved deployment strategies for better availability.
Keeping your points, I am summarizing and possibly giving a bit more clarity!
Using Cloud services --> This is the platform you choose for e.g. One can choose on-premise service deployment or on cloud such as AWS,Azure GCP etc. Not related to scalability question at the moment.
Load balancer --> Balance the load when you have multiple instances of your Microservice, so for e.g. You can create docker images of your microservice & deploy as a Pod on Kubernetes platform where you can have more than one Replicas (Replica is copy of your same service). Load balancer will balance the HTTP requests among multiple pods.
Using microservices and applying distributed system techniques --> You can but make sure to adhere to best practices and proven Microservice deployment strategies. Read more about the more about them here https://www.urolime.com/blogs/microservices-deployment-strategies/
If read operations are much more than write or update, a NoSQL db can be used. --> Definitely, infact you can decompose your microservice based on number of transactions or read/write operations & you can use NoSql DB like Couchbase or MongoDb
If we use jwt token for authentication, dstributed system would not a problem for security auth side I think. --> Again such mechanisms are usually centralized and JWT token has some time validity!
So there might be several other options of scaling but most used is the one I mentioned in point 2.
I highly suggest you get a grip on basics, Here are few links which would be helpful!
https://microservices.io/patterns/microservices.html
https://medium.com/design-microservices-architecture-with-patterns/decomposition-of-microservices-architecture-c8e8cec453e
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
My apologies as the realm of this question is very broad. We are starting on a new journey of defining microservices and starting with a DDD (We are based off .NET tech stack but I reckon for purposes of discussion this topic is independent of the stack)
At this moment, we have roughly identified the domains and we have defined layers like Domain Layer, Infrastructure Layer, Application layers. So for example if we have a customer / client we have defined the following layers for like so. The point where we are really getting confused is how this microservice with other service which are not microservice per se. Say for example, if there is a rule that a CreateCustomer command, as a part of its creation, needs CreditScore verfication and if this service is provided by some external provider via a facade that could be written in house, how should a microservice communicate with such a service?
Are there any patterns or any recomendation re how such microservice to other services communication needs to be defined? Any recomendations / suggestions are welcome.
services dependency manager
+ protocol (REST/RPC/native API's)
+ circuit breakers
just like any other micro/service would do.
Don't understand why (external) micro/service is not just another micro/service for your system.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm making an Spring MVC application, with some users but only ONE role for all (user_role). Do you think is necessary to implement Spring Security even taking only one role in my application?
Thanks,
Security is more than simply authorization (given I know how the user is, are they allowed to access the resource). Fortunately, Spring Security provides an easy means to do more than authorization:
Security is also about authentication. Authentication is securely identifying who the user is (i.e. comparing a username/password). This may seem trivial, but keep in mind you should store passwords securely (i.e. using BCrypt), ensure you protect against session fixation attacks, protect against timing attacks, etc. All of these Spring Security provides for you out of the box.
There are all sorts of attack vectors that Spring Security helps protect against (i.e. CSRF, XSS, Content Sniffing, Click Jacking, etc). You can implement all of these protections yourself, but first you need to know the attack exists (many of these are protected without any additional work on your side), then you need to understand how to secure your application from the attack (and keep this information up to date), the list goes on.
Providing defense in depth is critical to security. Spring Security allows you to easily add method based security as well as URL based security.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'd like to get peoples thoughts on a scenario I'm about to encounter.
I've been tasked with building a RESTful Web API Service that will be used by two client applications.
One client application will be a web application and the other client will be a mobile application.
They are two distinctly different applications that are targeting the same data-store. I imagine that a lot of the requests made by both client applications will be of shared interest.(They may want to receive slightly different messages back in terms of the model objects they request).
But ultimately there will be differences, and I don't want to expose parts of the service that are designed for an individual client app to all other clients.
I've been looking at Versioning with ASP.NET Web API, where i can create the same controllers multiple times and create custom constraints to controller selectors that switch out the controller depending on the version used in the URI.
Is this a good idea in my scenario, or should i really be building two API's, one for each specific client application?
First of all, if you want client A to access certain resources while client B shouldn't, you're going to implement authorization like OAuth2.
In the other hand, I doubt that the solution should be implementing 2 different APIs or overcomplicate the code of a single API to return the same response with some differences.
Furthermore, you can emit same DTO for both clients and map the generic DTO to a domain object or other DTO using AutoMapper in order to avoid the hassle to manually set properties from one object to the other.
Finally, you can also use an OData interface to your RESTful API to let the client decide which properties you want to return in your entities or perform other operations during the request and get just what you need in each case.
Conclusion/summary: you shouldn't adapt the REST API to your clients, but the clients should adapt themselves to how the API works. At the end of the day, you're returning JSON entities and you can map them to any class even if the structure is different using AutoMapper as I said in the first paragraph. You can even implement a custom serializer if needed. It will be less pain than duplicating the server code because some differences.
What would happen if you add a third client and says "I want also a different structure in returned entities", add even a fourth one! You're going to get crazy, aren't you?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
today I started reading about Microservice architectures - and it seems to be very interesting!
But I have one doubt I need some explanation on:
Assume I want to create a blog and would build 4 microservices for that: User/login Service, Article Service, Comments Service and Reporting/analytics Service(not a realistic example, I know...).
The Reporting/Analytics service is purely backend - no issue here for my understanding.
But the three others involve some UI part - and as to my understanding this UI part should also be part of the microservice itself, right?
How would the UI integration work? Would I then have a 5th "front door" service that collects the user requests, forwards them to the other services which then answer with HTML/CSS and the front door service would then compose the individual responses into what is returned to the user?
Any chance, you have an example/use case for such a scenario?
Thanks and regards!
From my experience, in a microservices architecture, it is often useful to have a service that acts like an API gateway that front loads to the more domain specific microservices that does the work. The responsibility of the API gateway could be to aggregate results and return them to the front end but consolidating responses that are returned from the microservices would be coupling the knowledge of the two services and leaking some domain knowledge into the API gateway layer. The API gateway should probably be as thin as possible and should reach out to services to accomplish something.
The use case here that you're describing would be trying to authenticate the user before reaching out to the login service and then the article or comments service. Altogether the front end would still stay monolithic if they are a part of the same application.
If the application becomes big enough, the application would be separated by products but probably still rely on a core set of services. In that case, they would probably live in different UIs so that would make it less complex (kind of like microservices on the back end). Just as a side note, that a microservices architecture usually introduces a set of core services that can be utilized by different teams and therefore different applications that have different UIs. An example being an ecommerce application, that has customer service department editing orders for servicing customers and customers using an orders service to make purchases. In effect, these are two applications and they will have two different UIs. Hope this helps!
The other thing that I'd like to point out is that a microservices architecture is only great when the application becomes too large and complex. A microservices architecture requires more resources as it has some additional overhead. Start with a monolithic first :).
There are a couple of different approaches that you can take. If it makes sense each microservice can have its own pages that it can render. Then you only need a front end that can create the appropriate navigation for the involved services. The menu is built for the application, each service presents its own UI. This approach works well when you need to have the ability to include or exclude services from the application, for instance, based on licensing.
Alternately, each microservice can provide a set of HTML Fragments. Then you need a front end service to compose the pages and navigation. The fragments must all use the same vocabulary for CSS or whatever means you use to define the look and feel. This approach can lead to odd pages when HTML fragments are composed without one or more service that might be included.
Finally, a complete application UI can be built on top of the microservices. This can result in a "tighter" UI with a better flow. It also will typically take longer and be more difficult to change as new services are added.
What is the best? As with most cases in software development, it depends on what you are building. In the case of the Blog application, you described I suspect that each service could have its one full page UI. More commonly having a full UI is the approach I have seen. The HTML Fragment approach is more versatile but takes longer to develop initially. Once it is built though you will have more flexibility in how you deploy your application. This could be a real benefit for a Software Product company.
Hope that helps.