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
>



-- 
Surajit Ray
Partner
www.rareindianart.com