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