<div dir="ltr"><div dir="ltr">On Mon, Oct 19, 2020 at 7:08 PM Paul B. Henson <<a href="mailto:henson@cpp.edu">henson@cpp.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Oct 19, 2020 at 05:17:45PM -0700, Ben Poliakoff wrote:<br>
> With the current SP configuration<br>
> "<a href="mailto:username@reed.edu" target="_blank">username@reed.edu</a><mailto:<a href="mailto:username@reed.edu" target="_blank">username@reed.edu</a>>" is released, when I test<br>
> the new configuration I can see in the logs that it's releasing a 32<br>
> character alphanumeric string.  And indeed the test result page<br>
> reports that string as my username.<br>
<br>
Sounds like it's getting the transient ID instead of the email address.<br>
Did you update the Adobe supplied metadata (which at least for my<br>
deployment listed multiple accepted name ID formats) to only have the<br>
email format, or override the selected nameid format for the SP?</blockquote><div><br></div><div>Yes, it does seem like that. I've tried:</div><div><br></div><div>- 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</div><div>- removing '<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>' from the Adobe supplied metadata</div><div><br></div><div>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).</div><div><br></div><div>Perhaps there's something else in the new SP metadata file that is causing the IDP to suppress the emailAddress formatted nameid?</div></div></div>