On Mon, Jul 19, 2010 at 11:59 AM, Andreas Maunz <andreas at maunz.de> wrote:

> Luchesar V. ILIEV wrote on 07/19/2010 10:53 AM:
>
>  Therefore, I'd like to ask for your opinion: is there a need to place
>> the protection at component level such that would outweigh the
>> additional technical burden. In fact, there's extra burden if we
>> protect at the root as well, because we need to have a mechanism to
>> "reroute" queries for specific components to the root policy.
>>
>
>
In principle, such "rerouting" can be done by the service itself.  For
example, the dataset service no doubt keeps information which compound
belongs to which dataset , and therefore, upon /compound GET request, the
service can request Authz for the relevant dataset.

This brings the issue what should happen if a compound belong to several
datasets with different policies.





> As Luchesar pointed out, we suggest to protect resources for compound
> datasets only, e.g. datasets, models, validations.
> Otherwise, since everything is exposed as resource URI, in the most extreme
> case one could also register single feature values, such as 'true' or
> 'false'.
>

Indeed.  But we have Features exposed via API, not feature values anymore ;
feature values are only exposed via dataset API.  Regarding features, the
same strategy as for compounds could be used.

Regards,
Nina


> On another note, I have now implemented DNS checking. The policy webservice
> accepts now only policies where the IPs of the resources match the IP of the
> client webservice. The idea is to prohibit registering resources from any
> computer, which is a security issue, as discussed earlier on this list.
>
> Specifically, for any policy p submitted by client c, for any resource r
> contained in p, it is enforced that URI(r) = URI(c).
> Thus, resources must always be identified by a FQDN or directly via IPs
> with one exception: You may use 'localhost', e.g. for testing.
>
> Please tell me if this fits your needs/requirements or if it presents a
> problem for you.
>
> Best regards
> Andreas
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>