saml proxying scoped attributes...best practice

[Cantor, Scott]

> I'm not entirely sure why I would need insulation between
> internal and external...can you explain?

Policy boundaries (like scoping), and imposing uniformity on a world without much of it, that sort of thing typically. I don't run proxies, so I'm not the best one to ask, but I think in general that passing through identifiers is a relatively less common thing to do at scale, though I'm sure it happens. Some proxies are purely "mechanical" or paper over fundamental software limitations, so are meant to be entirely pass-through.

> My SP trusts the IdP and that IdP trusts the upstream IdP. If
> my SP doesn't trust the upstream IdP (the authenticating
> authority), then it can choose to reject the assertion right?

Not easily, and probably not at all for most implementations, nor do most other proxying IdPs even populate the SAML fields defined for it. Proxying is often something the downstream SPs are ignoring or its hidden from them by design.

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.

> I cannot lookup user information in my authorization system
> if the user identifier is effectively unknown. Its been changed
> to something opaque that’s only known to the IdP.

That hashing isn't something other systems can't do if needed (I'm not saying the results are secret, just indirected), but if you federate a "generic" sort of authorization system so it knows about users from outside organizations, that is....even more rare to say the least. That tends to be the domain of tools like COManage and other systems designed to manage VOs.

Most deployments don't do that, frankly, or if they do, they run them through a proxy that locally assigns an ID to everybody for use in that authz layer. That's my impression anyway.

These issues are why at a lot of campuses, you just don't see any federation inbound, they issue guest accounts or have a social identity gateway (often one that links to locally issued IDs) and just punt on the idea of allowing true federated access. Because it's hard, and authorization is a big chunk of that.

> In my experience, most SPs don’t do just-in-time
> provisioning, so the access has to be provisioned ahead of
> time.

Multi-lateral federation is very commonly handled JIT in fact, precisely because, no matter what kinds of IDs you allow for, you won't know them ahead of time, generally, you'd just be guessing.

There are whole "invitation" flows designed to address that problem of not knowing the ID, I'm sure others are much more familiar with all that than I am.

> Because of this, the SP needs to know how the IdP is going to
> send back the user identifier (and how its formatted).

You will not know that as a general matter because the SAML world just isn't uniform enough for that. Notably the "fix" for that in OpenID,. the sub claim, is generally opaque and unknown to people too, which is why they end up back at email address (or do JIT provisioning and then manage access after).

>  I always thought that this is something that SPs and IdPs
> have to agree on - either between themselves or via a
> federation which 'recommends' that user ids should be
> released via some attribute. 

Yes, in a perfect world, and that's pretty much why federation has failed at scale in a lot of people's eyes, and almost totally non-existent across verticals because no such standardization existed.

We created approaches, usually badly, and the eventual creation of a generic approach in SAML was probably far too late to see much adoption.

> Either way, I need that user id and if its something opaque,
> its meaningless to the SP.

In saying that, you're basically saying OpenID is unworkable other than to carry email addresses as the real ID. That may be true, but I'm just noting that extrapolation.

Your initial perception that this issue is more complex than you think it is is correct.

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.

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.

The subject-id Attribute was created to address all those, and other, limitations. If nothing else, it's a good reference to what problems one will face because it isn't adopted enough.

-- Scott