Consequences of Permitting SAML NameID to Subject Mapping

[Cantor, Scott]

On 8/10/18, 8:20 AM, "users on behalf of Marvin Addison" <users-bounces at shibboleth.net on behalf of serac at vt.edu> wrote:

> We have run into a problem with a relying party that is sending a requested NameID in SAML AuthnRequests:

That's almost certainly a bug.

> I'd never seen this before, and frankly didn't even know it was a supported capability of the SAML 2 spec, but I was able
> to convince myself it made sense on further consideration.

It isn't a hint, though. The purpose of that feature was to support "stand alone" use of an IdP to request a token with specific content for web services. That's not a real use case anymore because WS-* died, so it's mostly a historical feature now.

People misuse it now to say "I think it's Bob, so maybe see if it's Bob", but the rules are that if it's not Bob, you have to fail the request. That's usually not what people want.
 
> Upon reviewing configuration and docs [1] to enable support for it, the defaults were so conservative that I wanted to
> make sure I understand the consequences.

They're conservative mainly because they're not possible to configure without local knowledge. There's no way the IdP can assume that dropping @vt.edu from an email address will produce a valid user name for "canonical" purposes, and it has to be canonical in order for the IdP to verify that it's issuing an assertion for the correct principal later since it has to match that one to one. So it has to leave that to local setup to make it work.

About the only "built-in" case would be transient ID reversal, but it's not sensible to request that this way, so it's not enabled.

> My intention is to allow mapping SAML NameIDs to subjects for a relying party group that includes SPs that are highly
> trusted (i.e. paying customers, legal contracts). That's simply a more manageable way than explicitly listing SPs per the
> default configuration template.

That's the other reason this was left locked down, the old IdP was a bit permissive about it because it didn't have the notion of an activation condition to control it well. Now it's a simple matter to enable it for exactly who you want to, so leaving it off made sense.

> What's the risk of allowing this reverse lookup?

Nothing really unless you allow Attribute Queries, then it provides direct access to whatever data is released to that SP based on that ID. You can think of it like a pseudo-token that effectively authorizes access to attributes about that subject.

-- Scott