Json2Ldap gets mentioned in Network World

Json2Ldap iconThanks to Dave Kearns for mentioning Json2Ldap in his last week’s IdM newsletter for Network World. I hope that would help towards making the software more popular.

Since its 1.0 release at the end of April 2010 initial sales have been rather disappointing. I suppose this has got to do with Json2Ldap being a truly novel product, so potential clients wouldn’t even suspect that such a solution existed. Directory services are typically regarded as a “deep” back-end function and few people involved with LDAP and IdM probably imagine that they can be exposed as a web service in a simple and elegant way. I guess it would take some time and campaigning to change this mindset.

So currently I’m looking for a partner to step up the marketing of Json2Ldap so I can go back to my real job, the greater Transaction Company software project. The LDAP web gateway/proxy was, after all, just a side-product of this project, but still, why not take advantage and its uniqueness and usefulness and help it grow into a popular product on its own?

Which LDAP servers support the “Who am I?” extended operation?

The extended “Who am I?” operation, defined in RFC 4532, allows an LDAP client to retrieve the bind DN associated with the current connection.

This ext. op. can be useful in situations where an authenticated (via bind) LDAP connection is shared by several clients: the client that issued the authentication request would certainly know the bind DN, but the other clients may not – the “Who am I?” mechanism provides them with a mean to find out the user’s identity.

The “Who am I?” RFC was published in June 2006. As of 2010 the following popular LDAP v3 compatible servers claim support for it:

  • Active Directory from Microsoft, starting from Windows Server 2008, in the format DOMAIN/user
  • Novell eDirectory
  • OpenDS
  • OpenLDAP
  • Sun Directory Server

13-те принципа при упражняване на Тайдзи-цюан

  1. Отпуснете раменете, отпуснете и ръцете в лактите.
  2. Приберете гръдния кош и повдигнете гърба.
  3. Оставете ци да потъне към Тан-тиен.
  4. Енергията на върха на главата трябва да е лека и чувствителна.
  5. Отпуснете кръста и бедрата.
  6. Разграничавайте “пълно” и “празно”.
  7. Координирайте горната и долната части на тялото.
  8. Използвайте ум, а не сила.
  9. “Вътрешното” и “външното” трябва да бъдат в хармония.
  10. Свържете съзнанието с ци.
  11. Търсете покоя в процеса на движението.
  12. Обединявайте движението с покоя.
  13. Всяка поза да бъде равномерна и в съответствие с изискванията.

Json2Ldap 1.3.1 – The LDAP gateway/proxy receives a minor config file bugfix

Json2Ldap iconJson2Ldap received a small bug fix earlier this week, after Ludovic Poitou, of the OpenDS project, reported an XML parse error during deployment onto GlassFish 3.0.1. Judging by the nature of the error messages I suspected the problem was in the Json2Ldap config file. I decided to reproduce the situation myself, and indeed, the J2EE server complained about the position of the <description> and <url-pattern> tags within the WEB-INF/web.xml file. Apparently GlassFish is being stricter about the expected XML element ordering, compared to Apache Tomcat, my test server for Json2Ldap, which never showed such parse problems.

I rearranged the tags according to the DTD’s and reran the tests with GlassFish. Json2Ldap installed and ran fine this time. This brings the current stable version to 1.3.1.

In July I’m planning to continue work with an IdM solution based on Json2Ldap. The ability to turn the back-end directory into a friendly web service makes for some very efficient ways to share user data in a SSO situation. This looks like an interesting topic to write about in future.

The JSON RPC 2.0 client receives a minor update

JsonRpc2 Console ClientYesterday I released an update to the JSON-RPC 2.0 console client, under version 1.3.

I created this tool in 2009 to quickly test and debug JSON-RPC 2.0 web services from my Linux console. At that time I was developing the web service component of MyTransactionCenter, which had a JSON-RPC interface. Later I used the tool during the programming of the Json2Ldap gateway/proxy and now I’m planning to use it again in the upcoming JsonSSO project. So I’ve been using the software more or less on a daily basis.

The JSON-RPC 2.0 console client is shipped as a Java application. You launch it from the command line by specifying the URL of the remote JSON-RPC service (it must support the 2.0 version of the protocol!). Once the connection is established, an interactive command session is opened where you can enter your requests and then see the resulting responses from the JSON-RPC server.

Here is an example Json2Ldap session (the clever -a 1 command line switch sets a default ID of 1 for each outgoing request to save you typing) :

> java -jar jsonrpc2client.jar -a 1 http://localhost:8080/json2ldap/
*** Simple interactive JSON-RPC 2.0 console client ***
*** Copyright (c) Vladimir Dzhuvinov, 2009 - 2010  ***

        1. Example request with positional parameters and an ID of zero:
                addNumbers [10,20] 0
        2. Example request with named parameters and an ID of one:
                divideNumbers {"dividend":27,"divisor":3} 1
        3. Example notification with no parameters: 
        4. To avoid typing request ID's repeatedly invoke the program with
           the -a/--auto-id option and specify a default ID value
        5. Press [Ctrl] + [C] to exit

