saml proxying scoped attributes...best practice

[Cantor, Scott]

> Our SPs only need to
> communicate with one IdP that we control (and is fairly easy
> to control) without needing to register every SP in a
> federation.

I suppose that's true, but when the biggest reason is "so we don't have to register", I think we've really gone off track as a community. That is not a hard thing to do and shouldn't be driving decisions, particularly when it's devolved to app owners (not every federation supports that, I admit).

> We also don’t need to configure separate IdPs on the SP side
> or ingest absurdly large metadata files on each SP.

Absurdly large metadata ended with MDQ. There really is no "special" configuration for mutliple IdPs in Shibboleth.

If it's ADFS or most other SPs? Sure, they aren't truly capable of federation to begin with, and that's a big driver of proxies of course.

> Doing any of this by having each of our SPs talking to other
> IdPs directly is nearly impossible.

Nothing you mentioned is really that hard at all (for some software), with the exception of the part you were asking about and seem to be dismissing, the lack of uniform attributes and identifiers (and getting them released at all).

That is what makes federation hard, and if you pass the data through, you don't really offload that problem to the proxy.

That was really the point I was trying to get across.

> I'm not sure how often this happens in practice, but if an
> upstream IdP re-uses the same identifier (EPPN) for 2
> different users, I don’t know if I care too much.

Well, I guess I can't really argue that. To me, it's pretty major and disqualifying. I think most people at least lean toward my take on that issue.

> I also don’t care too much about length limits or character
> set. If either of those become an issue, we can simply not
> allow authentication with that IdP anymore.

That's not so casual a decision if actual users are involved by that point.

I was oddly in a discussion about a broken system here at OSU today that ended up broken because somebody handled an absurd length limitation in a database by truncating identifiers.

That is, IMHO, what tends to happen if those kinds of issues aren't addressed head on.

> I think maybe the SAML community is becoming to overly
> concerned with these edge cases and the result is more spec
> changes/requirements that hider interoperability.

I obviously have a very different view of that. System design to me is entirely about edge cases.

I would say that to me you have all this somewhat reversed in terms of the things you're seeing as hard and easy. I don't know if that means it's all hard or all easy, but it's interesting if nothing else.

-- Scott