Domain-Driven Design – Implementing Users and Permissions

authorizationdomain-driven-designimplementationspermissions

I am working on a small application trying to grasp the principles of domain-driven design. If successful, this might be a pilot for a larger project. I'm trying to follow the book "Implementing Domain-Driven Design" (by Vaughn Vernon) and trying to implement a similar, simple discussion forum. I've also checked out the IDDD samples on github. I have some difficulties adopting the Identity and Access to my case. Let me give some background information:

I (hopefully) understand the reasoning behind separating the users and permissions logic: it is a supporting domain, and it's a different bounded context.
In the core domain, there are no users, just Authors, Moderators, etc. These are created by reaching out to the Identity and Access context using a service and then translating the received User objects to and Moderator.
Domain operations are called with a related role as a parameter: e.g.:

ModeratePost( ..., moderator);
The method of the domain object checks if the given Moderator instance is not null (the Moderator instance will be null if the user asked from the Identity and Access context does not have the Moderator role).
In one case, it does an additional check before altering a Post:

if (forum.IsModeratedby(moderator))

My questions are:

In the latter case aren't the security concerns blended again into the core domain? Previously the books states "with who can post a subject, or under what conditions that is permitted. A Forum just needs to know that an Author is doing that right now".
The role based implementation in the book is fairly straightforward: when a Moderator is the core domain tries to convert the current userId into a Moderator instance or into an Author when it needs that. The service will respond with the appropriate instance or a null if the user does not have the required role. However, I can't see how could I adapt this to a more complex security model; our current project I'm piloting for has a rather complex model with groups, ACLs, etc.

Even with rules that are not much very complex, like: "A post should be edited only by its Owner or an Editor", this approach seems to break down, or at least I don't see the correct way to implement it.

By asking the Identity and Access context for an OwnerOrEditor instance doesn't feel right, and I would end up with more and more security-related classes in the core domain. In addition, I would need to pass not just the userId, but the identifier of the protected resource (the id of the post, forum, etc.) to the security context, which probably should not care about these things (is it correct?)

By pulling the permissions to the core domain and checking them in the methods of the domain objects or in the services, I'd end up at square one: mixing security concerns with the domain.

I've read somewhere (and I tend to agree with it) that these permission related things should not be a part of the core domain, unless security and permissions are the core domain itself. Does a simple rule like the one given above justify making security a part of the core domain?

Best Answer

It's sometimes difficult to distinguish between real access control rules and domain invariants borderlining on access control.

Especially, rules that depend on data only available far into the course of a particular piece of domain logic might not easily be extractible out of the domain. Usually, Access Control is called before or after a domain operation is performed but not during.

Vaughn Vernon's assert (forum.IsModeratedBy(moderator)) example probably should have been outside the Domain, but it is not always feasible.

I would need to pass not just the userId, but the identifier of the protected resource (the id of the post, forum, etc.) to the security context, which probably should not care about these things (is it correct?)

If there's a Security BC and you want it to handle that logic, it doesn't have to know what a Forum is in detail but :

It could just have knowledge of concepts like "moderated by" and grant or deny access rights accordingly.
You could have adapter logic that subscribes to Core Domain events and translates them to simple (resource, authorizedUsers) key value pairs for the Security BC to store and use.

Related Solutions

Object-oriented – Filesystem like permissions for C++ type-members

Rephrasing the problem a bit:

I have an instance of MySpecialObject
an instance of JLP wants to call the methods of MySpecialObject
an instance of BEV wants to read the public data of MySpecialObject
the instance of JLP shouldn't be able to read public data and the BEV shouldn't be able to call member functions

This should be as type-safe as possible.

A solution I see involves wrappers :)

you write the code for MySpecialObject as you would normally, ignoring this extra requirement
you write a wrapper for each aspect of your class you wish to restrict. Say, MySpecialObject_Read and MySpecialObject_Execute.
these wrappers forward the requests (method calls, getter/setters) to an underlying shared_ptr of MySpecialObject
your MySpecialObject, MySpecialObject_Read and MySpecialObject_Execute classes each have (as needed) a "convert to ..." method. This method returns an appropriate wrapper over the underlying MySpecialObject

This solution provides a type-safe accessor with the desired limitations.

Each client class can choose what kind of access it needs. (And since you write these classes, you know what access you need.) If that is not acceptable, you could add factories that only create wrappers with certain limitations depending on a "token". That token might be the RTTI information of the calling class instance, although this could be abused.

Does this solve the original problem?

EDIT:

Remember that since you are the programmer you can instantiate an A whenever you want. By adding your class to a friend list or whatever...

What this solution provides is a clearer interface. Removing the explicit conversions probably makes it safer but less flexible. But, since they are explicit, you can easily look for them in the code and treat them as signs your architecture has a flaw somewhere.

Specifically, you can have code like this:

shared_ptr<A> * a = new A(parameters);

A_read aRead(a);
A_execute aExec(a);
A_write aWrite(aExec);

logger->Log(aRead);
view->SetUserData(aWrite);
controller->Execute(aExec);

Here there is an explicit conversion between an execute wrapper and a write wrapper, but you can decide on this based on your specific requirements.

But, with little effort (knowing which conversions are valid), just by looking at the call locations you can see that (with confidence!):

the logger will not change the state of your A
the view will not call methods on your A (other than setters)

This is true even if those particular method calls end up calling hundreds of other methods, more than you'd like to examine by hand.

At the cost of a few thin wrappers you gain the ability to see at a glance what a particular function call will do with the parameters you send. This may help a lot during debugging by helping you eliminate some branches from your investigation and, in general, would help people trying to understand the program.

I couldn't really find other reasons for using this ACL idea, at least ones where the costs don't outweigh the benefits. However, it does seem more intuitive than the visitor solution mentioned in the other answer.

Vernon’s book Implementing DDD and modeling of underlying concepts

1) The models of books in different stages refer to the same book. I wouldn't say that they refer to the same underlying concept because the concepts are different in the different contexts. They do refer to the same book in that the identity of the book is shared among the BCs.

2a) As with the book, they refer to the same identity but express different aspects of that identity in a specific context. Sort of like a single object implementing multiple interfaces which embody the roles that object plays.

2b) It isn't duplication of concepts because the concepts are different, only the identity is shared. Remember, the goal of DDD and programming in general is to create a model of your domain. All models are incomplete, but good models provide utility.

2c) You can say that a Moderator is a role played by a user in a specific context.

3) Same as above. They refer to the same identity, the same person, but different roles.

UPDATE

Does having two model elements ( both within same BC ) , each representing different aspect of the same underlying concept, result in what Evans calls duplicate concepts?

I don't recall what Evans called duplicate concepts so not sure.

I thought terms "representing different aspects of an identity within particular BC" and "representing different aspects of the same underlying concept within particular BC" are interchangeable ( ie they mean the same thing )? If not, how do they differ?

This may be a linguistic issue. The way I see it, an identity can have different concepts associated with it depending on the context.

I assumed each role represents a particular aspect of the underlying concept, but you're saying it doesn't? What then does role model and how is the thing that role models conceptually different from an aspect of the underlying concept?

Again this seems to be a linguistic issue. You use "underlying concept" to refer to identity which I think isn't clear enough to distinguish from simply "concept" which by itself isn't sufficient.

Best Answer

Related Solutions

Object-oriented – Filesystem like permissions for C++ type-members

Vernon’s book Implementing DDD and modeling of underlying concepts

Related Topic