Json2Ldap, the novel LDAP gateway/proxy for web + cloud apps, has received an update.
With version 1.2 the configuration of the web service was completely overhauled. Considerable amount of thought went into making sure the various config parameters made intuitive sense to users. Their naming and categorisation structure was reworked; new important ones were added too:
- json2ldap.clients.connectionQuotaPerBindDN This new parameter allows administrators to specify a connection quota per bound DN. This works similarly to the existing parameter for limiting LDAP connection count per client IP, but here the number of connections per authenticated user is controlled instead. I’ve given more details about the bind DN quota configuration in an earlier post.
- json2ldap.clients.maxConnectionTime With this parameter administrators can limit the total LDAP connection time. Previously only a max idle time could be set (after which the connection automatically expires and is closed).
- json2ldap.clients.maxConnectionTime This parameter affects the outgoing LDAP connections between Json2Ldap and the back-end directory servers. This makes use of a feature of the underlying LDAP library to attempt an automatic reconnect if for some reasons the LDAP connection is unexpectedly lost.
- json2ldap.clients.denyPasswordModifyRequests This parameter allows administrators to control whether extended requests for a “Password Modify” (RFC 3062) are to be relayed by the Json2Ldap gateway/proxy.
- json2ldap.clients.denyWhoAmIRequests Similarly to the previous parameter, but controls the relay of “Who am I?” extended requests (RFC 4532).
You can find out more about the Json2Ldap configuration in the technical spec and in the manual pages. Existing users upgrading to 1.2 will need to reconfigure their Json2Ldap installations (all config params are kept in the
WEB-INF/web.xml file of the WAR). The JSON-RPC 2.0 API has not changed in this version.
Has anything happened under the hood?
Well, there were a few refactorings here and there, but mostly in the Java code managing the storage, expiration and client IP and bind DN tracking of established LDAP connections. The dependence on the Apache Commons Collections package is also gone now. All this has made the Json2Ldap package nimbler and simpler to maintain. I must say I’m really satisfied with the elegance of the underlying code now 🙂
So, that’s it, let’s have a “Rythmology” weekend now!