Actually, unless the AA system is integrated into the OT services, I
don't see how you could avoid asking the AA server about _each_
resource. It doesn't make sense to request the list of resources to
which user "Bob" has access from the AA server just for a _specific_
OT service. And it also doesn't make sense to request the full list of
resources to which user "Bob" has access, when the service in question
actually holds only part of them.

And if there's a bottleneck concerning the number of resources to be
checked, that bottleneck would affect the AA server anyway: whether
you ask it resource by resource, or you request from it to process its
complete policy database.

Actually, a compromise that I see is to be able to ask not for single
resource/URI but for a list of resources/URIs -- with specific
token/user -- and then get in response only those URIs to which the
user has specific access (most likely GET, in certain cases probably
also POST). However, I'm not quite sure whether OpenSSO is able to do
this.

L.


On Fri, Jun 18, 2010 at 15:07, Nina Jeliazkova <nina at acad.bg> wrote:
> chung wrote:
>> Hi Nina, All,
>>
>> On Fri, 2010-06-18 at 13:42 +0300, Nina Jeliazkova wrote:
>>
>>> Hi Pantelis, All,
>>>
>>> chung wrote:
>>>
>>>> Hello Nina,
>>>>   I think it would be both more efficient for the server (because it
>>>> would provide shorter representations) and for the client (to be able to
>>>> view only the resources to which it has access) if the services return
>>>> only a URI list of resources at which the client has access. Otherwise
>>>> the services would have to return very long lists of URIs or even RDF
>>>> documents.
>>>>
>>>>
>>> IMHO this is better handled by adopting a search functionality -
>>> e.g.retrieve only objects which comply to certain criteria (user or
>>> group ownership) and should be independent of AA.
>>> I am kind of reluctant to the idea of duplicating resource - users
>>> relationships in services, for the obvious reason one can issue OpenSSO
>>> call to change this relationship, without ever informing the service.
>>> Then the service will have outdated information, which will be difficult
>>> to synchronize.
>>>
>>
>> Well, this is why the services should not store user-related information
>> hence there is no way to provide such lookup services. How can the
>> service tell which are the models owned by 'Nina' if there is no Nina in
>> the Database of the service?
>>
>>
> Would be good if Andreas can find a way to perform such queries via
> OpenSSO.
>
> Another idea is to have separate service(s) for storing users' favorites
> / bookmarks  - this could establish user- resource relationships without
> pretending these to be "ownership"-like.
>
> Something like del.icio.us for models, algorithms, compounds , datasets,
> etc.    In principle, the Ontology service can be used for this as well,
> if we introduce such "bookmark" property in opentox.owl
>>> >From OpenSSO side , I am afraid there is no easy way to retrieve list of
>>> objects of particular type that "belongs" to particular user - Andreas
>>> am I right?
>>>
>>>>   However if we decide to return the complete list I think it would be
>>>> good practice if clients requested only URI lists and not RDFs for the
>>>> sake of shorter representations. Recall that RDF representations contain
>>>> all information about the underlying resources, for example if you ask
>>>> for an RDF/XML representation of all model you can see every model's
>>>> independent and dependent variables etc.
>>>>
>>>>
>>> It will be valid to have subset of RDF representation, e.g. when
>>> retrieving datasets , only metadata is retrieved, not all compounds and
>>> properties. Same could be done for models.
>>>
>>>
>>
>> Is there any kind of information in the representation of a model which
>> should be hidden/protected? I think the model representations as they
>> are now do not have anything about the model itself such as its
>> equation, coefficients etc...
>>
> No, but you have this in PMML / TEXT representation .  I would say the
> current model API is a bit inconsistent, since RDF is actually a
> metadata of the model, not the model itself.
> It might be reasonable to introduce additional URIs to retrieve model
> content, where applicable, e.g.  /model/1 retrieves metadata, but
> /model/1/content retrieves the model itself.
>
> Best regards,
> Nina
>>
>>> Even if model variables are retrieved, these are only links, not their
>>> representation.
>>>
>>> Regards,
>>> Nina
>>>
>>>> Best regards,
>>>> Pantelis
>>>>
>>>>
>>>> --------------------------------------------------
>>>>
>>>> New Book: Teach yourself C in 45 years, Volume I.
>>>> Special offers for life prisoners ;)
>>>>
>>>>
>>>> On Fri, 2010-06-18 at 12:36 +0300, Nina Jeliazkova wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> Good question.  The easiest workaround would be to return URIs of all
>>>>> resources, regardless of the ownership/policy - if the user wants to
>>>>> retrieve representation of the  particular resource, then the
>>>>> authorisation applies.  This will not break protection of confidential
>>>>> resources, since the client will get only links, not resources
>>>>> themselves.  And this is how typical web page works as well - you can
>>>>> see the links, but accessing the links might require AA.
>>>>>
>>>>> In fact, retrieving list of resources should rely on the policy for the
>>>>> top level resource (e.g. /model )  , which might have GET allowed for
>>>>> everybody.
>>>>>
>>>>> Best regards,
>>>>> Nina
>>>>>
>>>>> chung wrote:
>>>>>
>>>>>
>>>>>> Hi All,
>>>>>>   If a user needs a list of all models or datasets (either a URI list or
>>>>>> an RDF document) is the service supposed to return only his resources
>>>>>> neglecting all other or list all resources to which the user has access?
>>>>>>
>>>>>>  In the first case I guess some identifier for the user has to be saved
>>>>>> in the database (e.g. bob at opentox.org). Checking all resources in the
>>>>>> database for authorization one by one I think is out of the question for
>>>>>> this would be a bottleneck. Maybe it is worth think about how can the
>>>>>> client obtain a list of all resources it can access which of course
>>>>>> might have been created by other users.
>>>>>>
>>>>>> Best regards,
>>>>>> Pantelis
>>>>>>
>>>>>> _______________________________________________
>>>>>> Development mailing list
>>>>>> Development at opentox.org
>>>>>> http://www.opentox.org/mailman/listinfo/development
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Development mailing list
>>>>> Development at opentox.org
>>>>> http://www.opentox.org/mailman/listinfo/development
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Development mailing list
>>>> Development at opentox.org
>>>> http://www.opentox.org/mailman/listinfo/development
>>>>
>>>>
>>> _______________________________________________
>>> Development mailing list
>>> Development at opentox.org
>>> http://www.opentox.org/mailman/listinfo/development
>>>
>>>
>>
>>
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>