[Yanel-dev] Enhancing access policies re downward inheritance

[Michael Wechner]

Guillaume Déflache schrieb:
> Hi!
>
> Michael Wechner schrieb:
>> Hi
>>
>> According to
>>
>> http://www.yanel.org/en/documentation/security/access-policies.html
>>
>> one can stop inheritance upwards by setting the 
>> use-inherited-policies="false", but
>> there is no attribute which allows access to a node, but stop 
>> inheriting this access downwards, for example, one
>> wants to give access to the node
>>
>> /foo/bar/index.html
>>
>> but no access to
>>
>> /foo/bar/no/access/here.html
>>
>> whereas this can be required in certain situations (for example in my 
>> current situation ;-)
>
> Would be nice, but we have to be careful not to slow down access 
> control calculations too much...

agreed, whereas in this case it should be ok, because one can test this 
"attribute" at the very end, I mean only
if an appropriate usecase policy is actually found, and otherwise one 
never checks this property.

Also we might want to introduce caching of policies. We did this for one 
of our customers using ehcache and it
seems to work very fine
> And also do we currently have an "EXPLAIN" feature that, well, 
> explains why you can or cannot have access to a particular resource? 
> Or maybe we already do that piecewise in the log messages?

kind of ;-)
> Because the calculation is getting more and more complicated!
>
> Also could these two mechanisms be in conflict?

I would suggest to do this in the log message, because otherwise it 
could be used to breach security
>
>
>> hence I would suggest to introduce a property called "bequeath" as 
>> follows
>>
>> /foo/bar/index.html.policy
>>
>>  <usecase id="view">
>>    <group id="wyona" permission="true"/>
>>    <group id="customers" permission="true" bequeath="false"/>
>>  </usecase>
>>
>> which means the group "customers" can access the page 
>> /foo/bar/index.html, but
>> this group won't have access to  /foo/bar/no/access/here.html
>>
>> WDYT?
>
> I had to look up "bequeath" in the dictionary :) so I suggest we use 
> more pidgin/IT English like:
> - "cascade-policy"
> - "propagate-policy-downwards"
> - "force-policy-on-children"
> - "make-children-obey-policy"
> ! ;)

makes sense to me as well. We have to differentiate between the API and 
the implementation though.

Cheers

Michi
>
> Cheers,
>    Guillaume