JSON-RPC 2.0 > ldap.connect {"host":"localhost", "port":1389}
JSON-RPC 2.0 > ldap.getEntry {"CID":"-46c531689feee1d7e864514dfebbcdff", "DN":"uid=user.100,ou=People,dc=example,dc=com", "attributes":"street telephoneNumber"}
{"telephoneNumber":["+1 360 654 0292"],"street":["26630 Lincoln Street"]}
JSON-RPC 2.0 > 

So what has changed in version 1.3 of JsonRpc2-Client?

  • The client has a routine that checks the HTTP Content-type header of the server response. If the value is not of MIME type “application/json-rpc” or “application-json” the client displays an error message. Up to version 1.2 there was a bug that prevented the correct detection of the MIME type if a character encoding is also specified in the same field. This is fixed now.
  • The client uses the JsonRpc2-Base library to process the JSON-RPC 2.0 messages. With this release the included library has been updated to its latests version 1.9.1.

The JSON-RPC 2.0 console client is available for a small fee, the source code is also included if you need to make some modifications. Get in touch with me if you have any suggestions or feedback.

Json2Ldap 1.3 – If you can’t document it – leave it out!

Json2Ldap iconAs I was updating the manual for the 1.2 release of Json2Ldap I got stuck on the ldap.presetBind section. Explaining the preset bind feature in a clear and concise way, particularly how to configure it properly due to its various security implications – that turned out to be quite a puzzle. And if I, as the developer of Json2Ldap, supposedly knowing the product inside-out, find it hard to internalise the feature, then how about the poor users?

In the end I decided to spare myself (and my users) this trouble and removed the preset bind command from Json2Ldap.

The corollary:

If you can’t document a feature in a clear and concise way – then it should be better left out!

The simplified, sans ldap.presetBind Json2Ldap gateway/proxy is now available as version 1.3.

Ритмология в Пловдив

Ритмология, за пръв път тук в Пловдив

Яко, първично, изпълващо, разтрисащо, върховно, енергизиращо – всичко това, и още повече даже, беше Ритмология днес!

Браво на Мартин Иванов, дай Боже повече извънземни като него на нашата малка планета; благодарности и на всички други замесени лица 🙂

И така, очакваме следващото издание. А ритъмът, той е във всички нас, на едно съвсем интуитивно и достъпно ниво!

Json2Ldap 1.2 with overhauled configuration

Json2Ldap iconJson2Ldap, 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!

Json2Ldap soon with bind DN quotas

Json2Ldap iconSince its first release Json2Ldap has allowed administrators to control LDAP connection count by specifying a certain limit per client IP address. To do this one has to set the json2ldap. clients. connectionQuotaPerIP configuration parameter. Once the connection limit for a particular IP is reached, no further LDAP connections are allowed from this address until an existing one is closed or expires.

This measure works well for anonymous LDAP connections. The new 1.2 release of Json2Ldap will include an additional quota mechanism which enables administrators to set LDAP connection quotas per bound DN. This slightly more advanced feature, already coded and tested out, is more suitable in cases where Json2Ldap users make mostly authenticated connections to the back-end directories (with a user DN and password).

The bind DN connection quota is set by the configuration parameter json2ldap. clients. connectionQuotaPerBindDN in the WEB-INF/web.xml file.

Here is an example illustrating how the bind DN quotas work.

First, we specify some bind DN quota value in the Json2Ldap config file, e.g. five:


Don’t forget to restart the web container in order for the new config to take effect!

Then we establish a new LDAP connection with ldap.connect and make a JSON-RPC ldap.bind request to authenticate the current LDAP connection (represented by the CID value) as originating from the user with the specified distinct name (DN) and password.

{ "method" : "ldap.bind",
  "params" : { "DN" : "uid=u001,ou=People,dc=example,dc=com",
               "password" : "secret",
               "CID" : "5288ff60f64a6a29b19e530cc4ff823f" },
  "id" : 1,
  "jsonrpc" : "2.0" }

If the bind request succeeds a JSON-RPC response indicating success is sent back to the client. The null result value here simply indicates that we have a void type RPC method.

{ "result" : null,
  "id" : 1,
  "jsonrpc" : "2.0" }

If, however, the connection limit for the above bind DN is reached, that is, there are already 5 active LDAP connections authenticated as the DN uid=u001,ou=People,dc=example,dc=com, then an -1204 JSON-RPC error will be returned:

{ "error" : { "code" : -1204,
              "message" : "Exhausted connection quota for this bind DN" },
  "id" : 1,
  "jsonrpc" : "2.0" }

