saml proxying scoped attributes...best practice

[Cantor, Scott]

> For the most part, it seems like the InCommon community
> has “standardized” on using eduPersonPrincipalName as the
> user identifier but I’m not entirely sure how to handle this in
> a proxy scenario.

EPPN is pretty unstable in practice a lot of the time. It's ubiquitious, but so is email address, and neither are good identifiers in practice because they usually have to match for life not to be painful for the IdP.

The well-defined choices (subject-id, pairwise-id) are poorly supported. That's just how it is, I'm not sure it will ever change in the SAML world, we screwed up to start with and waited too long to produce a workable answer.

> So I guess my question is this…how should I be handling
> EPPN that comes back from the upstream IdP?

To start with, you have to control all the SPs or they're going to reject a passthrough scoped value anyway (if using Shibboleth). You aren't authorized to assert all those scopes unless you specifically get them to accept metadata about your IdP saying so, or turn off the check. And you'd have to maintain that list of scopes in your metadata.

So I assume for practical purposes you do control that issue somehow.

> I’d like to send it downstream unmolested to the SP, which
> means I’d actually like to NOT apply the IdP scope, but I DO
> want to apply that scope for the non-proxying scenarios like
> when I build it via the password principal. 

I imagine the problem is you're producing the non-proxied one based on the principal name, which is there in proxied cases also (via EPPN, sounds like), so you need to ensure it's not produced in the proxy case.

Probably the most understandable way to do this would be to use a Script to build EPPN, and have it run against the Subject DataConnector as a dependency supplying the proxied EPPN (which you could apply a custom ID to via decoding so it's "separate").

The script could then detect if that separate ID were fed in and pass it along into EPPN, or build it the way it would normally get built.

> Should I transcode the upstream EPPN into a different
> attribute so that its not scoped?

No, but decoding into a different name lets you isolate it when you feed it into a Scripted attribute definition so you can see if it's there or not and use that as the "was proxying done?" signal.

But honestly proxying is a boundary that's usually meant to map all those external IDs into something produced at the proxy as a façade, or get mapped in to some linked identifier managed in an IDM system.

I would say that's a lot more common since this sort of proxy really tends to be in service of a group of SPs and needs to meet their expectations. Trying to demand they all understand all those external identifiers, you could just as well federate the SPs directly.

When you talk about best practice....proxies to me are always about avoiding any need for standards of any sort. They hide the complex world from the apps so they can act like things are simple. But there are different sorts of proxies obviously.

-- Scott