[OTDev] OpenSSO now secure

Fri Jun 11 10:53:54 CEST 2010

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