[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Expressing (and restricting) delegation
My project has been developing a proposal to implement a basic mechanism with SAML for web SSO with delegation, building on work that's already been done here and elsewhere. You can see some of the stated assumptions and proposals here: https://spaces.internet2.edu/display/ShibuPortal/Home In essence, we're trying to build on simple use of existing profiles like ECP to achieve "bearer" semantics at the eventual relying party site, consistent with the way most sites actually secure themselves today (seeing as browsers don't offer more than cookies), and in support of things like REST, which from a security PoV tend to be more like web sites than what I would think of as a service interface. Note that we're not precluding other protocols being useful to this problem, such as the bearer token delivery defined by Infocard, or something stronger like a holder of key mechanism, signing via OAuth, etc. What I'm interested in discussing and possibly proposing here is actually protocol- and confirmation-agnostic, specifically the actual expression of a chain of intermediaries and the ability to restrict token use normatively using a condition. This could actually be used across protocols as a standard semantic for more advanced assertion use cases, and actually could cross protocols in real time. ID-WSF currently defines a way of expressing a set of intermediaries using an element inside saml:Advice. The problem I'm having with this mechanism, aside from the fact that it's not OASIS-blessed, is that it's advisory. My group has concluded that producing a delegated access solution within Shibboleth is not something to be done without ensuring that existing SAML-protected web sites will not blindly accept SSO assertions that have been issued as a result of delegation, rather than via direct authentication of a user. This question can certainly be debated, but for my purposes, let's just take it as a given that some people feel this way. With the ID-WSF approach, you don't get that property because the chain of intermediaries is expressed only in the SubjectConfirmationData's NameID and in the Advice, neither of which have critical semantics. An SP following the standard SSO profile can be expected to silently accept such an assertion if it meets the other requirements of the profile. Therefore, I would tentatively like to propose that a new Condition type be defined that is essentially an extended version of the SubjectConfirmationData's NameID element today, but with critical semantics for a relying party, as with all conditions. The purpose of this would be twofold: - provide a way of expressing a chain of transited intermediaries that is more extensible than the ID-WSF element (allowing any NameID rather than just entityIDs) and allows for multiple intermediaries rather than the single delegate we defined in the original standard - express the chain via a condition so that relying parties would have to consciously choose to accept the delegation, both in size and in membership (Before anybody suggests using ProxyRestriction, if you read the description it's quite clearly about subsequent propagation of an assertion by the RP, and not about acceptance by the RP.) Thoughts or concerns? I haven't written anything formal up yet but am planning to. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]