The current connection will also be closed.

The bind requests for this DN will keep returning an -1204 error until one of those connections changes its bind DN (i.e. re-binds as a different or anonymous user), closes or expires.

Note that internally the bind DN quota is checked only after the user credentials are verified. This is to prevent attempts to guess whether somebody is logged onto the directory by making a false bind request with some random password.

JSON-RPC 2.0 vs 1.0

JSON-RPC 2.0Users of my Json2Ldap gateway/proxy software have noticed that its client interface is based on the latest version 2.0 of the JSON-RPC protocol (actually, the 2.0 specification proposal from 2010-03-26 which has stabilised now). Version 1.0 isn’t supported at all. Why is that and what are the advantages of JSON-RPC 2.0 over 1.0?

Version 2.0 brings a number of changes to the protocol, but its single most significant new feature, for services having the API complexity of Json2Ldap and JsonSSO, are the so-called named parameters.

The original version of JSON-RPC allows for parameter passing just like the function arguments in computer languages such as C and Java – the RPC parameters are identified by their position in the enclosing JSON array, that is we have positional parameters.

Here is one JSON-RPC 1.0 request example, notice the 3 parameters:

{ "method" : "registerUser", 
  "params" : ["uid001", "Adam Brown", "[email protected]"], 
  "id" : 0 }

Positional parameters are great for simple method signatures that include mostly mandatory parameters and API’s that are not expected to change much in future. If you, however, have methods with numerous optional parameters, or expect to support new optional parameters in future, then using positional parameters quickly becomes impractical.

Consider for example the ldap.search call of Json2Ldap. It has a fairly complex set of parameters, with 4 mandatory and 6 optional ones:

  • Mandatory parameters: CID, baseDN, scope, filter
  • Optional parameters: attributes, derefPolicy, sizeLimit, timeLimit, typesOnly, output

A method signature using positional parameters lists the mandatory first, followed by the optional ones, preferably in an order of decreasing parameter usage. An example ldap.search request, JSON-RPC 1.0 style, with mandatory parameters only:

{ "method" : "ldap.search", 
  "params" : ["26009f7f10b38b92ca0a8744b825104f", 
   "id" : 0 }

Now the same request as above, but also specifying a value for the last optional parameter (output type = LDIF). The preceding optional parameters are passed a null to leave them at their default value.

{ "method" : "ldap.search", 
  "params" : ["26009f7f10b38b92ca0a8744b825104f", 
   "id": 0 }

Having to fill in a number of nulls for each optional parameter until we got to the optional parameter that we wanted to specify is not particularly elegant, in fact it can be error prone too. While this example may be somewhat extreme the point I wanted to make should be clear now – JSON-RPC 1.0 with its positional-parameters-only model doesn’t serve well methods with multiple optional parameters.

That’s why in summer 2009 I was delighted to find out that an improved JSON-RPC standard had been in the works, called “2.0”, bringing one really neat feature – named parameters. It allows for an alternative parameter passing method where the values are packed as members of a JSON object. Order becomes irrelevant now as each parameter is specified by name.

Yes, named parameters make JSON-RPC requests more verbose, but I think this is rather good: the requests become self-describable which helps debugging, readability and even logging.

Therefore it was a straightforward decision to settle on a JSON-RPC 2.0 interface for the Json2Ldap gateway/proxy. The 2.0 draft has significantly stabilised now and I don’t expect any changes apart from minor wording corrections by the time it becomes “official”.

Here is a repeat of the above two ldap.search calls to Json2Ldap, but using named parameters now:

{ "method" : "ldap.search", 
  "params" : {"CID":"26009f7f10b38b92ca0a8744b825104f", 
   "id" : 0,
   "jsonrpc" : "2.0" }

And the request with the optional “output” parameter:

{ "method" : "ldap.search", 
  "params" : {"CID":"26009f7f10b38b92ca0a8744b825104f", 
   "id" : 0,
   "jsonrpc" : "2.0" }

Yes, the JSON-RPC requests look neater now with named parameters!. And as I mentioned before, readability is top too!

The JSON-RPC 2.0 improvements are not limited to adding named parameter support. The protocol was streamlined by removing some transport dependencies and specification redundancies. Also, the error reporting of common conditions (parse error, etc.) was standardised. All this makes JSON-RPC 2.0 a highly attractive choice for lightweight web communications.

PS: For my JSON-RPC 2.0 based projects I have developed my own Java implementation, called JsonRpc2 Base. It can be used both on the server and client sides and is deliberately kept as simple and minimal as possible (no frameworks, batching left out). While the software is not exactly free, its price is also minimal. The package comes with generous license terms, full source code and carefully written documentation. JsonRpc2 Base has been through a number of refinements and its current version is 1.9.1.