OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services-comment] Questions about SAML V2.0 Condition for Delegation Restriction Version 1.0


Jeff.Krug@gtri.gatech.edu wrote on 2009-03-30:
> I am concerned that the spec as written does not provide enough
information
> on how it would be composed.  Would it be possible to include some
scenarios
> that explain how it could be used and demonstrate what the conditions
would
> actually look like for those scenarios.

I'm willing to write some non-normative text once discussion shakes out.
 
> I have three scenarios that are rather vague, but I am trying to
> understand this at a very high level.  Would all (or any) of these
> scenarios be legitimate:

I think your use cases are distinct, with some overlap, but the use cases I
had in mind involve the IdP brokering exchanges, not forwarding an assertion
around.

> Scenario 1: An IDP issues an assertion to an SP.  The SP adds itself as a
> Delegate to this assertion and then forwards it onto a RP (strips off the
> IDP's signature and adds its own signature).  The RP then makes a decision
> based on the Delegate/IDP/Assertion Content/Signature.

That is what SAML 2 would refer to generally as "proxying", where an SP
becomes an IdP (or at least an issuer). There are already constructs in SAML
for controlling that, and for identifying the "authenticating authorities"
that are in the chain. The latter is admittedly optional to process, but I
don't think I would really like to see these use cases combined, as there's
a distinct difference.

> Scenario 2: An IDP issues an assertion to an SP that includes a list of
all
> Delegates the IDP trusts (including that SP itself).  The SP then fowards
> this assertion to another RP (the SP does not alter the original assertion
> in any way).  The RP then makes a deicsion based on all the
> Delegates/IDP/Assertion Content/Signature?  Was this RP also in the
delegate
> list (would it need to be)?

It is possible to represent the forwarding process in such a way that this
condition could come into play, but not without additional machinery. The
assertion would have to carry a suitable SubjectConfirmation and Audience
condition to enable the SP to use it someplace else, and in that case, the
condition could be used to identify the SP as a delegate of the user. But
you couldn't do that with multiple SPs at the same time in the same
assertion because the condition with the list isn't tied to the particular
SubjectConfirmation to satisfy.

A more proper way to do this would be to define new extended
SubjectConfirmation types that would carry the full delegation chain (much
like the current schema permits one entry). Then each individual
confirmation element for the different intermediates would carry the
appropriate chain for that use.

> Scenario 3: An IDP issues an assertion to an SP that includes a list of
all
> Delegates the IDP trusts (this list does not include that SP).  The SP
will
> not forward this assertion, since he is not a delegate.

The ability to act as a delegate is a function not of the condition, but of
the subject confirmation(s) included. The list of delegates in the condition
is just to inform the RP of the actors that go beyond just the immediate one
satisfying a confirmation.
 
> I realize this spec is just explaining how to represent Delegates and not
> defining how they are used, but without some sort of scenarios or
examples,
> it feels inadequate.  Is a Delegate an issuer of assertions?

No, it's a user/wielder of them.

> Would Delegates need to appear uniquely within the SAML 2 Entity Metadata
for a
> federation.  If they do, is there a need for a new role descriptor type?

No, any more than users today appear in metadata. Most of them will be SPs
themselves and probably will be in the metadata, but the basis of trust by a
RP of such an assertion (if it were holder of key at all) would be the
subject confirmation and its trust in the issuer, not by knowing the
delegate's key ahead of time.

Thanks,
-- Scott




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]