Shibboleth Developers

["Scott Cantor" <>]

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

That's exactly the point. The profile doesn't support multiple issuers so
that relying parties are not obligated to think about the issue. Also,
filtering as defined by Shibboleth SPs is not a SAML thing, it's a "Scott
made it up" thing. But people intutively get that it means something to
accept claims from a third party, so sticking with one third party was a
simplification.

You can back-door it, just stick an assertion inside an attribute. But that
forces you to handle it as an attribute processing issue, which is out of
scope of the profile, so nobody's mistaking it for an interoperable feature.

Finally, again, proxying (the thing I was talking about) is precisely for
the case where there is no trust between the SP and the IdP at the end.
Otherwise, it's more along the lines of this out of scope use case you're
talking about.

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

You have a bigger problem, which is federating an identifier between the two
IdPs so that any query can happen. That's why I think WSF is just better for
this...you don't worry about that at the SP/WSC, you just ask the
authenticating IdP for a token to go talk to that other service, and it
figures out how to embed the identifier you might need for that instead of
having to give you something up front on the off chance you need it.

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

Note that I suspect in Shibboleth now, even if it failed to block the
multiple issers (I think 1.3 does, not sure), the AAP step only in terms of
the one IdP, so the filtering would be inaccurate anyway. Again, precisely
because that use case was pushed out of scope.

-- Scott