Shibboleth Developers

["Tom Scavo" <>]

On 6/19/06, Scott Cantor 
<>
 wrote:
> > Okay, now I'm confused. :-)  Remember that conversation we had about
> > "masquerading SPs" last month?  The idea is that the proxy will
> > impersonate the SP, obtain assertion(s) targeted at the SP, and return
> > them to the SP unscathed.
>
> Right. That's not proxying because the IdP at the end can't tell the
> difference.

Sorry, I didn't explain our use case very well.  IdPA *does* issue its
own authn assertion (as described in section 3.4.1.5 of SAMLCore) but
it also passes through an attribute assertion issued by IdPB.  Thus
the response issued by IdPA contains three assertions:  an authn
assertion issued by IdPA, an attribute assertion issued by IdPA, and
another attribute assertion issued by IdPB.

> I suppose you can honor various aspects of proxying conditions,
> but you don't have to use the proxying processing rules.

Yes, I think the rules in section 3.4.1.5 apply in this case.

> Proxying is normally used when the relying party can't trust the signature
> of the eventual IdP

We assume that it does, so that the attribute assertion issued by IdPB
can be consumed by the SP.  Otherwise IdPA needs to consume and
regurgitate the attributes from IdPB, and we'd rather not get into
that.

> or when the IdP doesn't support SAML. You can proxy
> things like Passport and reflect that somehow in a deployment.

I would call this a SAML gateway (SAML in, non-SAML out) as opposed to
a SAML proxy (SAML in, SAML out).  Section 3.4.1.5 clearly refers to
both types of entities.

Tom