Cherwell application (on-prem)

Peter Schober peter.schober at
Sun Apr 28 08:12:26 EDT 2019

* Lohr, Donald A - lohrda <lohrda at> [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

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


More information about the users mailing list