Shibboleth Developers

["Tom Scavo" <>]

On 6/20/06, Scott Cantor 
<>
 wrote:
> http://www.oasis-open.org/committees/download.php/18811
>
> See PE26, which cleans up a lot of the Response processing rules for SSO and
> makes it very clear what the TC's intent was.

Argh!

> I wasn't ever very happy that we allowed multiple assertions because IMHO
> nothing was gained. With only one issuer, the only rational thing to do when
> including attributes now is just embed them in one, and we could have saved
> everybody headaches by restricting the profile to one assertion. But I lost,
> so all I can say is the errata at least tries to clarify things a bit.

Well, I suppose IdPA can extract the AttributeStatement from the
assertion received from IdPB and insert that into the attribute
assertion it issues to the SP, along with an AttributeStatement of its
own.  Seems the two sets of attributes need to be even more separate
than that, though, so the SP can apply policy appropriately.  If we
assume the SP has trust relationships with both IdPA and IdPB (again,
not unreasonable, I think), shouldn't we make a distinction between
the two attribute sets so that the SP can filter attributes
separately?

I suppose a workaround is to let the SP query IdPB for attributes on
the back channel, after receiving the authn assertion and attribute
assertion from IdPA on the front channel, but there's no support for
this in the SP now so it's not an option at this time.

I think the best approach for us now (SAML 1.1) is to pass multiple
assertions from IdPA to the SP, even though it goes against SAML 2.0
down the road.  It's the only approach that has a hope of being
implemented giving current technology.

Tom