Attribute not being added to assertion if username is in mixed case

Tue Jan 5 15:36:58 UTC 2021

It sounds like your ldap server is configured for case-sensitive searches
on memberUid, which I think is pretty standard.  That's why your ldap
filter is returning no results when the supplied UID doesn't match.  You'll
either need to change your ldap server (probably not a good idea?), do
something to fold the case to lowercase in your FilterTemplate, or live
with user education.

-Les

<http://www.carleton.edu/>

*Les LaCroix '79*

Strategic Technologist

Information Technology Services

t: (507) 222-5455

On Tue, Jan 5, 2021 at 9:20 AM Adam Bishop via users <users at shibboleth.net>
wrote:

> If a user logs into our IDP instance with a mixed case username (e.g.
> Adam.Bishop rather than adam.bishop), their group membership information is
> not added to the assertion.
>
> Using case that matches their UID as stored in ldap (i.e. all lower case),
> it works as expected. I've reproduced it with my own account - the consent
> screen has no 'member' attribute in the list if I uppercase my username,
> and the the SP receives no 'member' attribute.
>
> We're running 3.4.8, and upgraded a few days after release so it's
> possible this is recent breakage. Our configuration is fairly default, just
> password based login flows to <20 non-federated SP's.
>
> The attribute is defined as:
>
>     <AttributeDefinition id="member" xsi:type="Simple">
>         <InputDataConnector ref="ipaGroupQuery" attributeNames="cn" />
>         <AttributeEncoder xsi:type="SAML2String"
> name="urn:oid:1.3.6.1.4.1.5923.1.5.1.1" friendlyName="member"
> encodeType="false" />
>     </AttributeDefinition>
>
> The ldap search filter is:
>         <FilterTemplate>
>             <![CDATA[
>                 (memberUid=${resolutionContext.principal})
>             ]]>
>         </FilterTemplate>
>
> The release policy is:
>
>     <AttributeFilterPolicy id="releaseToAll">
>         <PolicyRequirementRule xsi:type="ANY" />
>         ...
>         <AttributeRule attributeID="member">
>             <PermitValueRule xsi:type="ANY" />
>         </AttributeRule>
>         ...
>     </AttributeFilterPolicy>
>
> I've configured additional logging, and I can see that the group query is
> executed, and does return the list of groups (see end of email) - so what
> could be going on between the LDAP query and the assertion being sent.
>
> It'll probably all work if I set shibboleth.authn.Password.Lowercase but
> that seems like a hack - if the group list is being returned by LDAP,
> matches the definition, and passes the filter policy it should be included
> as far as I understand.
>
> Thanks for any assistance,
>
> Adam Bishop
> Senior security architect (systems)
>
>   gpg: E75B 1F92 6407 DFDF 9F1C  BF10 C993 2504 6609 D460
>
> jisc.ac.uk
>
> ---
>
> 2021-01-05 14:47:29,873 - 88.98.83.40 - DEBUG
> [org.ldaptive.SearchOperation:168] - execute
> response=[org.ldaptive.Response at 1501309882
> ::result=[org.ldaptive.SearchResult@
> -887324086::entries=[[dn=uid=user,cn=users,cn=accounts,dc=domain[[mail[
> user.name at jisc.ac.uk]], [ipaUniqueID[**snip**]],
> [krbLastPwdChange[20200421092040Z]], [title[Normal User]],
> [objectClass[inetuser, ipasshuser, ipantuserattrs, inetorgperson,
> ipaobject, krbprincipalaux, organizationalperson, top, person,
> ipauserauthtypeclass, krbticketpolicyaux, ipaSshGroupOfPubKeys,
> mepOriginEntry, posixaccount]], [loginShell[/bin/bash]], [uid[user]],
> [krbPasswordExpiration[20210421092040Z]], [homeDirectory[/home/user]],
> [givenName[User]], [ipaSshPubKey[*snip*]], [sn[Name]],
> [entryDN[uid=user,cn=users,cn=accounts,dc=domain]],
> [manager[uid=user,cn=users,cn=accounts,dc=domain]],
> [ipaNTSecurityIdentifier[**snip**]], [ou[Null]], [initials[UN]],
> [gidNumber[100]], [krbPrincipalName[user at DOMAIN]], [cn[User Name]],
> [uidNumber[100]], [gecos[User Name]], [displayName[User Name]], [memberOf[
>
> ** snip giant list of groups **
>
> ]], [ipaUserAuthType[otp]]], responseControls=null, messageId=-1]],
> references=[]], resultCode=SUCCESS, message=null, matchedDn=null,
> responseControls=null, referralURLs=null, messageId=-1] for
> request=[org.ldaptive.SearchRequest at -32050967::baseDn=cn=users,cn=accounts,dc=domain,
> searchFilter=[org.ldaptive.SearchFilter at 664361842::filter=(uid=USER),
> parameters={}], returnAttributes=[], searchScope=SUBTREE, timeLimit=3000,
> sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null,
> sortBehavior=UNORDERED,
> searchEntryHandlers=[[org.ldaptive.handler.DnAttributeEntryHandler at -1580910376::dnAttributeName=entryDN,
> addIfExists=false]], searchReferenceHandlers=null, controls=null,
> followReferrals=false, intermediateResponseHandlers=null] with
> connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection at 1379181151
> ::config=[org.ldaptive.ConnectionConfig at 139698044::ldapUrl=ldaps://server1.domain:636
> ldaps://server2.domain:636, connectTimeout=3000, responseTimeout=3000,
> sslConfig=[org.ldaptive.ssl.SslConfig at 1806414996
> ::credentialConfig=org.ldaptive.ssl.CredentialConfigFactory$2 at 7563ad67,
> trustManagers=null, hostnameVerifier=null, hostnameVerifierConfig=null,
> enabledCipherSuites=null, enabledProtocols=null,
> handshakeCompletedListeners=null], useSSL=false, useStartTLS=false,
> connectionInitializer=[org.ldaptive.BindConnectionInitializer at 1511278406::bindDn=uid=sso-bind,cn=users,cn=accounts,dc=domain,
> bindSaslConfig=null, bindControls=null]],
> providerConnectionFactory=[org.ldaptive.provider.jndi.JndiConnectionFactory at 1840180882::metadata=[ldapUrl=ldaps://server1.domain:636
> ldaps://server2.domain:636, count=1],
> environment={java.naming.ldap.factory.socket=org.ldaptive.ssl.ThreadLocalTLSSocketFactory,
> com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> com.sun.jndi.ldap.read.timeout=3000},
> providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig at 1584406844::operationExceptionResultCodes=[PROTOCOL_ERROR,
> SERVER_DOWN], properties={},
> connectionStrategy=org.ldaptive.provider.ConnectionStrategies$ActivePassiveConnectionStrategy at 6534274a,
> controlProcessor=org.ldaptive.provider.ControlProcessor at 57e4f242,
> environment=null, tracePackets=null, removeDnUrls=true,
> searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED,
> PARTIAL_RESULTS], sslSocketFactory=null, hostnameVerifier=null]],
> providerConnection=org.ldaptive.provider.jndi.JndiConnection at 5ad91aa0]
>
>
>
>
>
> Jisc is a registered charity (number 1149740) and a company limited by
> guarantee which is registered in England under company number. 05747339,
> VAT number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane,
> Bristol, BS1 6NB. T 0203 697 5800.
>
>
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company
> limited by guarantee which is registered in England under company number
> 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall
> Lane, Bristol, BS1 6NB. T 0203 697 5800.
>
>
> Jisc Commercial Limited is a wholly owned Jisc subsidiary and a company
> limited by shares which is registered in England under company number
> 09316933, VAT number GB 197 0632 86. The registered office is: 4 Portwall
> Lane, Bristol, BS1 6NB. T 0203 697 5800.
>
>
> For more details on how Jisc handles your data see our privacy notice
> here: https://www.jisc.ac.uk/website/privacy-notice
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210105/14fddd3b/attachment.htm>