[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]