[cap-talk] Namespaces, protection, and adminstration

[David Chizmadia (JHU)]

Alan,

    The problem described is the delegation problem described in the
CORBA Security specification and many OMG talks (some by me, some by
those who wrote the CORBAsec spec). The closest that I saw to your
term is "transitive delegation".

    Let me know if you need more specific references,

-DMC

Karp, Alan H wrote:
> I submitted a proposal for a talk to the RSA 2008 Conference.  The
> abstract is limited to 2,500 characters, so it's a bit terse.  Please le
> me know if you have any relevant citations.  In particular, I'd like to
> know if I coined the phrase "transitive access problem" and if others
> have explicitly articulated this problem.  The phrase is a 3-word
> Google-whack (exactly one hit), which is to a slide set from the
> Internet Futures conference that quotes me.
> 
> -------------------------------------------
> 
> 			The Transitive Access Problem for SOA
> 
> A number of Services Oriented Architecture (SOA) projects have failed to
> achieve all their stated goals. A common reason for failure is the
> inability to solve the transitive access problem, which is best
> illustrated with an example. A program run by Alice invokes a service
> run by Bob. In order to satisfy Alice's request, Bob's service invokes a
> service run by Carol. 
> 
> Whose rights get used when Bob's service invokes Carol's? Bob may have
> some rights not granted to Alice, and Alice may have some rights not
> granted to Bob. If Bob's rights are used, he may do something on behalf
> of Alice that Alice is not allowed to do. If Alice's rights are used,
> Bob may take an action that Alice would not approve. 
> 
> Another form of this problem arises when Alice passes a parameter to
> Bob's service, and Bob's service passes the parameter from Alice along
> with a parameter of Bob's to Carol's service. In common cases, a
> conventional access control mechanism based on identity, role, or
> attributes makes it impossible for Carol's service to operate. For
> example, Carol's service could copy a file. If only Alice has permission
> to read the input file, and only Bob has permission to write the output
> file, Carol does not have the rights needed for the requested operation.
> Nor can Carol's service operate by impersonating either Alice or Bob.
> Further, there may be nobody with the authority to change the respective
> access policies to allow Carol's service to work. 
> 
> Transitive access works smoothly with an access control mechanism based
> on explicit authorizations presented with the request. In the second
> example, Alice's program invokes Bob's service with her authorization,
> delegating to Bob a subset of her rights to the argument. Bob's service
> invokes Carol's service using his authorization, delegating to Carol a
> subset of the rights he received from Alice and a subset of his rights
> to the second argument. This approach guarantees that Carol's service
> has the least set of rights from Alice and Bob that it needs to satisfy
> the request. If Bob wishes to use Alice's rights to invoke Carol's
> service, his service interface takes as an argument an authorization to
> use the subset of Alice's rights she is delegating to Bob. 
> 
> We will demonstrate the usefulness of this approach by applying it to a
> problem from the Consolidated Afloat Network and Enterprise Service
> (CANES) program of the US Navy.
> 
> ________________________
> Alan Karp
> Principal Scientist
> Virus Safe Computing Initiative
> Hewlett-Packard Laboratories
> 1501 Page Mill Road
> Palo Alto, CA 94304
> (650) 857-3967, fax (650) 857-7029
> https://ecardfile.com/id/Alan_Karp
> http://www.hpl.hp.com/personal/Alan_Karp
>   
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
>