Let say we are build an ecommerce application for web and mobile using REST API with Admin, Merchants and customers roles using Laravel/Lumen.
Is it a good best practice to have separated application for each roles with single database?
One application will usually suffice. It is usually best practice to have a single API (or a single set of microservices) where endpoints enforce your security policies for each role - rather than separate services for each role. This is more maintainable because these services typically share a lot of logic.
On the front end, it may be a different story. You might want a separate Admin app that has such different functionality that it makes sense to build it separately.
Related
I'm creating a software marketplace web app, and looking for some insights and suggestions about the architecture.
I would like to be owner of the UI, so probably a headless approach is the way to go.
The basic requirements contains:
I need to have multiple external identity providers (custom sites, not like facebook or google)
I need to have at least three roles
simple users who can buy stuff
users who can upload things available for sale in the marketplace
administrators, who has to approve everything that is uploaded to the marketplace
Do modern ecommerce platforms allow limiting certain API-s based on custom user's roles? Or allow registering custom external identity providers?
If not, would it be a viable option to put the ecommerce API behind one of my own microservices and do RBAC in one of my on MS?
I generally would like to do most of the customizations of the ecommerce externally, in my own microservices, instead of within the ecommerce platform itself - so I'm not bound to any specific language or technology. I would like to host the site myself, in a containerized environment.
Additionally, any suggestions about a platform that would fit the use case mentioned above?
We are currently using direct DB connection to query mongodb from our scripts and retrieve the required data.
Is it advisable / best practice to make the data retrieval from DB as a microservice.
It does until it doesn't :)
A service needs to get its data from somewhere and a database is a good start. If you have high loads you may find that you need to add a cache in the middle see this post from Instagram engineering https://instagram-engineering.com/thundering-herds-promises-82191c8af57d
edit (after comment)
generally speaking, a service should own its database and other services shouldn't access another database service directly only via its API. The idea is to keep services autonomous and enable them to evolve independently.
Depending on the size of microservice, that's now always practical since it can make the overhead of having the service be more of the utility it provide (I call this nanoservices). Also, if you have a lot of services you don't want to allow each one to talk to any other (even not via the DB) since you just get a huge mess. The way I see it there should be clear logical boundaries (services or microservices) and then within each such logical services you may find that it makes sense to have more than one "parts" (which I call aspects) e.g. they have different scaling needs or different suitable technologies etc. When you set things this way aspects can access the same database and services shouldn't (and you can still tame the chaos :) )
One last thing to think about - who said API is only a REST API, you can add views on top of the data that belongs to another service and as long as you treat that like an API (security, versioning etc.) you can have other services access that as well
We are developing a keycloak(5.0.0) based solution where our clients can create their account with us and manage their own users - and only their users.
Initially with thought that we could use realms for this. Every client gets their own realm. After initial testing we deemed it might not be a good solution as after creating ~500 realms the application becomes unresponsive(https://issues.jboss.org/browse/KEYCLOAK-4593).
We decided to try using Groups to emulate a tenant. Our objective is to create during an external process(keycloak REST API) a group with an admin user.
Can't find currently a way how to restrict this administrator to be able to only manage their own group(creating subgroups, managing users, and giving them roles).
I've noticed several emails mentioning these features but I fail to find actual examples to make this work.
http://lists.jboss.org/pipermail/keycloak-user/2017-June/010882.html
http://lists.jboss.org/pipermail/keycloak-dev/2017-June/009496.html
The second link shows exactly what we would like to achieve.
Current alternative I can see is to implement a facade(client or separate web app) which would restrict visibility and access to other groups.
Are there other alternatives?
I am working on an application where I need to setup identity server 4. I have an api as resource. and a web forms application as client.I have few roles like teachers, students, parents in my database. How can I use this custom database and perform authentication and authorization without using identity?
Please suggest.
From your other question here I get a better idea of what you want.
I think one solution for what you want would be to setup identityserver4 in a seperate project with its own seperate database. I noticed the tag identityserver3, but I think it is quite safe to go for identityserver4. It shouldn't make a difference for the client/user since they are conceptually compatible.
1) Give your application a client/secret (which you configure in identityserver) in order to identify your application and grant access to the resource api. Here is some information: http://docs.identityserver.io/en/dev/quickstarts/1_client_credentials.html
You'll only need to configure one client to protect your resource from the outside. The only way to access the resource api is through your application, since your application is making the actual calls. This is also the drawback, you cannot expose the token to the outside world.
Since your client isn't the actual user, you'll need to identify the user. You can use any mechanism based on your current model as you like. A simple user/pass (with or without asp.net identity) could be enough to determine the roles. But please keep in mind that your application has full access to the resource api.
2) However, since identityserver is available, why not use it? Why don't you want to use the identitymodel? I think you should consider to seperate the identity information and your datamodel. Your datamodel shouldn't be aware of the security. And the security has nothing to do with your datamodel.
When you create a seperate database for identityserver you have one place to configure the identity users. All you need is a reference (sub) to the user in the datamodel. http://docs.identityserver.io/en/dev/quickstarts/2_resource_owner_passwords.html
Add claims or roles and everything is in place and you'll see there is no need to keep identity data in your custom database. The structure of your custom database stays intact, including the user table but without the identity data.
I think this is a safer solution and considering the good documentation and sample projects it may even turn out to be a quicker solution.
I'm looking for some guidance on my research to building an SaaS. This thread seems to be related, but I'm wondering if this software Rackspace has called rBuilder is what I would be looking for to automate the process of creating an instance of the software with a unique IP address and domain name.
Also, for an application similar to Shopify, does the application work like Facebook where it serves up different information based on the account, or is it better to have separate installs of the software like WordPress, but on a server that you maintain?
IMHO, there are various levels of Multi-tenancy [level1 through level4], among them, the purest form of multi-tenancy [Level4] is to have a single code base to cater to the needs of different customers [tenant's].
In this case, you will be required to maintain all of the configuration metadata within your code base to ensure that each tenant has the capability to customize the application the way they wanted to.
Having a single codebase is very clean, easier to maintain, easy to patch, easy to onboard new customers etc...
Hence, kindly note that you have to decide on the time and expense that you have budgeted for the application that you have planned to as the purest form of multi-tenancy does require some more additional thought process.
You can consult some articles like this and also google on the pros and con's of having the purest form of multi-tenancy vs on-premise model or virtualized model of multi-tenancy.
Also read more from here