Your idea is sound except for the behavior of the
PermissionGrantingStrategy. If you take a closer look, you'll see that the
first applicable ACE will make the ultimate decision for the permission
bitmask. Only if you check for more than one mask, the loop will continue.
Also see the documentation for the difference between "permission
attributes", and "permission bitmasks".
Kind regards,
Johannes
On Tue, Apr 5, 2011 at 10:41 PM, Gustavo Adrian <comfortablynum...@gmail.com
> wrote:
> 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
>
--
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
