Json2Ldap articles

Json2Ldap 3.1

Posted on 2017-07-20

The Json2Ldap web service for working with LDAP directories received several updates under the hood. Most notably, logging was upgraded to Log4j 2. This means that logging can now be reconfigured on the fly, with zero service downtime, and its I/O performance is sped up too.

Note that Log4j 2 requires a new configuration file.

Check the release notes below for details.

Release Notes

version 3.1 (2017-07-20)

  • Switches to Log4j 2 logging, which is now configured by /WEB-INF/log4j.xml.
  • Refactoring and clean up of source code.
  • Upgrades Apache Commons Codec to 1.10.
  • Upgrades NimbusDS Common to 1.108.1.
  • Upgrades CORS Filter to 2.5.
  • Upgrades Property Utils to 1.10.
  • Upgrades JSON Smart to 1.3.1.
  • Upgrades JSON-RPC 2.0 Base to 1.38.
  • Upgrades JSON-RPC 2.0 Server to 1.11.
  • Upgrades JSON-RPC 2.0 Access Filter to 1.5.1.
  • Upgrades Nimbus SRP 6a to 2.0.2.
  • Upgrades UnboundID LDAP SDK to 3.2.1.
  • Upgrades Log4j to 2.8.2.

Json2Ldap 3.0.6

Posted on 2015-05-28

There is a new maintenance release of the Json2Ldap web API service for LDAP directory access.

Bug fixes:

  • Fixes the json2ldap.ldap.requireSecureAccess configuration setting to correctly identify and block non-TLS/SSL LDAP connection if the setting is enabled (iss #14, reported 2015-05-28).

The 3.0.6 maintenance release is available for download now.

Should you have any questions about the new release, don’t hesitate to contact our support.

Today we also updated the FAQ section with instructions how to set up a X.509 client certificate to provide an additional layer of authentication to clients and apps that access the Json2Ldap web API.

User passwords should never leave the browser

Posted on 2014-04-16

The OpenSSL Hearbeat incident taught us an important lesson — user passwords should never leave the confines of the browser and be sent across the network.

But how can that be achieved?

Enter the Secure Remote Password

A solution that is not widely known has existed for over a decade and it’s called Secure Remote Password or SRP for short. SRP is an ingenious cryptographic protocol for user authentication based on the principle of zero knowledge password proof.

How does SRP work?

The common approach when a user signs up is to ask her for a name and password, which then get saved on the server. Servers may save the password in plain text, which is bad in case the server gets compromised and the credentials get stolen. People tend to reuse passwords a lot, which means that once a user password gets compromised, the attacker has a chance of more than 50% to gain access to other services and web sites where the person is subscribed.

To mitigate against this servers employ a technique of storing the password in hashed form, typically mixed with a salt) and passed one or more times (the more the better for security) through a SHA1 or PBKDF2 algorithm so that in case the server gets compromised, reconstructing the password through brute force dictionary attacks becomes impractical (or at least buy enough time to notify users of the breach and let them change the passwords).

Unfortunately, storing the password in hashed form on the server side doesn’t prevent password leaks when the Transport Level Security (or TLS / SSL) fails, as was the case with the Heartbeat incident. To eliminate this particular risk we must ensure that the user’s password is never transmitted across the network. The Secure Remote Password protocol does just that.

When a user registers with an SRP-enabled website, the password gets entered in the browser and a piece of JavaScript computes the so-called verifier from it — a very long cryptographic number which can be used to check the password, but is not the password itself; the actual password is discarded by the JavaScript once the verifier is computed. This verifier then gets sent over the network to the server to create the user’s account.

When the user logs in the the SRP-enable website, the input password is again processed by a piece of JavaScript to produce a cryptographic number, which is passed over the network to the server, and which the verifier (installed previously during registration) can check for whether it was derived from the password or not, thus completing the user authentication. Note again that the password itself does not leave the user’s computer. What browser and server exchange is cryptographic number based on the verifier and password.

The properties of the SRP protocol make it resistant to eavesdropping and man-in-the-middle attacks. A TLS/SSL channel is not technically required to secure the message exchange in the SRP protocol, but if used can add an additional layer of protection.

Combining SRP with PBKDF2 for even greater overall security

To make brute force attacks against leaked SRP verifiers from a compromised server harder, we recommend using multiple iterations (1000+) of PBKDF2 on the input password in JavaScript. Using PBKDF2 with SRP in this way can significantly up the security of the entire authentication system. It also can save on the server bills, since the CPU-intensive PBKDF2 iterations happen not on the server, but on the user’s computer, inside their browser.

How to implement SRP + PBKDF2

Connect2id offers a comprehensive open source Java library for SRP servers and clients, as well as a command-line tool for testing and debugging purposes.

There also exist a number of JavaScript libraries, to perform the necessary modulus and PBKDF2 computations inside the browser. Google and Mozilla have recognised the importance of having native support of crypto operations inside the browser as evidenced by the WebCrypto API effort at the W3C which is quickly approaching completion.

