Behavior of multiple ACL rules
Daniel E. Renfer
what the appropriate behavior should be, so I thought I would bring it
up here for further discussion.
If I post an activity with 2 ACL rules both relating to the same action,
what should happen if they contradict?
For instance, my first rule states that the view action is granted to
everybody, and then my second rule states that the view action is denied
to ham...@denmark.lit. Can Hamlet see it or not? Currently, canSee will
break out at the first view action. Meaning that only the grant to
everybody has any effect. This is most likely wrong and every rule
should be taken into account.
Personally, I think the order of rules should be significant. The first
rule would grant rights to hamlet, and the second one would override it.
End result, this action would not be visible to Hamlet if he is logged in.*
Fixing this would probably require making ACLManger's canSee return some
sort of "tri-state boolean" to specify if the user is explicitly
permitted, denied, or if the rule simply does not apply.
Daniel E. Renfer
* I am aware of the fact that If he were to log out and try to read my
activities anonymously, it would show up. This is just an example.
Vishal Patel
policies for handling ACL rules?
http://httpd.apache.org/docs/1.3/mod/mod_access.html#order
Daniel E. Renfer
First of all, the mod_access rules are probably a bit too simplistic as
they only deal with permitting or denying access based on ip / domain
name. We have the framework to control access to any of the CRUD
operations. I'm not quite sure how an update permission on my phone
number would work, but the semantics at the entry level are well understood.
One of the reasons it would be good to have multiple ACL rules working
is I can see servers supporting default rules where any of the user's
choices included in the message are simply appended to the acl rule list.
On that point, how do people feel about wrapping all the rules (applying
to the same element) in a single container element so that, for
instance, an Entry has at most a single acl:rules child. It makes the
sent stanza slightly more verbose, but would simplify processing.
I've been trying to look around for other projects with a fully fleshed
out ACL model (especially those involving Atompub) but I haven't found
anything really good yet. Anyone else have any good links?
Daniel E. Renfer
osw jid: du...@mycyclopedia.net
Renato Iannella
On 4 Aug 2010, at 00:28, Daniel E. Renfer wrote:
> I've been trying to look around for other projects with a fully fleshed
> out ACL model (especially those involving Atompub) but I haven't found
> anything really good yet. Anyone else have any good links?
We have been planning to write up an XEP for using ODRL [1] for permission/policy mgt in 1SW.
We have started the draft, but not yet completed.
I've attached some of use cases were are looking at the end of this email.
Let me know if this is on the right track...
Cheers
Renato Iannella
http://renato.iannella.it
=====================================
A simple example of a Policy is shown below is is a typical use case from the Publishing domain. In this example, the Display action is being assigned to "hamlet" from "william" for the eBook "romeo+juliet" as a Permission.
<policy xmlns="http://odrl.net/2.0/">
<permission>
<asset uid="urn:ebook:shakespeare:romeo+juliet"/>
<action name="http://odrl.net/2.0/action/display"/>
<assigner uid="wil...@shakespeare.biz"/>
<assignee uid="ham...@denmark.lit"/>
</permission>
</policy>
In the next example, the Translate action is being assigned to "hamlet" from "william" for the eBook "romeo+juliet" as a Prohibition.
<policy xmlns="http://odrl.net/2.0/">
<prohibition>
<asset uid="urn:ebook:shakespeare:romeo+juliet"/>
<action name="http://odrl.net/2.0/action/translate"/>
<assigner uid="wil...@shakespeare.biz"/>
<assignee uid="ham...@denmark.lit"/>
</prohibition>
</policy>
A use case from the online Social Networks domain would include the need to allow the public to view a status update as well as only your friends viewing and commenting on you photos. These two examples are shown below.
<policy xmlns="http://odrl.net/2.0/">
<permission>
<asset uid="urn:socialnetwork:user:shakespeare:status"/>
<action name="http://odrl.net/2.0/action/display"/>
<assigner uid="wil...@shakespeare.biz"/>
<assignee uid="http://odrl.net/role/everyone"/>
</permission>
<permission>
<asset uid="urn:socialnetwork:user:shakespeare:photo-album:romeo+juliet"/>
<action name="http://odrl.net/2.0/action/display"/>
<action name="http://odrl.net/2.0/action/comment"/>
<assigner uid="wil...@shakespeare.biz"/>
<assignee uid="urn:socialnetwork:user:shakespeare" scope="http://odrl.net/role/allConnections"/>
</permission>
</policy>
A use case from the online Newspaper domain would include the need to indicate that a News article can be republished as long as the source is attributed and the advertisement attached to the news article is also reproduced.
<policy xmlns="http://odrl.net/2.0/">
<permission>
<asset uid="urn:shakespeare.street.journal:article:2010:07:07:foo"/>
<action name="http://odrl.net/2.0/action/reproduce"/>
<duty>
<action name="http://odrl.net/2.0/action/attribute"/>
<action name="http://odrl.net/2.0/action/keepAds"/>
</duty>
<assigner uid="wil...@shakespeare.street.journal"/>
<assignee uid="http://odrl.net/role/everyone"/>
</permission>
</policy>
A privacy use case from the online Web domain would include the need to indicate that a Users' personal details can only be used to contact the User.
<policy xmlns="http://odrl.net/2.0/">
<permission>
<asset uid="urn:web.company:customers:hamlet@denmark:profile"/>
<action name="http://odrl.net/2.0/action/display"/>
<constraint name="http://odrl.net/2.0/constraint/purpose"
operator="http://odrl.net/2.0/eq"
rightOperand="http://w3.org/p3p:contact"/>
<assigner uid="ham...@denmark.lit"/>
<assignee uid="urn:web.company"/>
</permission>
</policy>
An extension of the above use case would include the need to indicate that the Users' personal details can only be retained for 6 months, then must be deleted.
<policy xmlns="http://odrl.net/2.0/">
<permission>
...
<duty>
<action name="http://odrl.net/2.0/action/delete"/>
<constraint name="http://odrl.net/2.0/constraint/datetime"
operator="http://odrl.net/2.0/eq"
rightOperand="P6M"/>
<asset uid="urn:web.company:customers:hamlet@denmark:profile"/>
</duty>
</permission>
</policy>
=============================
Vishal Patel
> First of all, the mod_access rules are probably a bit too simplistic as
> they only deal with permitting or denying access based on ip / domain
> name. We have the framework to control access to any of the CRUD
> operations. I'm not quite sure how an update permission on my phone
> number would work, but the semantics at the entry level are well understood.
Agreed. :) I didn't mean to lift the mod_access mechanism directly --
naturally IP/domain rules make sense for a web server like Apache, but
OSW demands more fine-grained control. However, Apache's parsing of a
configuration like "Order Deny, Allow" defines a precedence for their
ACL rules which might be an interesting way to think about your
intiial question.
