Announcement Announcement Module
No announcement yet.
ACL Usage Scenario Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • ACL Usage Scenario

    Hello All,

    I'm evaluating whether I need ACLs and wanted to access the charitable and intelligent folks in this community.

    I'll keep my scenario simple. I have two concepts: users and digital items for which the user can obtain access. Ordinarily, I'd just create an association between the two to represent access rights. However, I'm realizing this could be done with instance-based ACLs.

    So in doing so, would I bypass creating the association and instead just have a service create the appropriate ACEs? Or would I do both? Having not seen a canonical solution where ACEs are granted (short of the example, of course), I'm not sure how you would typically do this.

    I realize that additional context would probably help, but I'm keeping this simple. You could assume that access might be more complicated than has access versus doesn't have access.

    Any discussion would be appreciated.


  • #2

    My suggestion would be to go with your usual association regime unless you can see a wider use for ACLs in other parts of your application.

    ACL handling in Acegi is powerful, but it does take a little bit of time to get right, with a bit of infrastructure that needs to be plugged together. If you can afford to sink the time, go ahead. But if you just want to make the application go, don't worry about it.

    If you were to use ACLs you would need to add a service layer to create and manage ACLs, but you won't need to manage the association anymore. I would suggest that you should use ACLs where you need to control access, and use associations where you want to stipulate a relationship between objects. Don't mix things up, the sematics are quite different.



    • #3
      If you need relationships as part of good old OO design, by all means use them. It's not hard having your services layer create(), update() and delete() methods transparently manage the acl_object_identity table in addition. After all, the whole idea of a services layer is to coordinate this sort of workflow within the same transaction. If the relationship is not needed for normal OO (ie it exists exclusively for permissioning), I'd simply do it all via the ACL services and forget the extra class and relationship.

      The ACL services do take a bit of getting used to, and in many sitations people find using a custom AccessDecisionVoter is sufficient. Having said that, if your application was to support say users editing the ACLs that apply to instances, the ACL package will make life much easier. Especially given it can be used not only for invocation-time enforcement, but also querying if a user has a particular permission to a particular domain object instance.


      • #4

        Thanks all for replies!

        In the scenario I envision, a "digital item" would have consumers and producers and so each would have their own permissions. So ACLs seem appropriate in this case.

        I will have to give some careful thought as to whether the traditional OO relationships need to exist. The heuristic probably centers on the nature of the queries for the relationship. If they are security-centric-only, then ACLs-only is probably appropriate. I believe however, that I have a hybrid situation.

        So anyway, thanks for the help.