Hi Nina, all,

the OpenSSO server is readily available at 
http://sens-it-iv.fdm.uni-freiburg.de:8080/opemsso. I can pass the admin 
credentials around.
Currently, we have an attached OpenDS server with sample users (to be 
replaced by the real plone data).

We could craft some policies via the web-based server console (address 
see above) for one or more sample users, new users could also be created 
(in the future there should be a webservice for this).
Then, using the authenticate and authorize services (see the document I 
sent around for a sample workflow), we could indeed solve a first task 
involving A&A.

Greetings
Andreas

Nina Jeliazkova wrote on 03/24/2010 11:13 AM:
> Hi Andreas, All,
>
> I would like to suggest to try to select a specific task to solve (e.g.
> descriptor calculation, model building , validation), involving several
> partner's services and write specific curl commands, solving the task,
> taking into account the proposed AA solution via OpenSSO.
>
> Do you think this is feasible with the current setup you have with OpenSSO ?
>
> Best regards,
> Nina
>
> surajit ray wrote:
>> Hi Andreas,
>>
>> What if we treat lets say an OT Server A as a user on OT Server B (from
>> which Server A might be requesting certain resources). That way we can
>> uniform user based system ... So irrespective of the actual authenticated
>> user , Server A starts a session on Server B using its predetermined
>> username/passwd. Also that way we could easily assign elevated privileges to
>> "Server users".
>>
>> On the downside this would also mean that there will be additional steps and
>> network load when running a distributed task from Server A (for maintaining
>> authenticated tokens and renewing them when necessary)
>>
>> IP/Mac addresses on the other hand would require resetting the AA policies
>> for a server if the IP / hardware changes. Also looking at the future,
>> certain services may be load balanced on several servers. In such a case
>> each of the servers in the load balancing network would require to have
>> their IPs and Macs registered with the OT authentication system.
>>
>> Cheers
>> Surajit
>>
>>
>>
>>
>>
>> On Wed, Mar 24, 2010 at 2:16 PM, Andreas Maunz<andreas at maunz.de>  wrote:
>>
>>
>>> Hi all,
>>>
>>> chung wrote on 03/23/2010 05:11 PM:
>>>
>>>> I think the problem is solved if:
>>>> * A service can call another service providing the username of the user
>>>> that triggered the operation and services recognize each-other by their
>>>> IPs+MAC address+whatever
>>>>
>>> OpenSSO also supports policy conditions based on IP addresses:
>>> http://docs.sun.com/app/docs/doc/820-3885/gipxm?a=view
>>>
>>> Here are some more links, relevant to the discussion we had on monday:
>>>
>>> 1)http://docs.sun.com/app/docs/doc/820-3885/gjeby?a=view
>>>
>>> "When multiple policies are applicable to a particular resource, the
>>> order in which the policies are evaluated is not deterministic."
>>>
>>> This means that positive results - i.e. allows - add up, as long as no
>>> negative results are encountered.
>>> In the latter case, evaluation is stopped immediately and access is denied.
>>> In the former case, the effective outcome policy is the addition of all
>>> the (positive) results.
>>> Access is also denied, if no rule matches.
>>>
>>> "If a policy decision for a requested action is boolean and the request
>>> is determined to be false based on policies evaluated thus far, no
>>> further policies will be evaluated for the requested action. This
>>> behavior can be changed by toggling the Continue Evaluation On Deny
>>> Decision attribute in the Policy Configuration Service."
>>>
>>> Perhaps this can be used to override a rule yielding a negative result
>>> with more specific rules that yield positive results? I will check that.
>>>
>>> 2)https://opensso.dev.java.net/servlets/ReadMsg?listName=users&msgNo=3354
>>>
>>> The wildcard operator stretches by default across all levels, e.g.
>>> http://opentox.org/*  will matchhttp://opentox.org/1  as well as
>>> http://opentox.org/1/2. However, there is a one-level-wildard operator:
>>> -*- that will only match the former.
>>>
>>> 3)http://docs.sun.com/app/docs/doc/820-3885/gipxp?a=view
>>>
>>> This explains how policies are specified using XML and imported using
>>> the ssoadm command line utility (which could be wrapped by a webservice
>>> for use in OpenTox).
>>>
>>> Regards
>>> Andreas
>>>
>>> --
>>> http://www.maunz.de
>>> OpenPGP key:http://www.maunz.de/andreas@maunz.de_pub.asc
>>>
>>> Real programmers don't document. If it was hard to write, it should be
>>> hard to understand.
>>> _______________________________________________
>>> Development mailing list
>>> Development at opentox.org
>>> http://www.opentox.org/mailman/listinfo/development
>>>
>>>
>>
>>
>>
>>
>

-- 
http://www.maunz.de
OpenPGP key: http://www.maunz.de/andreas@maunz.de_pub.asc

    I do know everything, just not all at once. It's a virtual memory 
problem.