[OTDev] OpenSSO now secure

Fri Jun 11 10:49:27 CEST 2010

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.

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

-- 
http://www.maunz.de

                         C Programmers do it recursively.