Hi,
I would like to integrate spring-security-acl to manage permissions in my various aggregate. Should I create a different context to handle adding permissions or do I do it directly in my CommandHandler that manages the root aggregate?
Thank you in advance for your response.
If possible, I would annotate the commands themselves and use an interceptor to validate commands against the roles of the principal sending them.
If the acl’s depend on aggreate state, I would validate them inside the aggregate, as that’s the only place where consistent state resides.
What do you mean with adding permissions? Do you have an ACL per aggregate instance? In that case, you might not want to mix the permissions management with the ‘regular’ business logic. A separete context would be the solution. Again, an interceptor could use the query model of that context to validate incoming commands.
Cheers,
Allard
Thanks Allard.
I added acl spring annotations at my CommandHandler to check if the user has the rights to do this or that change. These annotations are of this type:
@CommandHandler
@PreAuthorize(“hasPermission(#command.accountId.identifier, ‘xxx.command.Account’, edit)”)
public void handle(){…}
It works fine. To add a permission to a user on an aggregate, I do it at my CommandHandler thanks to the UnitOfWork. I add permissions thanks the Spring Security ACL service when all events have been sent. I register a listener to add this permission with the “aftercommit” of UnitOfWorkListenerAdapter. Is this the right solution?
What you mean by separate context? Should I create a different context like a different CommandHandler to manage the addition and removal of permission in spring acl? If so, I do not see how …
Cheers,
Nicolas
I wasn’t sure if what you were attempting to do was the checking of authorizations, or the management of authorizations on a user. The latter can be done in a different context (where you would expect a User aggregate or an Account with roles and rights assigned to it).
Instead of putting the annotation on the handle method, I would put it on the command itself. That would allow you to define an interceptor that blocks the command as it is sent through the Command Bus. A few moments ago, someone sent a patch of a SpringSecurity interceptor (see http://issues.axonframework.org/youtrack/issue/AXON-281). That solution might work for you as well.
The issue with using the afterCommit is that you’ve spend resources (CPU’s, locks, I/O, etc) on an action that is blocked afterwards. It’s better to detect this prior to executing the command.
Cheers,
Allard
This is actually more sense to check the permissions level into the commands. I will use the AXON-281 patch to integrate spring security PreAuthorize annotations. This patch timely 
Thank you to explain me the issues about the use of aftercommit. I’ll be careful now.
To be more specific, Allard, I would like to check authorizations and manage the user permissions for a user for a specific entity. I add the permissions of a user with Spring Security Acl thanks AclService. In my case, after validating Authorizations in the command, when I create an account I add an admin permission for the user who creates the account on the object that he comes created. I do not see how using different context. Currently I do like that:
public void handle(CreateAccountCommand command) {
this.aclService.addPermission(Account.class, CurrentUser, ‘admin’);
Account account = new Account(command.getName);
this.repository.add(account);
}
Is this the right way?
Thank you very much Allard to spend your time to answer my questions.
Cheers,
Nicolas
Is the acl repository an entity within the aggregate? Afe you using event sourcing?
If both questions are answered with yes, gou should put the ‘add’ logic in an EventSourcingHandler.
If the first is ‘no’, consider the fact that using ‘external resources’ should be avoided as much as possible. Doing so will ultimately result in the same ‘spaghetti code’ caused by some other architectural styles.
Cheers,
Allard