Shibboleth Developers

["Scott Cantor" <>]

> 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.

Check line 544 of profiles. Each assertion during SSO is from the same
issuer. That was intentional. You can't sneak in the multiple authority use
case. When you mentioned all this, I assumed you were just talking about
reissuing the attributes.

Of course, would it work in a lot of products? Probably, but it's still
against the rules.

Note that the language isn't as clear as it probably should be, but when it
says "the issuing IdP" it's intended to refer back to the IdP acting in the
profile, and there's only one. I will bring that up as a possible errata.

> 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.

Sorry. See above. The multiple authority use case was out of scope at the
time.

> > 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.

Be that as it may, the proxying stuff came from ID-FF, and that was one of
the use cases. The assumption was that non-SAML IdPs would have a
pseudo-providerId assigned as needed. The technical definition of proxying
here is just that some other domain was actually responsible for the user's
authentication, not the IdP issuing the SAML assertion.

-- Scott