Dear Nina, All,
  Thanks for pointing out to issue of A/A.

On Wed, 2009-09-30 at 11:30 +0300, Nina Jeliazkova wrote:
> 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.
> 

I think an easy way to overcome this complexity is the following: The
user posts a request to a service S0 and provides proper credentials
(e.g. username+password) to the authentication of that service. The the
service S1 performs some requests to the services S1, S3, ..., Sk. Each
one of them recognizes that the request comes from S0 and does not ask
for credentials. Schematically, we then have the following structure:

S[0]
|
|----> S[1] (IP authentication of S[0] )
|----> S[2] 
|
.
.
.
|----> S[k]
        |
        |
        |--> S[k+1] (IP auth. of S[k])


Each server S[i] should authenticate all other services S[j]. 

However, some user may want to use the service S[i] directly. This is
the case of a user that needs to calculate a single molecular descriptor
for a single compound. Then we have to establish common client
credentials for all services. For example if a user is given credentials
for the whole OpenTox service (set of services), every service should
authenticate that user with the same credentials. 

Now suppose that a service S[i] offers access to a database where
"highly confidential" data are stored so not every user should be
allowed to use the service. What is more if all users where allowed to
delete models then some very fine and accurate models could be deleted.
These are cases that authorization should be taken into account. So, I
propose to consider of three levels of authorization:

* Simple Users
* Privileged Users 
* Administrators

As far as the authentication schema is concerned, I think that for the
time we should restrict ourselves to something simple (like HTTP Basic,
or HTTP Digest).

> 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