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: Re: [security-services] IDP Proxying & Distributed Authentication

On 6/8/07, Scott Cantor <cantor.2@osu.edu> wrote:
> Paul Madsen wrote:
> > Separately but related, existing Authn Context mechs in the
> > AuthnStatement appear limited in being able to describe 'who did what'
> > in such a distributed authentication case. There can be multiple
> > <AuthenticatingAuthority> elements, but all within a single
> > <AuthnContext>. The implication is that the proxying IDP would need to
> > create a single AuthnContext to reflect how the authentications were
> > distributed (even while acknowledging that the first IDP was involved in
> > some manner.)
> True, though I could imagine many ways of passing information along,
> probably in Advice, to provide additional context.

I agree, this is what we do, and it works well.  By nesting an
assertion in Advice, an IdP implicitly asserts: 1) I am an IdP Proxy,
2) I trust the IdP indicated in the nested assertion, and 3) I have
validated the response that previously contained the nested assertion.
 The relying party trusts the IdP Proxy to do all that and simply
consumes the assertion, or if it has a trust relationship with the
original IdP, it validates the assertion before consuming it.
Presumably the nested assertion is signed so that the relying party
can verify the signature if it so chooses.

This technique has the nice theoretical property that the level of
nesting corresponds to the ProxyCount.  A relying party can tell at a
glance how far removed the assertion is.


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