Grouper Developers Forum

[Tom Zeller <>]

For those interested, I'd thought I'd relate current progress on ldappc-ng.

I'm mostly writing and running end-to-end junit tests. In addition to
verifying that ldap directories are being provisioned correctly, I'm
also verifying the intermediary spml messages.

I was stuck for a day or two on identifier canonicalization. The
current ldappc converts ldap dns to lowercase, which may not be
entirely correct. I went and read a couple of rfcs to see if dns are
explicity case-insensitive, but they aren't. Dns are composed of rdns
which are composed of attribute type and value pairs, which are schema
dependant. So, case sensitive dns are possible. Active Directory tends
to return attribute types in uppercase (DC=memphis,DC=edu), so I
decided to lowercase attribute types (since they are explicitly
case-insensitive). Fortunately, the ApacheDS LdapDN() class does this
for us via toString() - I guess they've been there already.

I'm currently pondering how to handle the fact that the groupOfNames
objectclass declares the member attribute as MUST, not MAY. When
provisioning an empty group to a vanilla openldap installation, the
member attribute must exist with some (configurable) value. Ldappc has
handled this for a while.

However, Active Directory requires that the values of the member
attribute be dns of currently existing objects. Consequently, when
provisioning AD, it makes sense to first provision groups without any
members, then a second time with members, to avoid errors. To do this,
I was going to submit a BulkCalcRequest with ReturnData set to "data",
then a second time set to "everything". The options are "identifier",
"data" (identifier + attributes), and "everything",
(identifier+attributes+references). This approach will fail for
openldap, since it requires the member attribute (which is defined as
a reference).

So, there are a couple of options. One is to handle the MUST member
attribute in a subclass of the spml-to-ldap-connector
(LdapTargetProvider, ala OpenLdapTargetProvider extends
LdapTargetProvider). I was thinking of avoiding this kind of
customization in the spml-to-ldap-connector, since it would be sort of
hidden away. Another option is for the PSP to handle this (like ldappc
does now). The second option would be bending spml, in that when
ReturnData is set to "data", we'll still return an empty reference
which should really only be present when ReturnData is set to
"everything". We could define a custom ReturnData value, for example,
"required", but this might be too much for a first release.

Thoughts on bending spml ?

TomZ