The Blog of Vladimir Dzhuvinov – Page 10 – Блог на Владимир Джувинов

Seatpost wisdom

Always choose the longer postpost

… particularly if you’re getting a new bike frame.

But why would you need a new one?

Because bike manufacturers have gone overboard with sizes and today when you buy a new frame it’s very likely it would have its own seatpost diameter. A quick wikipedia check shows how many “standard” diameters are in existence today. Hold your breath:

22.0, 22.2, 23.4, 23.8, 24.0, 25.0, 25.4, 25.8, 26.0, 26.2, 26.4, 26.6, 26.8, 27.0, 27.2, 27.4, 27.8, 28.0, 28.6, 29.4, 29.6, 29.8, 30.0, 30.4, 30.8, 30.9, 31.4, 31.6, 31.8, 32

Something like 30 if you bother to count them.

First look at JsonSSO

Earlier in August I began work on JsonSSO, a web service that provides single sign-on and session management. It naturally complements Json2Ldap, another product of mine which provides web-friendly JSON-RPC access to LDAP v3 compatible directories such as OpenLDAP, MS AD and Novell eDirectory.

The recent years we saw a proliferation of single sign-on (SSO) solutions. While the underlying concept of SSO is relatively simple, the IT context (participating apps, authentication methods, back-ends, platforms, policy, etc.) can vary significantly, which has prompted the development of so many implementations.

JsonSSO has three defining features:

User authentication is done against a back-end LDAP directory via Json2Ldap.
Once a user session is established, participating web clients may be given an open LDAP connection (by means of Json2Ldap) bound as the currently logged-in user. This connection allows web clients convenient and flexible access to user details such as user ID, name, email, photo, application preferences, etc.
An internal database records the details of all active and expired user sessions. It can be queried for audit and management purposes via a JSON-RPC interface.

For JsonSSO to be easy to understand and work with I intend to stick to these three main features. Diversions, such as adding DB-based authentication, will be avoided. I want to have JsonSSO as web-friendly as possible, keeping all incoming (from clients) and outgoing (to back-end) connections in the form of HTTP.

Here is a preliminary overview of the JsonSSO API and its configuration settings. These may change somewhat by the time JsonSSO is officially released (Q4 2010).

JSON-RPC 2.0 API

sso.login Initial login with an authenticating ID (username, email, etc.) and password. Returns a new session identifier (SID) which can be passed between the participating web clients and apps.
sso.logout Closes a user session. Can be invoked by any of the participating web clients and apps that holding the corresponding SID.

sso.getUserID By passing a valid SID, clients can get the user’s system/org-wide ID.
sso.getUserDN By passing a valid SID, clients can get the distinct name (DN) of the user, i.e. their directory record.

sso.getJson2LdapURL Returns the URL of the Json2Ldap web service.
sso.getAnonymousLdapConnection Returns an anonymous LDAP connection (via Json2Ldap) to the back-end directory (if permitted by config).
sso.getBoundLdapConnection Returns an LDAP connection (via Json2Ldap) bound as the currently logged-in user (if permitted by config and the web client/app has authorisation).

sso.refresh Allows clients/apps to extend a user session by presenting its SID, otherwise it would eventually expire after a preconfigured idle time.
sso.getSessionSettings Returns the max idle time, max duration and other settings for a session represented by a given SID.

sso.registerLogoutCallback Allows participating web apps to receive a notification that the user has logged out and the session has ended.
sso.unregisterLogoutCallback Allows to cancel a previously registered logout notification.
sso.listRegisteredCallbacks Lists all web apps that have requested to receive a logout notification.

sso.listSessions Lists the details of current or expired sessions. Regular users can only access their own session history. Administrators have full access.

ws.getName Returns the web service name.
ws.getVersion Returns the web service version.
ws.getTime Returns the local web service time.

JsonSSO configuration parameters

This set of parameters governs web client/app access to the JsonSSO service:

jsonsso.clients.requireHttps
jsonsso.clients.returnAnonymousLdapConnection
jsonsso.clients.returnBoundLdapConnection
jsonsso.clients.allowLogoutCallbacks

User session limits:

