Cherwell application (on-prem)

[Lohr, Donald A - lohrda]

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:

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:*nameid-format:kerberos*</md:NameIDFormat>

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

why did you configure your IDP to produce the "unspecified" NameID format instead?

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.

Thx
DL

Sent from an Apple iDevice

On Apr 28, 2019, at 8:12 AM, Peter Schober <peter.schober at univie.ac.at<mailto:peter.schober at univie.ac.at>> wrote:

* Lohr, Donald A - lohrda <lohrda at jmu.edu<mailto:lohrda at jmu.edu>> [2019-04-27 14:56]:
The SP configuration is done inside the application on their SAML
Settings GUI screen. Once configured, this screen has an export
button which copies the internal configuration to a xml formatted
file containing the SP metadata. The intent of this file is to
sneaker-net it to the IdP.

OK, so you cannot actually (freely) chose the NameID format the SP
expects.

We were told the Windows login is equivalent to samaccountname, or
in our case the CN attribute (a users login account name) in our
non-AD LDAP directory used by our IdP.
We believe it is the selection of "Windows login" that wrote the following line to the SP metadata file:

<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:Kerberos</md:NameIDFormat>

OK. Whether an unqualified login user name is legal per RFC 1510 (or
if this is in fact a misuse of this NameID format) I'll leave to
others. You could say this doesn't matter much for bilerteral one-off
configuration but I have no intention of littering my IDP with such stuff.

But that doesn't change any of my concrete advise and copy/paste-able
configuration snippets I provided for your convenience:

If the above is the format you need to generate then why did you
configure your IDP to produce the "unspecified" NameID format instead?
I was pointing out that this doesn't make any sense.
I was also suggesting a more appropriate way to configure NameIDs in
your IDP than using the attribute resolver.

You're of course free to ignore all that.

The use of email address as the record match is a whole nother issue
to involved to explain here.

You'll find that this community has never advised or pushed for use of
email addresses as unique identifiers, quite the contrary.

But again you fail to understand the point I was making: I was
pointing out that the metadata you presented would cause the IDP to
pick the emailAddress NameID format, which also doesn't match what you
said you need to generate. I.e., if you don't want to use
emailAddress-type NameIDS (as you keep saying) then don't list them in
the SP metadata (first). If, as I said, you manage that metadata
yourself.
If OTOH you blindly import that metadata directly from the SP and into
your IDP (which is a bad idea to begin with) then you'd need to add an
override for this SP wrt the NameID format to your relying-party.xml
configuration so that the NameIDFormats listed in the SP metadata will
be ignored.

-peter
--
For Consortium Member technical support, see 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=
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190428/86ec7e45/attachment.html>