To sum up, all required technology for SRP and PBKDF2 is there, so there’s no excuse to not make authentication for users more secure.

Enabling SRP for LDAP authentication

We have also added Secure Remote Password support to our Json2Ldap middleware, so that businesses can easily implement SRP authentication against their existing LDAP directory servers. Get in touch with us to find out more about this option.

Json2Ldap adds directory server fail-over and load-balancing

Posted on 2013-01-24

The new year began with the third major release of Json2Ldap, the cool JSON web API for accessing directory servers such as MS Active Directory, OpenLDAP and OpenDJ.

This post is a summary of what’s in the new 3.0 version.

Directory server fail-over and load-balancing

Resilience and scalability is a common requirement in enterprise and SaaS applications. You can now configure Json2Ldap to fail-over between two or more directory servers, or alternatively, to perform round-robin directory server selection.

Fail-over is a common strategy to provide backup in case your primary LDAP server fails. To handle such situations you can specify a secondary, tertiary, and so on servers for Json2Ldap to connect to if the primary becomes unavailable.

To configure fail-over:

json2ldap.defaultLDAPServer.selectionAlgorithm = FAILOVER
json2ldap.defaultLDAPServer.url = ldap:// ldap://
json2ldap.defaultLDAPServer.connectTimeout = 500

The above configuration will set a secondary LDAP server on IP Json2Ldap will direct new ldap.connect requests to it if it’s not able to connect to the primary server within 500 milliseconds.

Round-robin is the alternative server selection method. It provides for load-balancing between multiple servers and is also a form of fail-over in case one or more of the servers in the set become unavailable.

To configure round-robin selection with two servers, using again a connect time-out of 500ms:

json2ldap.defaultLDAPServer.selectionAlgorithm = ROUND-ROBIN
json2ldap.defaultLDAPServer.url = ldap:// ldap://
json2ldap.defaultLDAPServer.connectTimeout = 500

Configuration of fail-over and round-robin is explained in detail in the Json2Ldap docs.

Support for Virtual-List-View searches

The Virtual-List-View (VLV) control (draft-ietf-ldapext-ldapv3-vlv-09) allows web clients to retrieve an arbitrary subset of an LDAP search result. You can think of it as a sophisticated makeover of the Simple Paged Results (RFC 2696) control. The VLV control allows you to specify an offset into the result set and a number of entries to get before and after the offset position. This can for instance be of great help in devising efficient browsing web UIs when the result sets are expected to be huge.

To apply VLV to an ldap.search request add a parameter like this:

"vlv" : { "offset":50, "after":24 }

This will ask to return 25 entries at offset fifty. Note that the VLV control also requires the presence of a sort control in order to determine the entry order, e.g.:

"sort" : { "key":"givenName" }

I have put together a list of the directory servers that support Virtual-List-View. A brief look at the list will show you that it’s widely supported. You may however have to create specific indexes in your directory to enable it. Check you server documentation for that.

Use of the VLV control in Json2Ldap is detailed in the ldap.search API docs.

Normalising attribute names

The attribute names that Json2Ldap returns with ldap.getEntry, ldap.search and ldap.getRootDSE appear as defined in the directory schema. However, if you don’t have prior knowledge of their letter-case retrieving them from the result JSON object can be a bit of a problem.

var givenName = result["givenName"];

The solution to this has been to normalise all names, e.g. converting them to lower-case, before processing the result.

Json2Ldap 3.0 added a new optional normalize parameter to solve this problem. With it all attribute names in the result will be normalised, or converted to lower-case. So you don’t have to worry about the extra conversion. It will be done for you, quite efficiently, inside Json2Ldap.

Retrieving subordinate subtree entries

The ldap.search SUBORDINATE_SUBTREE scope parameter has been renamed to SUBORDINATES. This is the only breaking change in the Json2Ldap web API and was done to make the parameter compatible with the LDAP URL schema.

API keys

You can now also specify API keys to ensure only selected web clients can access the web API of Json2Ldap. These are passed as an optional apiKey parameter to each web call. You can define API keys for global access as well as keys that are only for certain API calls. Check out the API key configuration to find out more.

The classic X.509 client certificate access controls are still supported.

Simplified configuration files

Json2Ldap 3.0 moved the configuration parameters from the web.xml file to a set of simpler text properties files that continue to follow the established semantics. Many of the configuration properties were also given better and more intuitive names. As a result the whole task of configuring Json2Ldap should have become easier and less error-prone (by switching from XML to simple key / value properties). Adding a web UI configuration editor is on the roadmap for 2013 / 2014.

Ready to try out Json2Ldap 3.0?

You can get a copy of Json2Ldap 3.0 for evaluation from the product downloads section. Existing subscribers should have already been notified and received their download links for the full version.

[You’re welcome to get in touch with us if you have questions about the new version or feedback to share.

The full 3.0 change log is on the Json2Ldap datasheet.