jsonsso.sessions.maxTime
jsonsso.sessions.maxIdleTime
jsonsso.sessions.quotaPerUser
jsonsso.sessions.onQuotaExhaustion

Specifies the Json2Ldap URL through which the back-end LDAP directory will be accessed:

jsonsso.json2ldap.url
jsonsso.json2ldap.trustSelfSignedCerts

Specifies the server details of the back-end LDAP directory. If the useDefault parameter is true JsonSSO will use the default LDAP server for the configured Json2Ldap gateway/proxy.

jsonsso.ldapServer.useDefault
jsonsso.ldapServer.host
jsonsso.ldapServer.port
jsonsso.ldapServer.timeout
jsonsso.ldapServer.security
jsonsso.ldapServer.trustSelfSignedCerts

The uidAttribute parameter specifies the name of the LDAP attribute that holds the system/org-wide user IDs (typically userid but may be something else). If set, the groupDn parameter governs which users are allowed to login via JsonSSO.

jsonsso.users.uidAttribute
jsonsso.users.groupDn

This set of parameters determines how to derive the user directory record (DN) from the username or email entered at login:

jsonsso.dnResolution.method
jsonsso.dnResolution.dnTemplate
jsonsso.dnResolution.searchFilter
jsonsso.dnResolution.searchBaseDn
jsonsso.dnResolution.searchUserDn
jsonsso.dnResolution.searchUserPassword

This set of parameters determine which users have admin access to the session logs:

jsonsso.admin.dn
jsonsso.admin.groupDn

Със Салса Буда на Водната планина

С Илиан от пловдивската Salsa de Cuba си направихме епичен поход из “Водната планина” или както траките са наричали Рила. Маршрутът ни мина през стръмните зъбери на Мальовица, после по билото до хижа Иван Вазов, след което се спуснахме и до Седемте рилски езера.

Там където водата и планината докосват толкова високо небето, там спокойствието и усещането за чистота са наистина невероятни!

LDAP web service software updated

Json2Ldap 1.4, released yesterday, simplifies its JSON-RPC 2.0 API to become an even friendlier web service for working with LDAP compatible back-end directories.

The calls to make plain, secure and default LDAP connections are now merged into a single RPC method named ldap.connect.

To make a connection to the default LDAP server (specified in the Json2Ldap configuration file by the admin) just send an ldap.connect request with no parameters:

{ "id" : 1,
  "method" : "ldap.connect",
  "jsonrpc" : "2.0"
}

To make a plain LDAP connection to a particular directory server specify its host and port:

{ "id" : 1,
  "method" : "ldap.connect",
  "params" : { "port" : 1389, "host" : "dir.example.com" },
  "jsonrpc" : "2.0"
}

To make a secure (encrypted) connection, set the optional security parameter to StartTLS or SSL. You may also set the optional trustSelfSignedCerts parameter:

{ "id" : 1,
  "method" : "ldap.connect",
  "params" : { "host" : "192.168.0.1", 
               "port" : 1389, 
               "security" : "StartTLS",  
               "trustSelfSignedCerts" : true },
  "jsonrpc":"2.0"
}

The full description of the ldap.connect JSON-RPC call is available in the online API docs.

Json2Ldap gets mentioned in Network World

Thanks 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-те принципа при упражняване на Тайдзи-цюан

Отпуснете раменете, отпуснете и ръцете в лактите.
Приберете гръдния кош и повдигнете гърба.
Оставете ци да потъне към Тан-тиен.
Енергията на върха на главата трябва да е лека и чувствителна.
Отпуснете кръста и бедрата.
Разграничавайте “пълно” и “празно”.
Координирайте горната и долната части на тялото.
Използвайте ум, а не сила.
“Вътрешното” и “външното” трябва да бъдат в хармония.
Свържете съзнанието с ци.
Търсете покоя в процеса на движението.
Обединявайте движението с покоя.
Всяка поза да бъде равномерна и в съответствие с изискванията.

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

Json2Ldap 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

Yesterday 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  ***

Hints: 
        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: 
                notifyIdleState
        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}
-46c531689feee1d7e864514dfebbcdff
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!

As 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.