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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Shibboleth - Users mailing list
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@1501309882::result=[org.ldaptive.SearchResult@-887324086::entries=[[dn=uid=user,cn=users,cn=accounts,dc=domain[[mail[[hidden email]]], [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@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@-32050967::baseDn=cn=users,cn=accounts,dc=domain, searchFilter=[org.ldaptive.SearchFilter@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@-1580910376::dnAttributeName=entryDN, addIfExists=false]], searchReferenceHandlers=null, controls=null, followReferrals=false, intermediateResponseHandlers=null] with connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1379181151::config=[org.ldaptive.ConnectionConfig@139698044::ldapUrl=ldaps://server1.domain:636 ldaps://server2.domain:636, connectTimeout=3000, responseTimeout=3000, sslConfig=[org.ldaptive.ssl.SslConfig@1806414996::credentialConfig=org.ldaptive.ssl.CredentialConfigFactory$2@7563ad67, trustManagers=null, hostnameVerifier=null, hostnameVerifierConfig=null, enabledCipherSuites=null, enabledProtocols=null, handshakeCompletedListeners=null], useSSL=false, useStartTLS=false, connectionInitializer=[org.ldaptive.BindConnectionInitializer@1511278406::bindDn=uid=sso-bind,cn=users,cn=accounts,dc=domain, bindSaslConfig=null, bindControls=null]], providerConnectionFactory=[org.ldaptive.provider.jndi.JndiConnectionFactory@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@1584406844::operationExceptionResultCodes=[PROTOCOL_ERROR, SERVER_DOWN], properties={}, connectionStrategy=org.ldaptive.provider.ConnectionStrategies$ActivePassiveConnectionStrategy@6534274a, controlProcessor=org.ldaptive.provider.ControlProcessor@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@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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Shibboleth - Users mailing list
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

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 <[hidden email]> 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@1501309882::result=[org.ldaptive.SearchResult@-887324086::entries=[[dn=uid=user,cn=users,cn=accounts,dc=domain[[mail[[hidden email]]], [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@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@-32050967::baseDn=cn=users,cn=accounts,dc=domain, searchFilter=[org.ldaptive.SearchFilter@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@-1580910376::dnAttributeName=entryDN, addIfExists=false]], searchReferenceHandlers=null, controls=null, followReferrals=false, intermediateResponseHandlers=null] with connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1379181151::config=[org.ldaptive.ConnectionConfig@139698044::ldapUrl=ldaps://server1.domain:636 ldaps://server2.domain:636, connectTimeout=3000, responseTimeout=3000, sslConfig=[org.ldaptive.ssl.SslConfig@1806414996::credentialConfig=org.ldaptive.ssl.CredentialConfigFactory$2@7563ad67, trustManagers=null, hostnameVerifier=null, hostnameVerifierConfig=null, enabledCipherSuites=null, enabledProtocols=null, handshakeCompletedListeners=null], useSSL=false, useStartTLS=false, connectionInitializer=[org.ldaptive.BindConnectionInitializer@1511278406::bindDn=uid=sso-bind,cn=users,cn=accounts,dc=domain, bindSaslConfig=null, bindControls=null]], providerConnectionFactory=[org.ldaptive.provider.jndi.JndiConnectionFactory@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@1584406844::operationExceptionResultCodes=[PROTOCOL_ERROR, SERVER_DOWN], properties={}, connectionStrategy=org.ldaptive.provider.ConnectionStrategies$ActivePassiveConnectionStrategy@6534274a, controlProcessor=org.ldaptive.provider.ControlProcessor@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@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 [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]