[services-wg] [cfwg] a proposal for slice stitching

Jeff Chase chase at cs.duke.edu
Sun Feb 28 17:03:40 EST 2010


Max Ott wrote:
> On 25/02/2010, at 8:16 AM, Jeff Chase wrote:
>
>   
>> Trust is anchored 
>> in identity providers outside of ORCA, and each actor controls its own 
>> policies regarding what powers to give to identities endorsed by those 
>> providers.
>>     
>
> What is trust really used here? Is it trusting that some 'message' comes from whoever they claim they are? Trust, that the entity I delegated some authority, too, did the right thing? 
>   
By "trust is anchored in identity providers external to ORCA", I was 
just referring to identity providers as external authorities to 
authenticate users and other identities, and assert the attributes of 
those identities for use by an authorization policy.  That statement was 
a little bit glib: the local operator for each ORCA server is empowered 
to define trust relationships to other actors and IdPs, e.g., what 
clearinghouse to advertise your resources to, what identity providers to 
accept user sessions from, etc.

Authorization policies can then be formulated using those attributes.  
For example "this principal is the PI on project XXX" can be an identity 
attribute asserted by an identity provider, and an authorization policy 
can use that information.   This is basically the nub of Shibboleth.
> In our world, for an entity to act on a request it needs to carry the right authorisation. An authorisation is normally a chain of authorisations which ultimately needs to lead back to the receiver (or the one acting on the request). A request comes from user A which is authorised by PI B which is authorised by organisation C which I have an agreement with. Something, like a Policy Decision Point, then needs to traverse that and ensure that they are not only authentic, but also conform to the associated policies.
>   
Right.  I think we are all in agreement about that.  For GENI, the broad 
outlines of authorization policy based on chained delegations goes back 
to ideas hammered out by Mike Reiter and Steve Schwab and others back in 
the last round of the process, pre-BBN (2005-2006).   It is also present 
in SHARP (an SOSP 2003 paper) with respect to resource control, and 
SHARP is a predecessor of ORCA.  SFA suggests one instantiation of 
chained delegation mechanisms as a basis for authorization policy.   I 
think there is still some groping around for consensus on a general set 
of mechanisms (and running code) for specifying and processing these 
delegations in a way that is fully disentangled from policy. There have 
been some discussions about that off on the side, involving Rob Ricci 
and Steve Schwab and some Shibboleth folks and Aaron, and that probably 
should be summarized on this list.

I would certainly like to hear more about the chaining/delegation 
mechanisms in OMF.
> I fully agree with Jeff that in a truly federated world there is no place in the architecture for a central authority. Certain deployments may delegate all decisions to a single entity, but that's a deployment decision and not one dictated by architecture.
>   
Thanks.  Just for the record, I feel sure that Rob and the SFA designers 
would agree with that too, and I didn't intend to suggest otherwise. 

Jeff





More information about the services-wg mailing list