• Home
• Solutions
• Software
• Services
• About

• Software overview
• Json2Ldap
  • Overview
  • Online Demo
  • Applications
  • Quick Start
  • Specification
  • Configuration
  • Web API
  • Error Codes
  • Roadmap
  • FAQ
• AuthService
  • Overview
  • Quick Start
  • Specification
  • Configuration
  • Web API
  • Error Codes
• NimbusSSO
  • Overview
  • Quick Start
  • Specification
  • Configuration
  • Web API
  • Error Codes
  • Roadmap
• Download

How did Json2Ldap come about?

Json2Ldap is actually a by-product of a larger software project. It was initially conceived to serve a XULRunner business application where a key selling point was presenting user identity data as a JSON web resource. Directories, however, speak LDAP, a binary TCP protocol tailored mostly to intranet environments. The solution - creating a lightweight web service in front of the LDAP directory to translate JSON / HTTP messages to the LDAP protocol and then back.

Making a directory appear as a web service turned out to be a wise decision. It enabled UI engineers to easily link up and mix user data into web pages - in the exact spot and degree of detail the particular screen or form requires, directly at the presentation level using just a few lines of JavaScript.

Early 2010 time was invested to spin off the LDAP gateway / proxy code into a product on its own, which was later named Json2Ldap. It was then realised that Json2Ldap can serve well in many other applications of the Ajax / Cloud / Mashup / Web 2.0 spirit, by providing web-friendly access to directory data and search.

Why JSON-RPC 2.0?

Instead of inventing another ad-hoc JSON schema for Json2Ldap, it was deemed more appropriate to use standard JSON-RPC, which is gradually gaining acceptance now. Version 2.0 of JSON-RPC was chosen over 1.0 because it allows for named parameters, improving API clarity and making it easy 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, and not just once but several times. In the end JSON-RPC was deemed more appropriate for Json2Ldap's intended purpose.

• Utility functions such as ldap.util.isValidDN and ldap.util.normalizeDN do not fit well in the concept of REST.
• The aim of Json2Ldap is to resemble the nature of the original and well-known LDAP protocol as closely as possible. It's just that the requests and the responses are encoded as JSON. For this a remote-procedure call (RPC) protocol is better suited.
• An explicit aim of Json2Ldap is to support cross-domain requests via the CORS-mechanism. Unfortunately, MS-IE's implementation hurts RESTful applications as it only allows GET and POST requests; PUT and DELETE are blocked. This would require work-arounds (such as tunneling) that just make things more complicated.

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.

Using JSON to talk to directory servers over the web has significant advantages: In terms of format, JSON encoded messages are terse and easily consumed by JavaScript programs on the browser side. In terms of API, Json2Ldap keeps a close mapping to the LDAP protocol, so programmers who have previously worked with directories would feel at home.

And how about XLDAP?

Recently there was mention of a new effort, XLDAP, to address the shortcomings of DSML by creating an improved XML-based directory protocol (June 2010). This project appears to be still in an early phase, whereas Json2Ldap is available right now and it offers a friendlier JSON interface.

What are the implications of exposing a directory server on the web?

Use of the LDAP protocol is typically confined within the corporate intranets and isn't really suited to work over the internet. The Json2Ldap gateway / proxy 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.

How does Json2Ldap apply to cloud computing?

The web-friendly JSON + HTTP interface of Json2Ldap can turn any LDAP v3 compatible server into a "cloud directory" for serving various web applications and devices. Contact us if you have interest in a custom cloud directory solution.

Why was the ldap.presetBind request removed from Json2Ldap in version 1.3?

The ldap.presetBind command was removed for the sake of simplicity. During a recent rewrite of the documentation it was noticed that explaining the various security and configuration implications of this RPC request was rather complicated. So it was decided to make life simpler for all of us and this call was scrapped from the Json2Ldap API.

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.