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 match http://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
>>
>>     
>
>
>
>