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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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