Consequences of Permitting SAML NameID to Subject Mapping

[Marvin Addison]

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

    <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
        <saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
nobody at vt.edu</saml:NameID>
    </saml:Subject>

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. 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. 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.

What's the risk of allowing this reverse lookup?

Thanks,
Marvin at Virginia Tech

[1] https://wiki.shibboleth.net/confluence/x/C4AEAQ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180810/88889040/attachment.html>