<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
<div>My apologies. While at a high level I understand most of what you are saying, I do not know how to take this from the SP metadata:</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">
<blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><br>
</span></font></blockquote>
<blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:*nameid-format:kerberos*</md:NameIDFormat></span></font></blockquote>
<br>
</div>
<div id="AppleMailSignature">...and code it on our IdP, since we have a requirement to use a users account name and not email address as the record match. Our IdP is Shib version 3x and the instructions from the vendor is using Shib IdP 2x examples in their
documentation. </div>
<div id="AppleMailSignature"><br>
</div>
<blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">why did you configure your IDP to produce the "unspecified" NameID format instead?</span></font></blockquote>
<div><br>
</div>
We are looking for some Shib IdP 3x examples of what goes into our IdP .xml file to make this SP work. We are working to get a meeting with the vendor. My underlying goal here also was to gain more detailed knowledge in prep for this meeting so I am not speaking
out of ignorance.
<div>
<div>
<div><br>
</div>
<div>Thx</div>
<div>DL<br>
<div id="AppleMailSignature"><br>
Sent from an Apple iDevice</div>
<div><br>
On Apr 28, 2019, at 8:12 AM, Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><span>* Lohr, Donald A - lohrda <<a href="mailto:lohrda@jmu.edu">lohrda@jmu.edu</a>> [2019-04-27 14:56]:</span><br>
<blockquote type="cite"><span>The SP configuration is done inside the application on their SAML</span><br>
</blockquote>
<blockquote type="cite"><span>Settings GUI screen. Once configured, this screen has an export</span><br>
</blockquote>
<blockquote type="cite"><span>button which copies the internal configuration to a xml formatted</span><br>
</blockquote>
<blockquote type="cite"><span>file containing the SP metadata. The intent of this file is to</span><br>
</blockquote>
<blockquote type="cite"><span>sneaker-net it to the IdP.</span><br>
</blockquote>
<span></span><br>
<span>OK, so you cannot actually (freely) chose the NameID format the SP</span><br>
<span>expects.</span><br>
<span></span><br>
<blockquote type="cite"><span>We were told the Windows login is equivalent to samaccountname, or</span><br>
</blockquote>
<blockquote type="cite"><span>in our case the CN attribute (a users login account name) in our</span><br>
</blockquote>
<blockquote type="cite"><span>non-AD LDAP directory used by our IdP.</span><br>
</blockquote>
<blockquote type="cite"><span>We believe it is the selection of "Windows login" that wrote the following line to the SP metadata file:</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:Kerberos</md:NameIDFormat></span><br>
</blockquote>
<span></span><br>
<span>OK. Whether an unqualified login user name is legal per RFC 1510 (or</span><br>
<span>if this is in fact a misuse of this NameID format) I'll leave to</span><br>
<span>others. You could say this doesn't matter much for bilerteral one-off</span><br>
<span>configuration but I have no intention of littering my IDP with such stuff.</span><br>
<span></span><br>
<span>But that doesn't change any of my concrete advise and copy/paste-able</span><br>
<span>configuration snippets I provided for your convenience:</span><br>
<span></span><br>
<span>If the above is the format you need to generate then why did you</span><br>
<span>configure your IDP to produce the "unspecified" NameID format instead?</span><br>
<span>I was pointing out that this doesn't make any sense.</span><br>
<span>I was also suggesting a more appropriate way to configure NameIDs in</span><br>
<span>your IDP than using the attribute resolver.</span><br>
<span></span><br>
<span>You're of course free to ignore all that.</span><br>
<span></span><br>
<blockquote type="cite"><span>The use of email address as the record match is a whole nother issue</span><br>
</blockquote>
<blockquote type="cite"><span>to involved to explain here.</span><br>
</blockquote>
<span></span><br>
<span>You'll find that this community has never advised or pushed for use of</span><br>
<span>email addresses as unique identifiers, quite the contrary.</span><br>
<span></span><br>
<span>But again you fail to understand the point I was making: I was</span><br>
<span>pointing out that the metadata you presented would cause the IDP to</span><br>
<span>pick the emailAddress NameID format, which also doesn't match what you</span><br>
<span>said you need to generate. I.e., if you don't want to use</span><br>
<span>emailAddress-type NameIDS (as you keep saying) then don't list them in</span><br>
<span>the SP metadata (first). If, as I said, you manage that metadata</span><br>
<span>yourself.</span><br>
<span>If OTOH you blindly import that metadata directly from the SP and into</span><br>
<span>your IDP (which is a bad idea to begin with) then you'd need to add an</span><br>
<span>override for this SP wrt the NameID format to your relying-party.xml</span><br>
<span>configuration so that the NameIDFormats listed in the SP metadata will</span><br>
<span>be ignored.</span><br>
<span></span><br>
<span>-peter</span><br>
<span>-- </span><br>
<span>For Consortium Member technical support, see <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=XSmEJ40wtGCAuUi9ISZnajyES300ZXleaEkQCAbvsfc&s=TAx-GyoGg0pOPjL6bzZb-M1A2pKfA_dhItUUyeB1HBQ&e=">
https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=XSmEJ40wtGCAuUi9ISZnajyES300ZXleaEkQCAbvsfc&s=TAx-GyoGg0pOPjL6bzZb-M1A2pKfA_dhItUUyeB1HBQ&e=</a></span><br>
<span>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">
users-unsubscribe@shibboleth.net</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>