[OTDev] OpenSSO now secure

chung chvng at mail.ntua.gr
Mon Jun 14 19:11:51 CEST 2010


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? (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.

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.

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? 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.
 ii. Publicly available - Modifications are not allowed.
 ii. Strictly private.
 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).
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.


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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> 





More information about the Development mailing list