You're right. I didn't notice that detail. I've implemented only the
SecurityIdentityRetrievalStrategy
and it's working great.
As always, thanks a lot for your advice!
2011/4/6 Johannes Schmitt <schmitt...@gmail.com>
> 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
>
--
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
