How did Json2Ldap come about?
Json2Ldap was born as a by-product of a large software project in 2009. Its job was to present user identity data as a JSON web resource that is simple to integrate and manage, as part of a complex rich internet application (RIA).
Over the following years Json2Ldap quickly matured and is now serving a wide range of applications that benefit from web-friendly access to LDAP directory data - from Ajax apps to back-end software for provisioning and synchronising users onto cloud apps / SaaS.
Why JSON-RPC 2.0?
JSON-RPC provided a clean path to keep the spirit of the original LDAP protocol. Moreover, its RPC messages can flow nicely through web sockets (on our road map).
Version 2.0 of JSON-RPC was chosen over 1.0 because it enables named parameters, improving API clarity and allowing us to add new request parameters in future without breaking backward compatibility. JSON-RPC 2.0 also has better error reporting.
Why not a RESTful web API?
REST was given serious consideration. In the end JSON-RPC was deemed more appropriate for Json2Ldap for two reasons:
The objective of Json2Ldap was to mimic the nature of the original LDAP protocol as closely as possible, while using JSON to encode the messages.
How about DSML?
DSML is, well, what the acronym implies - it’s dismal :-) The first version of this protocol was devised in 1999, but it didn’t really pick up, and even the subsequent revision in 2001 wasn’t particularly successful.
How does the Json2Ldap API compare to SCIM?
SCIM is a recent effort to provide RESTful access to identity data. Json2Ldap on the other hand offers a general purpose web API for working with any LDAP or virtual directory, and is not tied to a particular schema.
What security features does Json2Ldap have?
Use of the LDAP protocol is typically confined within the corporate intranets and isn’t really suited to work over the internet. The Json2Ldap is not just about rewriting the incoming JSON messages as LDAP requests. It also offers mechanisms to ensure that sensitive information is protected and chances of denial-of-service attacks are minimised:
LDAP server whitelists.
Connection quotas per client IP and authenticated user (bind DN).
Use of secure connection identifiers (CID).
Clients may be required to authenticate using LDAP “bind” at connection time.
Allowing for default connect requests where the hostname/IP address of the back-end LDAP server remain hidden from web clients.
TLS/SSL may be required for the client-gateway and/or the gateway/LDAP server connections.
Directory access may be limited to read-only or authenticate-only.
Cloud directory with Json2Ldap?
Json2Ldap can be fitted to any LDAP directory hosted in the cloud and web-enable it so that cloud-based or on-premise apps can conveniently work with identity data stored in it.
Why was the ldap.presetBind request removed from Json2Ldap in version 1.3?
The ldap.presetBind command was removed for the sake of simplicity. We realised that explaining the various security and configuration implications of this request was rather complicated, so we scrapped it from the Json2Ldap web API. Life should now be simpler for you and us too :)
Why do I get an LDAP error 11 (Admin Limit Exceeded) when making searches?
This error is raised when the so-called “look through” limit is exceeded. If you’re using OpenDS set the ds-cfg-lookthrough-limit configuration parameter to a value that is greater than the total number of entries in your directory.