Hi Luchesar,

On 13 January 2011 08:19, Luchesar V. ILIEV <luchesar.iliev at gmail.com>wrote:

> On 01/12/2011 14:54, Nina Jeliazkova wrote:
> > Hi Tobias,
> >
> > On 12 January 2011 14:43, Tobias Girschick <tobias.girschick at in.tum.de
> >wrote:
> >
> >> Hi Nina,
> >>
> >>
> >> On 01/12/2011 01:32 PM, Nina Jeliazkova wrote:
> >>
> >>> Hi Tobias,
> >>>
> >>> On 12 January 2011 14:27, Tobias Girschick<tobias.girschick at in.tum.de
> >>>> wrote:
> >>>
> >>>  Hi Nina,
> >>>>
> >>>> well, as
> >>>>
> >>>> /dataset/{id}/compound
> >>>>
> >>>> gives a list of all compounds in the dataset this should be definitely
> >>>> protected. /dataset/{id}/feature could maybe left without policy.
> >>>>
> >>>
> >>>
> >>> I guess it depends  - if features refer to sensitive data , it might
> make
> >>> sense to be protected.
> >>>
> >>>
> >>>  We are not sure about the metadata.
> >>>>
> >>>>  OK, then the next question - if we want  /dataset/{id}/compound to be
> >>> protected , should a policy to "/dataset/{id}/compound"  be registered
> as
> >>> well,  or we could have one "top level" policy  (this does not work at
> the
> >>> moment ) ?
> >>>
> >>
> >> Well, the easier way would be to register an additional policy, but
> having
> >> just one policy for everything beneath dataset/{id}.... sounds tempting.
> >
> >
> > Yes :)
> >
> >
> >> But that would mean to introduce wildcards to the policies, right? And
> that
> >> is something that might complicate things, although I am not aware of
> the
> >> exact reason we have/had not to use wildcards,
> >>
> >
> > It was decided for security reasons not to use wildcards, otherwise, one
> > could register  http://tu-muenchen.de/* once and not let the  services
> > register specific URIs upon creation, e.g.
> > http://tu-muenchen.de/model/idwhen amodel is created.
> >
> > Perhaps Andreas could comment and suggest the right behaviour.  There is
> > also subsequent question what do we do with compound URIs  that belong to
> a
> > dataset ... do we need policies for every single URI of a compound in a
> > protected dataset ?  Wildcard policies would help a lot.
>
> Now that I think of it, are the wildcards really that evil? If we had
> just random URIs, that would indeed be the case. But it's my impression
> that, at least for most things, we have pretty well structured URIs...
>
> /{type_of_resource}[/{id}][/...]
>
>
There are only few cases with more than two levels (e.g. for datasets and
models , if I remember right).

I would say (generic) wildcards are still bad thing, because these could
allow anybody to register policy of the top level (e.g. /model ), and
effectively forbid anybody else to create models under this top level URI.


So, if we restrict the wildcard usage to the sub-{id} level of the URI,
> that would allow much simpler policies without compromising security
> (and actually even strengthening it, since it's less likely you'd miss
> to protect some elusive component of the resource).
>
> Of course this isn't quite an universal solution, but if it works for
> most (and most important) things, and if they could be easily defined so
> that we're able to apply the wildcard usage to them only, then probably
> that is the way to go. Then again, I might be missing the whole point,
> so feel free to correct me in this case.
>
>
As Andreas explained to me yesterday, it is possible to configure "allowed
wildcard paths" at the OpenSSO/policy server , which seems to solve the
issue, as the wildcards will be allowed only under certain level.

Best regards,
Nina

Cheers,
> Luchesar
>
> P.S. To make things clearer, I imagine defining policies for just two
> URIs when you create a resource...
>
> /{type_of_resource}/{id}
> /{type_of_resource}/{id}/*
>
> At the same time, you wouldn't be allowed to create policies for...
>
> /{type_of_resource}/*
> /*
>
> Again, this might be an oversimplification of the problem on my side.
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>