Cherwell application (on-prem)

[Lohr, Donald A - lohrda]

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. 

In this SAML Settings GUI is listed two choices for "Type of ID":

E-mail address
Windows login

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>

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

DL

Sent from an Apple iDevice

> On Apr 27, 2019, at 6:43 AM, Peter Schober <peter.schober at univie.ac.at> wrote:
> 
> * Lohr, Donald <lohrda at jmu.edu> [2019-04-26 22:56]:
>> In the SP metadata is:
>> 
>> <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>
> 
> Are you manageing the metadata for the SP or are you consuming their
> metadata directly from somewhere else?
> 
> The IDP would use emailAddress if you had configured support for that
> (e.g. for other services) because it's listed first.
> 
> Also why kerberos? The SAML spec defines that NameID format as:
>  Kerberos principal name using the format name[/instance]@REALM.
> but your sAMAccountName will not have an instance nor a REALM?
> 
> To me the more obvious NameID format to use to send a local,
> unqualified userid (sAMAccountName) would be (note the second sentence
> about omitting the qualifier):
> 
> urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
>  A Windows domain qualified user name is a string of the form
>  "DomainName\UserName". The domain name and "\" separator MAY be omitted.
> 
>> <resolver:AttributeDefinition id="sAMAccountName" xsi:type="ad:Simple"
>> sourceAttributeID="cn">
>>     <resolver:Dependency ref="oud" />
>>     <resolver:AttributeEncoder xsi:type="enc:SAML2String"
>> nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
>> name="sAMAccountName" encodeType="false" />
>> </resolver:AttributeDefinition>
> 
> 1. Why would you use the resolver to generate NameIDs and not the
> saml-nameid.xml configuation? Something like this should suffice
> (within the "shibboleth.SAML2NameIDGenerators" list; assuming the
> NameID format I suggested to use above):
> 
> <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>    p:omitQualifiers="true"
>    p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName"
>    p:attributeSourceIds="#{ {'sAMAccountName'} }" />
> 
> 2. Why would you configure support for the "unspecified" NameID format
> if you know the SP wants something else and you said above you want to
> use kerberos?
> 
> So what you say you want to achieve and what you configured simply
> does not match.
> 
> -peter
> -- 
> For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwIFAw&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=m1o6YGZ5Neywi4R8NnrnLei4SYK4WZGUHAbI0lFnamM&s=rrBK9qWTa_8z7vcw5J9suSdjfoknQFSTNcc1x1B5EfM&e=
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net