The current implementation is tied to LDAP RACF only

[jamsden]

The access to LDAP should be encapsulated totally in LdapConnection so that it can support RACF or any other LDAP server that supports OrganizationalUnits.

That is, only two configurations of LDAP would be supported, RADF and the standard LDAP schemas for groups and members that are typically installed by default in LDAP directory servers.

Customers would be expected to have these schemas installed in their directory server, and use them for the groups and members used by LDAP-RTC Synchronizer.

[jamsden]

If we stick to this same design, then the only thing that would need to change is the implementation of LdapConnect.getMembers(). That is, the only things that are LDAP specific in the implementation are the racfgroupuserids (to identify members of a group) and racfsubgroupname (to identify subgroups of a group) properties.

However, I would recommend that customers using non-RACF LDAP directory servers might benefit greatly from the original design where there is no configuration file and all the RTC/CLM user information is in LDAP. This would require a somewhat different implementation, but a lot of the code could be reused. The difference would be that the RTC user configuration information would come from LDAP rather than from the JSON configuration file. This should be a simple change in the implementation of methods that provide that information.

[jamsden]

We may need to assess the actual demand for this, and whether it can be provided by the open source community if desired.