saml proxying scoped attributes...best practice

[Bobby Lawrence]

> Honestly, I don't much see the point of proxying if you expose the SP to all of the details like that. Just run a real SP like Shibboleth's and
> connect it directly to the IdPs it wants to allow, no proxy needed. People proxy because of all the things their SPs can't or don't want to
> handle, and a giant, varied namespace of different identifiers is certainly one of those things.

That’s exactly why we want to use the proxy capabilities of Shibboleth....it simplifies our organization's authentication configuration yet provides flexibility.  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.  Some of our SPs have specific requirements as well which many IdPs would not know how to deal with, but we can handle with the customized configuration that Shibboleth provides (IE: skipEndpointValidation).  We also don’t need to configure separate IdPs on the SP side or ingest absurdly large metadata files on each SP.

This one IdP effectively becomes a gateway to multiple authentication mechanisms, but our SPs only need to speak SAML with this one IdP.  Users get sent to one place where they can choose how they want to authenticate, depending on what kind of credentials they have and what the SP requires.  If the user has credentials at our organization, they can simply input their username/password and the IdP will authenticate against our LDAP server.  The user could even choose to use a smart card or OTP token to authenticate (one of those is a custom authn flow) and might even be required to if the SP requires MFA.  If the user doesn't have credentials for our organization and the SP can accept federated credentials (indicated via metadata), the IdP will proxy the authentication upstream to another SAML IdP or some OIDC relying party.

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

> My general point is that most proxies are not as "transparent" as you're talking about here. That doesn't mean you can't be transparent with it if you want, but 
> you can't ignore all the defaults/expectations that already exist around certain attributes if you choose to use them, like EPPN.

Yea - point taken.  Proxying does make things tricky, especially with VERY specific requirements imposed by the SAML spec.  Luckily I only really care about the stuff I control and as long as our IdP releases the attributes that members of the InCommon federation expect (EPPN, etc) while adhering to the spec, I don’t need to care too much about the others (unless they reach out with specific requirements).

> The main point about EPPNs to understand, fundamentally, is they tend to be name-based and thus prone to changing a lot on your apps, and the attribute did not
> outright preclude reassignment. It also has no limits on lenth, character set, etc.

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.  They are asserting it’s the same user so to our SP, it’s the same.  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.  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.