saml proxying scoped attributes...best practice

[Cantor, Scott]

> So this is one of the things I never quite understood
> regarding hashed/opaque identifiers. I understand its value
> with respect to preserving privacy

Privacy is not the point here. Hashing is a simple way to use a stable input from outside and turn it into a stable output you can govern (using your own scope for example) without creating a stateful database.

An alternative is to build full on stateful identity linking in a database/IDM system.

Passing through values is a degenerate form of the stateless model, but with no insulation between internal and external.

> but most of my SPs need to lookup a database record of a
> valid user to determine authorization roles/rules. How am I
> to correlate the identifier to a database record if its hashed?

The same way they would with any other identifier. The downside is when you have to provision access ahead of time, i.e. knowing what the identifier is going to be. Then hashing is a bad approach. But that's the same reason pairwise approaches tend to work badly, so it's not a novel problem with proxies either.

To some extent, all federated systems have that problem of not knowing how to determine someone's identifier ahead of time, without the benefit of a total view of the "universe" that an identity registry provides.

It's not generally solvable in the scenario you're talking about, whether you pass through an EPPN or hash it into something else.

> I also don’t quite understand your uid comment. I
> understand that the uid may not be suitable for federated
> services, but isn't it still suitable within my organization?

My view is that bad things are bad and handling "internal" in a special way because you have more control is a bad path in general that always leads to applying the same practices to everything, not just the internal systems.

>  All the SPs I control understand the concept of a uid because
> they used to receive it via a login form or Basic auth and
> (along with a password) used it to authenticate the user
> against our LDAP directory.

That concept is what you are conflating with the LDAP attribute called "uid", which is inherently lacking in any structure, meaning, or definition whatsoever. Same as CN.

There is nothiing anywhere that defines "uid" as what you're describing. For me, that is disqualifying.

-- Scott