This content originally appeared on DEV Community and was authored by Atul Joshi
This is just not a post however I want like minded persons who have created the system gracefully with a rich model and scale from modular monolith to microservices, to discuss their approach, what worked for them and what not, and what was the learning.
Many times we start small and create a simple MVC CRUD like application using some framework for pilot and quick release to go to market validation.
Usually developers create a configuration file with some roles and permissions assigned or do a route level check. If route has read, write, update or delete permissions.
So basically roles like, users, admin, retailer, customer, internal admin roles, etc.
Then permission : C, R, U, D
Modules, Features : These are majorly names of controllers as I see in many applications.
Then in routes middleware is called with user information taken from token or session based on what role can access which feature/controller and what permission level.
However this is good for small simple projects, good for learning some framework or projects used for internal or personal use.
When we want to create a rich domain model things need to be discussed in more detail as per use-case and within domains ubiquitous knowledge.
I have been on a DDD learning path recently so maybe a few things can be out of order.
Let's take a scenario in retail:
Problem Statement:
** Core Domain: **
A retailer can create bills and share the bills with their customers (one who purchases the product from the shop). A retailer can also assign staff to create bills on this behalf.
....
....other use-cases
** Supporting Domain **
Customer Support:
Customer support members will reach out to customers (Here customers for customer support team are retailers), they can take retailers' query and give necessary tele call support..
...
....other use-cases
** Generic Domain **
IAM: User sub domain can be used for authentication and authorisation.
Use Case: 1
A retailer can only edit his own bills/Invoice or can allow his selected staff to edit bills/Invoice. Admin can also edit the bills/Invoice for retailers.
User Domain:
What are all the possible roles ?
Retailer, Staff, Admin, Customer Support Member
There are few questions:
Now who is customer?:
A customer (end user one who purchases the product) in the core domain.
or
A retailer in the customer support domain.How do we define this role?
*What are permission levels? * It's just the same as CRUD, like a small application or more detailed permissions?
Where do these permissions apply ?
*Should we write these permissions at controller, service or domain layer ?
Each has its own pros and cons.
*How do we start from modular monolith and scale later.
My Solution:
We can have a configuration file based on sub domains or BC we decided.
So we can define roles like:
iam.billing.retailer
iam.billing.customer
iam.billing.admin
iam.billing.staff
iam.customer-support.customer
iam.customer-support.customer-support-member
So here iam.billing.retailer and iam.customer-support.customer can be two different roles being assigned to same entity.
We can define permissions to be specific to the domain/bc as per the use-case,
Like "generateInvoice", "viewInvoice", "changeInvoice".
We can assign these permission to different roles from outside and this will make changes more configurable and can be even moved in future to other external service or LDAP.
Then we can call the authorisationCheck("{activity_name or permission}") in each use-case instead at router or controller.
As we can call these application layer use-cases from different event subscribers by passing controller which is more based on HTTP concerns only.
For more detailed cases where we need information form the specific domain persistence, we can use that part in domain as these are more close to business logic.
In domain we can save the duplication of code being done in multiple use-cases which have same BL being used.
*Reference Links: *
Authorisation based on activity rather than roles-permission match:
Access Control in Domain Driven Design:
This content originally appeared on DEV Community and was authored by Atul Joshi
Atul Joshi | Sciencx (2023-03-08T15:18:12+00:00) DDD : Authentication and Authorisation, How to achieve?. Retrieved from https://www.scien.cx/2023/03/08/ddd-authentication-and-authorisation-how-to-achieve/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.