Ok I think I have an idea about this case. I'd appreciate if you can give me
your opinion about this. Having the scenario commented before I'd do the
following:

. First, I'd need to implement my own SecurityIdentityRetrievalStrategy,
since I have my own user - department tree. So I'd override the
"getSecurityIdentities" method with something like the following:

    public function getSecurityIdentities(TokenInterface $token)
    {
         $sids = array();

         // add user security identity
         if (!$token instanceof AnonymousToken) {
             try {
                 $sids[] = UserSecurityIdentity::fromToken($token);

                 // This is the only thing I'd change
                 $user = $token->getUser();

                 while (($entity = $user->getParent()) !== null) {
                     $sids[] = new
UserSecurityIdentity($entity->getUsername(), get_class($entity));
                 }
             } catch (\InvalidArgumentException $invalid) {
                 // ignore, user has no user security identity
             }
         }
    }

So, $sids would have the $user and all its parents, in that order. The only
thing left that I'd need to implement is another PermissionGrantingStrategy.
This is because the default implementation keeps looking for a granting ACE,
even if an ACE has a DENY permission type. In my case, even if Department 1
has a permission VIEW = ALLOW on an Article, if User 4 has the same
permission but with a DENY, I don't want to keep checking up in the tree. I
want to deny its access as soon as possible. So I'd extend the default
PermissionGrantingStrategy and override the method
"hasSufficientPermissions" and, if an ACE is found for a given SID /
Permission combination, I'd return the $ace->isGranting() result. This way,
as soon it finds an ALLOW or DENY, it returns the result.


What do you think?

2011/4/5 Gustavo Adrian <comfortablynum...@gmail.com>

> Hi there!
>
> I recently came up with this question: How to implement ACL with a
> hierarchical tree of users and other entities? I had an idea before but now
> that I'm almost at the middle of the implementation and that I understand
> better the ACL I realized it was wrong.
>
> Having the following tree:
>
>
> Department 1:
>     . Group 1
>         . User 1
>         . User 2
>            . User 3
>            . User 4
>     . Group 2
>         . User 5
> Department 2:
>       ... etc
>
>
> I'd like to check permissions from bottom to top. ie: if I want to check if
> User 4 has permissions to VIEW an instance of Article, the following checks
> would take place (in this order):
>
> . Check if User 4 has permissions to VIEW the Object Identity Article with
> ID = 124 (suppose this is the ID of the Article)
> . If not, check if User 4 has the permission VIEW for the Object Identity
> representing the class Article
> . If not, do the first two checks but for the parent of User 4 (User 2 in
> this case)
> . If not, do the first two checks but for the parent of User 2 (Group 1 in
> this case)
> . If not, do the first two checks but for the parent of Group 1 (Department
> 1 in this case)
> . If not, he/she has no access to the Article.
>
>
> To implement this, I'd first create an ACL for the Object Identity
> representing the class. Then I'd create an ACL for the Object Identity
> representing the instance of the Article, and I'd set the ACL of the Article
> class as the parent of the ACL of the instance of the Article. I'd then
> assign Class and Class-field ACEs to the Article class ACL, and object and
> object-field ACEs to the instance of the Article's ACL. If this instance of
> the Article has a child, then this child's ACL would have as parent the ACL
> of its parent Article.
>
> You may ask why I create two distinct ACL for the class and for the
> instance. This was the easier way I've found.
>
> The user has three options available for each permission to choose from:
> INHERIT (This would only remove the corresponding ACE), ALLOW and DENY.
> These three options are available for the four kinds of permissions: Class,
> Class-Field, Object, Object-Field.
>
> Now, the only problem left is how to do the permission check based on the
> position on the tree of the user. I can't use the "setParent" feature of the
> ACL for this, because it's only for object identities, not for security
> identities.
>
> Which would be the best way to implement this?
>
>
>
> Thanks in advance!
>

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en

Reply via email to