Ex: Updated Adobe "IDP" (SP) config results in scrambled nameid

[Ben Poliakoff]

On Mon, Oct 19, 2020 at 7:08 PM Paul B. Henson <henson at cpp.edu> wrote:

> On Mon, Oct 19, 2020 at 05:17:45PM -0700, Ben Poliakoff wrote:
> > With the current SP configuration
> > "username at reed.edu<mailto:username at reed.edu>" is released, when I test
> > the new configuration I can see in the logs that it's releasing a 32
> > character alphanumeric string.  And indeed the test result page
> > reports that string as my username.
>
> Sounds like it's getting the transient ID instead of the email address.
> Did you update the Adobe supplied metadata (which at least for my
> deployment listed multiple accepted name ID formats) to only have the
> email format, or override the selected nameid format for the SP?


Yes, it does seem like that. I've tried:

- overriding the nameid format for the SP by adding
'nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"'
to the relying party clause
- removing
'<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>'
from the Adobe supplied metadata

But in both cases my IDP no longer sends any nameid assertion at all (and
authentication tests fail). It's unclear to me why it's refusing to release
the nameid attribute in the way it does with the existing/old Adobe/Okta SP
configuration (attribute release policies for the old SP and the new SP
seem to be identical).

Perhaps there's something else in the new SP metadata file that is causing
the IDP to suppress the emailAddress formatted nameid?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20201020/67c9dc23/attachment.htm>