TCK Challenge: ldap-3 uses seeAlso (memberOf) in LDIF without defining those groups

[brideck]

Challenged Tests: ee.jakarta.tck.security.test.AppLDAP2IT#testAuthenticated

TCK Version: Jakarta Security TCK 3.0.0

Tested Implementation: Open Liberty

Description: This test configures an LDAPIdentityStoreDefinition that is setting the groupMemberOfAttribute from the default of "memberOf" to "seeAlso." It configures LDAP with an LDIF that then uses "seeAlso" to list the groups that a particular user belongs to, but does so without actually defining any of those groups.

The LDAPIdentityStoreDefinition does not set the groupNameAttribute, so a default value of "cn" is used. Therefore, [foo, bar] should be returned as a result of the group membership lookup of the authenticated user "reza." To retrieve each group cn, an additional LDAP call needs to be made using the DNs listed in "seeAlso" ("memberOf"). However, since groups foo and bar are not defined in the LDIF, the test fails while attempting these searches.

Accordingly, these two groups should be defined in the LDIF.

[arjantijms]

Thanks for the detailed description. I didn't personally write this test and my LDAP knowledge is admittedly limited. Can you check why other implementations (specifically Soteria, e.g. as in WildFly or GlassFish) does passes the test?

[brideck]

Thanks for the detailed description. I didn't personally write this test and my LDAP knowledge is admittedly limited. Can you check why other implementations (specifically Soteria, e.g. as in WildFly or GlassFish) does passes the test?

We already has this as a to-do, but wanted to get something open. We'll see what we can find.

[brideck]

Thanks for the detailed description. I didn't personally write this test and my LDAP knowledge is admittedly limited. Can you check why other implementations (specifically Soteria, e.g. as in WildFly or GlassFish) does passes the test?

I'm not a Security/LDAP person (and I'm having other Open Liberty devs take a look, too), but I think that was easier than I expected. Soteria is stripping the cn value out of the supplied dn value and doing no verification (that I can see) that the group in question actually exists -- https://github.com/eclipse-ee4j/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/identitystores/LdapIdentityStore.java#L197

[arjantijms]

That all sounds quite reasonable. So we have to update both the test and Soteria then, and additionally add another test like the current one but test for the negative outcome (it should fail).

[ryanesch]

Can you check why other implementations (specifically Soteria, e.g. as in WildFly or GlassFish) does passes the test?

The RI (Soteria) only allows groupNameAttribute to be an RDN (cn, uid, etc.) in the DN or the full DN. The spec does not say groupNameAttribute must be an RDN within the DN. The RI will fail if the groupNameAttribute is not in the DN. Imagine a scenario where two groups have DNs cn=group1,o=co and uid=group2,o=co. The RI could use full DN to return these, but if they used groupNameAttribute as any other attribute (uid, cn), they would not be able to return both groups. Or a scenario where the user wants groupUID or any other attribute to be returned.

[teddyjtorres]

Hi @arjantijms, Please let us know if this challenge has been accepted or if more information is needed.

Regards, Teddy

[arjantijms]

For completeness tagging @wmhopkins who originally implemented this in https://github.com/javaee/security-soteria/commit/b208e0777eeaa76ba136f5ddd332389c0a5284c3

[arjantijms]

@ryanesch

Imagine a scenario where two groups have DNs cn=group1,o=co and uid=group2,o=co.

Do we actually want to allow groups that are defined differently? Is it a realistic scenario where one group has the group name in the cn RDN and another one has the group name in the uid RDN?

The spec does not say groupNameAttribute must be an RDN within the DN.

It feels more naturally to me to require that, at least from my experience with data in SQL, JSON, XML, etc. As I mentioned above, my LDAP knowledge is limited to just the basics of definitions and searching, so I can't really tell how normal it is for LDAP to have such non-consistent definitions.