« Return to Thread: a proposal for slice stitching
Re: [cfwg] a proposal for slice stitching
by Jeff Chase
::
Rate this Message:
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
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
> 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?
>
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
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
« Return to Thread: a proposal for slice stitching
| Free embeddable forum powered by Nabble | Forum Help |
