Hi Pantelis,

chung wrote:
> Hi Nina and Andreas,
>
> On Mon, 2010-06-14 at 22:28 +0300, Nina Jeliazkova wrote:
>   
>> chung wrote:
>>     
>>> Dear all,
>>>  I have some questions on OpenSSO and A&A in general:
>>>
>>> A user obtains a tokenId which uses to authenticate itself and acquire
>>> authorization to use a model training service. So my question is:
>>>
>>> 1. How is the possession of the generated model by this particular user
>>> is declared in terms of the OpenTox ontology? Should there be some link
>>> to the user resource in the created model? 
>>>       
>> One can retrieve OpenSSO  policies of a model URI, but we should be
>> aware OpenSSO doesn't have a notion of a model "owner" (neither a
>> "dataset" or any other opentox object "owner").  The first user who
>> succeeds to create a policy of a  model (dataset, etc.) is considered
>> its "owner".  This is the reason we brought the issue of  "atomicity"
>> when creating objects and policies.
>>     
>
> So every resource like models has a policy which in turn has a creator:
> the owner of the resource. 
(it might happen that the policy creator is not the resource creator,
e.g. I can create policy for http://ntua.gr/model/1 before that model exist)
> The owner can render the resource available
> to others. So after all there is some weak sense of ownership.
yes.
>  But
> should there be some link to the resource's policy in the resource
> representation. 
might be useful, but not necessary. 
> For example, if I have a dataset representation in RDF
> format, where can I find the policy assigned to it?
>   
You could query OpenSSO to retrieve the policy for the dataset URI.   We
might of course try to duplicate this information, but if information is
multiplicated, one needs to care about synchronisation.
>   
>>> (The same holds for other
>>> resource that a user is allowed to create such as compounds, features
>>> and datasets). Let me mention that there we have no ontological class
>>> for Users. IMHO there should be a service that returns the username
>>> given the tokenId and require administrative skills.
>>>   
>>>       
>> There are OpenSSO REST interface to retrieve user information, given a token
>>
>> curl -i -X POST -d 'subjectid=your-token-url-encoded'
>> 'http://opensso.in-silico.ch/opensso/identity/attributes'
>>
>>     
>
> Thanks!
>
>   
>>> 2. Which user information are/should be available to the administrators
>>> and service providers? Will the services be able to retrieve the
>>> username that corresponds to a given tokenId? If not, how will be
>>> possible to establish a link to the User that created a resource or
>>> invoked a service.
>>>   
>>>       
>> See the output of the command above.
>>     
>>> 3. Every user should be allowed to make use of a pre-specified fraction
>>> of the server's storage capacity which simply means that there should be
>>> an upper bound on the number of models a user can create (say 50000 or
>>> something like that). How can such a constraint be established using
>>> policies? 
>>>       
>> Quota support is something we had not yet discussed, but it is indeed
>> important. 
>>     
>
> Is there some perspective of accomplishing this kind of authorization
> using SSO or web services should take that on?
>   
This is actually accounting, not authorisation, and we hadn't considered
it at all.   I am slightly in favour of separating accounting from services.

Andreas, what do you think?  Does OpenSSO provide a solution for AAA ?

Best regards,
Nina
>   
>>> If this functionality is not supported then the service itself
>>> has to impose such constraints, which means that for a given token has
>>> to have access to the some more static information about the user (e.g.
>>> its username).
>>>
>>> 4. The (non-privileged) user should have some access to options about
>>> the (public) availability of its data. For example, choose if a dataset
>>> should be:
>>>  i.  Publicly available - Modifications are allowed.  
>>>   
>>>       
>> assign a policy to allow guest user  GET and POST
>>     
>>>  ii. Publicly available - Modifications are not allowed.
>>>   
>>>       
>> assign a policy to allow guest user GET only
>>     
>>>  ii. Strictly private.
>>>   
>>>       
>> assign a policy to allow registered users of certain group(s)  to
>> perform GET and POST
>>     
>>>  iii. Other user are allowed to USE the dataset but not view/modify its 
>>> content (e.g. use it for external validation of their models).
>>>   
>>>       
>> assign a policy to allow registered users of certain group(s)  to
>> perform POST only
>>     
>>> So, this question is about if the end user will be able to generate
>>> policies (?!) which sounds a little bit risky if not a security leak.
>>>
>>>   
>>>       
>> When creating a new resource, no policy exist.   The policy should be
>> created for the new resource, just created by this user.  The policy
>> should be created using either an user token or special server token.
>> There are several issues Luchesar already listed in his email last week.
>>     
>
> Best Regards,
> Pantelis
>
>   
>> Best regards,
>> Nina
>>
>>     
>>> Best regards,
>>> Pantelis.
>>>
>>>
>>>
>>> On Fri, 2010-06-11 at 13:44 +0200, Andreas Maunz wrote:
>>>   
>>>       
>>>> Ok, here is the solution:
>>>> Please use
>>>>
>>>> <Value>cn=partner,ou=groups,dc=opentox,dc=org</Value>
>>>>
>>>> instead of
>>>>
>>>> <Value>uid=partner,ou=groups,dc=opentox,dc=org</Value>
>>>>
>>>> It was wrong in the doc and is now updated.
>>>>
>>>> Best
>>>> Andreas
>>>>
>>>>
>>>> Nina Jeliazkova wrote on 06/11/2010 10:53 AM:
>>>>     
>>>>         
>>>>> Andreas Maunz wrote:
>>>>>       
>>>>>           
>>>>>> I have checked on the server console:
>>>>>>
>>>>>> - the policy has correctly been created
>>>>>> - you are a member of 'partner' group
>>>>>>
>>>>>> So I can see no obvious error here. Could you please make sure to
>>>>>> refresh your token and try again?
>>>>>> If it still fails, I will investigate this more closely.
>>>>>>         
>>>>>>             
>>>>> I've verified with
>>>>> http://opensso.in-silico.ch/opensso/identity/isTokenValid   the token is
>>>>> still valid;  and also obtained a new token , unfortunately
>>>>> authorization still fails.
>>>>>
>>>>> Regards,
>>>>> Nina
>>>>>       
>>>>>           
>>>>>> Andreas
>>>>>>
>>>>>> Nina Jeliazkova wrote on 06/11/2010 10:39 AM:
>>>>>>         
>>>>>>             
>>>>>>> Andreas,
>>>>>>>
>>>>>>> My fault, but I've just replaced the policy to use partner group and
>>>>>>> still not getting authorized.
>>>>>>>
>>>>>>> nina at ambit:~$ curl -i -X GET
>>>>>>> http://opensso.in-silico.ch/Pol/opensso-pol/nina_top_level_test4 -H
>>>>>>> 'subjectid:..'
>>>>>>> HTTP/1.1 200 OK
>>>>>>> Server: nginx/0.6.32
>>>>>>> Date: Fri, 11 Jun 2010 08:31:35 GMT
>>>>>>> Content-Type: text/xml
>>>>>>> Connection: keep-alive
>>>>>>> Content-Length: 1188
>>>>>>>
>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>> <Policies>
>>>>>>>       <Policy name="nina_top_level_test4"
>>>>>>> createdby="id=amadmin,ou=user,dc=opensso,dc=java,dc=net"
>>>>>>> lastmodifiedby="id=amadmin,ou=user,dc=opensso,dc=java,dc=net"
>>>>>>> creationdate="1276245073888" lastmodifieddate="1276245073888"
>>>>>>> referralPolicy="false" active="true">
>>>>>>>           <Rule name="tr1">
>>>>>>>               <ServiceName name="iPlanetAMWebAgentService"/>
>>>>>>>               <ResourceName
>>>>>>> name="http://nina-vpn.acad.bg:8080/sso_protected"/>
>>>>>>>               <AttributeValuePair>
>>>>>>>                   <Attribute name="POST"/>
>>>>>>>                   <Value>allow</Value>
>>>>>>>               </AttributeValuePair>
>>>>>>>               <AttributeValuePair>
>>>>>>>                   <Attribute name="GET"/>
>>>>>>>                   <Value>allow</Value>
>>>>>>>               </AttributeValuePair>
>>>>>>>           </Rule>
>>>>>>>           <Subjects name="s1" description="">
>>>>>>>               <Subject name="test" type="LDAPGroups"
>>>>>>> includeType="inclusive">
>>>>>>>                   <AttributeValuePair>
>>>>>>>                       <Attribute name="Values"/>
>>>>>>>
>>>>>>> <Value>uid=partner,ou=groups,dc=opentox,dc=org</Value>
>>>>>>>                   </AttributeValuePair>
>>>>>>>               </Subject>
>>>>>>>           </Subjects>
>>>>>>>       </Policy>
>>>>>>> </Policies>
>>>>>>>
>>>>>>>     11:31:53 AM: nina at ambit:~$ curl -i -d
>>>>>>> 'uri="http://nina-vpn.acad.bg:8080/sso_protected' -d 'action=POST' -d
>>>>>>> 'subjectid=..' 'http://opensso.in-silico.ch/opensso/identity/authorize'
>>>>>>> HTTP/1.1 200 OK
>>>>>>> Server: nginx/0.6.32
>>>>>>> Date: Fri, 11 Jun 2010 08:31:48 GMT
>>>>>>> Content-Type: text/plain;charset=UTF-8
>>>>>>> Connection: keep-alive
>>>>>>> Content-Length: 14
>>>>>>>
>>>>>>> boolean=false
>>>>>>>
>>>>>>> Regards,
>>>>>>> Nina
>>>>>>> Andreas Maunz wrote:
>>>>>>>           
>>>>>>>               
>>>>>>>> Nina,
>>>>>>>>
>>>>>>>> actually, there is no group called 'opentox'. The groups that
>>>>>>>> currently exist are 'partner' and 'development'.
>>>>>>>> Please check:
>>>>>>>>
>>>>>>>>
>>>>>>>> am at z21:~/aa$ curl -i -d "attributes_names=objecttype" -d
>>>>>>>> "attributes_values_objecttype=group" -d
>>>>>>>> "admin=AQIC5wM2LY4Sfcx8QFIIIagJH2prVX8o5YXh7EtJa024ps8=@AAJTSQACMDE=#"
>>>>>>>> http://opensso.in-silico.ch/opensso/identity/search
>>>>>>>> HTTP/1.1 200 OK
>>>>>>>> Server: nginx/0.6.32
>>>>>>>> Date: Tue, 08 Jun 2010 07:50:30 GMT
>>>>>>>> Content-Type: text/plain;charset=UTF-8
>>>>>>>> Connection: keep-alive
>>>>>>>> Content-Length: 34
>>>>>>>>
>>>>>>>> string=development
>>>>>>>> string=partner
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>>
>>>>>>>> Nina Jeliazkova wrote on 06/11/2010 10:26 AM:
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> Andreas,
>>>>>>>>>
>>>>>>>>> Thanks,  I've created the policy to allow all members of opentox group
>>>>>>>>> to do POST and GET
>>>>>>>>>
>>>>>>>>> curl -i -X GET
>>>>>>>>> http://opensso.in-silico.ch/Pol/opensso-pol/nina_top_level_test4 -H
>>>>>>>>> 'subjectid: ...'
>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>> Server: nginx/0.6.32
>>>>>>>>> Date: Fri, 11 Jun 2010 08:22:15 GMT
>>>>>>>>> Content-Type: text/xml
>>>>>>>>> Connection: keep-alive
>>>>>>>>> Content-Length: 1188
>>>>>>>>>
>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>>>>> <Policies>
>>>>>>>>>        <Policy name="nina_top_level_test4"
>>>>>>>>> createdby="id=amadmin,ou=user,dc=opensso,dc=java,dc=net"
>>>>>>>>> lastmodifiedby="id=amadmin,ou=user,dc=opensso,dc=java,dc=net"
>>>>>>>>> creationdate="1276244370369" lastmodifieddate="1276244370369"
>>>>>>>>> referralPolicy="false" active="true">
>>>>>>>>>            <Rule name="tr1">
>>>>>>>>>                <ServiceName name="iPlanetAMWebAgentService"/>
>>>>>>>>>                <ResourceName
>>>>>>>>> name="http://nina-vpn.acad.bg:8080/sso_protected"/>
>>>>>>>>>                <AttributeValuePair>
>>>>>>>>>                    <Attribute name="POST"/>
>>>>>>>>>                    <Value>allow</Value>
>>>>>>>>>                </AttributeValuePair>
>>>>>>>>>                <AttributeValuePair>
>>>>>>>>>                    <Attribute name="GET"/>
>>>>>>>>>                    <Value>allow</Value>
>>>>>>>>>                </AttributeValuePair>
>>>>>>>>>            </Rule>
>>>>>>>>>            <Subjects name="s1" description="">
>>>>>>>>>                <Subject name="test" type="LDAPGroups"
>>>>>>>>> includeType="inclusive">
>>>>>>>>>                    <AttributeValuePair>
>>>>>>>>>                        <Attribute name="Values"/>
>>>>>>>>>
>>>>>>>>> <Value>uid=opentox,ou=groups,dc=opentox,dc=org</Value>
>>>>>>>>>                    </AttributeValuePair>
>>>>>>>>>                </Subject>
>>>>>>>>>            </Subjects>
>>>>>>>>>        </Policy>
>>>>>>>>> </Policies>
>>>>>>>>>
>>>>>>>>> However, I am not getting authorized (same token used in both curls,
>>>>>>>>> removed here).  And I assume my user is a member of opentox group :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> curl -i -d 'uri="http://nina-vpn.acad.bg:8080/sso_protected' -d
>>>>>>>>> 'action=POST' -d 'subjectid=...'
>>>>>>>>> 'http://opensso.in-silico.ch/opensso/identity/authorize'
>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>> Server: nginx/0.6.32
>>>>>>>>> Date: Fri, 11 Jun 2010 08:21:43 GMT
>>>>>>>>> Content-Type: text/plain;charset=UTF-8
>>>>>>>>> Connection: keep-alive
>>>>>>>>> Content-Length: 14
>>>>>>>>>
>>>>>>>>> boolean=false
>>>>>>>>>
>>>>>>>>> Could you help?
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Nina
>>>>>>>>>
>>>>>>>>> Andreas Maunz wrote:
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> Sorry, it should read:
>>>>>>>>>>
>>>>>>>>>> <Subject name="mygroupname" type="LDAPGroups"
>>>>>>>>>> includeType="inclusive">
>>>>>>>>>>      <AttributeValuePair>
>>>>>>>>>>        <Attribute name="Values"/>
>>>>>>>>>>        <Value>uid=mygroup,ou=groups,dc=opentox,dc=org</Value>
>>>>>>>>>>      </AttributeValuePair>
>>>>>>>>>> </Subject>
>>>>>>>>>>
>>>>>>>>>> instead.
>>>>>>>>>>
>>>>>>>>>> A.M.
>>>>>>>>>>
>>>>>>>>>> Andreas Maunz wrote on 06/11/2010 10:09 AM:
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>>> Hi Nina,
>>>>>>>>>>>
>>>>>>>>>>> you would create a policy that contains:
>>>>>>>>>>>
>>>>>>>>>>> <Subject name="mygroupname" type="LDAPUsers"
>>>>>>>>>>> includeType="inclusive">
>>>>>>>>>>> <AttributeValuePair>
>>>>>>>>>>> <Attribute name="Values"/>
>>>>>>>>>>> <Value>uid=mygroup,ou=groups,dc=opentox,dc=org</Value>
>>>>>>>>>>> </AttributeValuePair>
>>>>>>>>>>>
>>>>>>>>>>> Mind the "ou=groups" instead of "ou=people". Then, create the group
>>>>>>>>>>> "mygroup" and assign users to it (contact Micha for that).
>>>>>>>>>>>
>>>>>>>>>>> Best regards
>>>>>>>>>>> Andreas
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nina Jeliazkova wrote on 06/11/2010 08:53 AM:
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>>>> Hi Andreas,
>>>>>>>>>>>>
>>>>>>>>>>>> Could you tell how to create a policy, that allows group of
>>>>>>>>>>>> users to
>>>>>>>>>>>> POST or GET ? This would be applicable to almost all top level
>>>>>>>>>>>> resources like /algorithm/{id} , etc.
>>>>>>>>>>>>
>>>>>>>>>>>> Following the example at p.12 of the deliverable D3.3. , one could
>>>>>>>>>>>> create a policy which is per user only.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Nina
>>>>>>>>>>>>
>>>>>>>>>>>> Andreas Maunz wrote:
>>>>>>>>>>>>                     
>>>>>>>>>>>>                         
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> connections to the OpenSSO service at opensso.in-silico.ch can
>>>>>>>>>>>>> now be
>>>>>>>>>>>>> made secure by using SSL.
>>>>>>>>>>>>> Submit your user credentials safely and obtain a token:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ****************************************************************
>>>>>>>>>>>>> am at z21:~/aa$ curl -v -k -i -d "username=amaunz&password=secret"
>>>>>>>>>>>>> https://opensso.in-silico.ch/opensso/identity/authenticate?uri=service=openldap
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * About to connect() to opensso.in-silico.ch port 443 (#0)
>>>>>>>>>>>>> * Trying 178.63.18.76... connected
>>>>>>>>>>>>> * Connected to opensso.in-silico.ch (178.63.18.76) port 443 (#0)
>>>>>>>>>>>>> * successfully set certificate verify locations:
>>>>>>>>>>>>> * CAfile: none
>>>>>>>>>>>>> CApath: /etc/ssl/certs
>>>>>>>>>>>>> * SSLv3, TLS handshake, Client hello (1):
>>>>>>>>>>>>> * SSLv3, TLS handshake, Server hello (2):
>>>>>>>>>>>>> * SSLv3, TLS handshake, CERT (11):
>>>>>>>>>>>>> * SSLv3, TLS handshake, Server finished (14):
>>>>>>>>>>>>> * SSLv3, TLS handshake, Client key exchange (16):
>>>>>>>>>>>>> * SSLv3, TLS change cipher, Client hello (1):
>>>>>>>>>>>>> * SSLv3, TLS handshake, Finished (20):
>>>>>>>>>>>>> * SSLv3, TLS change cipher, Client hello (1):
>>>>>>>>>>>>> * SSLv3, TLS handshake, Finished (20):
>>>>>>>>>>>>> * SSL connection using AES256-SHA
>>>>>>>>>>>>> * Server certificate:
>>>>>>>>>>>>> * subject: C=CH; ST=Some-State; L=Basel; O=in silico toxicology;
>>>>>>>>>>>>> CN=Christoph Helma; emailAddress=helma at in-silico.ch
>>>>>>>>>>>>> * start date: 2010-06-09 16:38:59 GMT
>>>>>>>>>>>>> * expire date: 2020-06-06 16:38:59 GMT
>>>>>>>>>>>>> * common name: Christoph Helma (does not match
>>>>>>>>>>>>> 'opensso.in-silico.ch')
>>>>>>>>>>>>> * issuer: C=CH; ST=Some-State; L=Basel; O=in silico toxicology;
>>>>>>>>>>>>> CN=Christoph Helma; emailAddress=helma at in-silico.ch
>>>>>>>>>>>>> * SSL certificate verify result: self signed certificate (18),
>>>>>>>>>>>>> continuing anyway.
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>>>>>>>>>>>>> POST /opensso/identity/authenticate?uri=service=openldap HTTP/1.1
>>>>>>>>>>>>>> User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7
>>>>>>>>>>>>>> OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
>>>>>>>>>>>>>> Host: opensso.in-silico.ch
>>>>>>>>>>>>>> Accept: */*
>>>>>>>>>>>>>> Content-Length: 32
>>>>>>>>>>>>>> Content-Type: application/x-www-form-urlencoded
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                         
>>>>>>>>>>>>>>                             
>>>>>>>>>>>>> <    HTTP/1.1 200 OK
>>>>>>>>>>>>> HTTP/1.1 200 OK
>>>>>>>>>>>>> <    Server: nginx/0.6.32
>>>>>>>>>>>>> Server: nginx/0.6.32
>>>>>>>>>>>>> <    Date: Thu, 10 Jun 2010 08:12:27 GMT
>>>>>>>>>>>>> Date: Thu, 10 Jun 2010 08:12:27 GMT
>>>>>>>>>>>>> <    Content-Type: text/plain;charset=UTF-8
>>>>>>>>>>>>> Content-Type: text/plain;charset=UTF-8
>>>>>>>>>>>>> <    Connection: keep-alive
>>>>>>>>>>>>> Connection: keep-alive
>>>>>>>>>>>>> <    Content-Length: 72
>>>>>>>>>>>>> Content-Length: 72
>>>>>>>>>>>>>
>>>>>>>>>>>>> <
>>>>>>>>>>>>> token.id=AQIC5wM2LY4SfcyyY3V7C7qD1FD2ZoktJHsYKEKE8g+wXys=@AAJTSQACMDE=#
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Connection #0 to host opensso.in-silico.ch left intact
>>>>>>>>>>>>> * Closing connection #0
>>>>>>>>>>>>> * SSLv3, TLS alert, Client hello (1):
>>>>>>>>>>>>> ****************************************************************
>>>>>>>>>>>>>
>>>>>>>>>>>>> As you can see, a special switch (-k) is still required to allow
>>>>>>>>>>>>> connections using the self-signed certificate from Christoph. We
>>>>>>>>>>>>> might
>>>>>>>>>>>>> improve on this by using a free certificate from startssl.com,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> clients trust.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Moreover, connections without SSL still work as usual.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Greetings
>>>>>>>>>>>>> Andreas
>>>>>>>>>>>>>
>>>>>>>>>>>>>                       
>>>>>>>>>>>>>                           
>>> _______________________________________________
>>> 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
>>
>>     
>
>