Spring Security ACL and root aggregate

[Nicolas GUERRIER]

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.

[Allard Buijze]

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

--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nicolas GUERRIER]

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

[Allard Buijze]

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

[Nicolas GUERRIER]

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

---

Lauréat au concours national 2010 + 2012

Nicolas GUERRIER CTO & Co-Founder  +336 61 64 79 73 +334 22 13 00 00 nicolas....@prediseo.com

Ensemble protégeons la nature, n'imprimez ce mail que si nécessaire…
Consider the environment before printing this mail...
***Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer l'expediteur par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme. 
*** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system.

Contact me:  nicolas....@prediseo.com

--
You received this message because you are subscribed to a topic in the Google Groups "Axon Framework Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/axonframework/LMTBlVmvjxM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to axonframewor...@googlegroups.com.

[Allard Buijze]

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