[OTDev] Authentication and authorisation for OpenTox REST services

Nina Jeliazkova nina at acad.bg
Wed Sep 30 17:07:41 CEST 2009


Hi Christoph, All,

Christoph Helma wrote:
> Hi all,
>
> Some more requirements: In the long term we might want to share data
> between users and groups (as in CCD http://www.collaborativedrug.com/),
> but to protect them from the outside.
>
> This would need 
> 	- user and group permissions (read/write)
> 	- permission inheritance
> 		Example use case:
> 			- a user creates a new dataset with restricted permissions
> 	  	- another user creates features from this dataset 
> 	  	- the feature dataset should have the same permissions as the
> 	  	  original dataset
> 			- another user creates a prediction model from this dataset
> 			- the prediction model should have the same permissions as the
> 	  	  original dataset
> 			- the dataset owner decides to make the dataset public
> 			- all derived datasets/models should become public
>   
I agree this is a realistic use case. Do you have suggestions how to
RESTify this use case (users, groups, ownership, permissions) ? 
> Best regards,
> Christoph
>
> PS Do you have the impression that FOAF+SSL is ready for production
> systems?
>   
FOAF+SSL is indeed appealing, but very very new. I have seen some Java
code claiming to support it, but prefer not to judge before really
trying how it works.  May be we could design a feasibility study with
Java from our side and  Andreas taking care of Ruby integration.

Best regards,
Nina
> Excerpts from Nina Jeliazkova's message of Wed Sep 30 10:30:48 +0200 2009:
>   
>> Hello All,
>>
>> I would like to start a discussion on possible requirements and
>> solutions for OpenTox REST services.  The main point here is we have
>> distributed services, developed by different partners, but expected to
>> work together.
>>
>> A typical use case would be a dataset to be provided by service S1,
>> descriptors calculated by Service S2 , model prediction by service S3
>> and validation by service S4.  Any of the services might request
>> authentication of the client. In case of independent AA implementations
>> for each partner service, the client will be asked 4 times (in worst
>> case) to enter his credentials, specific for each of the four services.
>>
>> Current status :
>>
>>     * Own (minimal) implementation of AA for some services (NTUA, IDEA
>>       –HTTP Basic for dataset POST, others?)
>>
>> Options:
>>
>>     * Centralized service providing Identity
>>     * Federated AA
>>
>> Technologies to consider (the list is not complete!) :
>>
>>     * HTTP Basic + SSL
>>     * HTTP Digest
>>     * OpenID
>>     * OpenAuth
>>     * Google OAuth & Federated Login  
>>       http://sites.google.com/site/oauthgoog
>>       <http://sites.google.com/site/oauthgoog/Overlap>
>>     * FOAF + SSL (pretty new)  http://esw.w3.org/topic/foaf+ssl
>>     * SAML
>>
>> Best regards,
>> Nina
>>
>>     
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>   




More information about the Development mailing list