My colleague Warren, who I had the pleasure to work with at Sun and again with ForgeRock, has been playing with Ansible and has produced 2 roles to install OpenDJ and to configure replication. Check Warren’s blog post for the details, or go directly to the Ansible Galaxy.
In the LDAP information model, a syntax constrains the structure and format of attribute values. OpenDJ defines and implements a large number of syntaxes (you can discover them by reading the ldapSyntaxes attribute from the cn=Schema entry).
But infrequently, we receive enquiries on an obscure and non standard syntax, often in the form of “I’m having an error importing schema from this or that legacy directory server”, with an error message that ends with “No such syntax is configured for use in the Directory Server”.
As syntaxes are constraining the structure and format of attribute values, they are implemented as code, specifically Java code in OpenDJ. It’s possible to implement new syntaxes by implementing the org.opends.server.api.AttributeSyntax abstract class, and installing the classes or the JAR in OpenDJ classpath. But often, it’s easier and more convenient to define a syntax by configuration, and OpenDJ offers 3 possibilities to define new syntaxes. In term of backward compatibility, I will only focus on the 2 main ones, by substitution and by pattern (the 3rd one allows to define enumeration of values).
With OpenDJ, you can define a new syntax by configuration and delegating the contraints to an already implemented syntax. A simple example is the URI syntax (which was defined is some very old schema with the OID 126.96.36.199.4.1.4401.1.1.1). A URI is really an ASCII string, and it might be sufficient to accept attributes with URI syntax to verify that all characters are pure ASCII. The standard syntax for ASCII strings is IA5String aka 188.8.131.52.4.1.14184.108.40.206.15.
ldapSyntaxes: ( 220.127.116.11.4.1.4401.1.1.1 DESC ‘URI’ X-SUBST ’18.104.22.168.4.1.1422.214.171.124.15’ )
Insert the above line in the schema LDIF file before the attributeTypes, and you’re done.
The other option is to define the syntax as a pattern, using regular expressions. This could be better when willing to enforce additional constraints on an URI, for example, verifying that the URI is an LDAP one.
ldapSyntaxes: ( 999.999.999.1 DESC 'LDAP URI Syntax' X-PATTERN '^ldap://[-a-zA-Z0-9+&@#/%?=~_|!:,.;]*[-a-zA-Z0-9+&@#/%=~_|]' )
So the next time you are trying to import some legacy schema to the OpenDJ directory server, and you have an error due to missing syntaxes, you know what to do to quickly resolve the problem.
The date has been set, the 2014 ForgeRock summit in United States will take place on the week of June 2nd, in Phoenix AZ.
Make sure you block the date in your calendar ! I hope to see you there.
And if you’re in Europe, don’t panic ! We are also planning an EMEA summit in the fall. The date and location will be announced later.
OpenDJ, the Open source LDAP Directory service built on the Java platform, offer plenty of flexibility to administrators to setup their environment. One specific area is how to deal with multi-tenants and hosting data from different companies.
In OpenDJ, the data is organized in database backends -and there can be many database backends-, each capable of hosting many separated “Base DN”, aka naming context or suffixes (think about “dc=Coca,dc=com” and “dc=Pepsi,dc=com”).
So we are often asked the best practices around multi-tenants, and whether it’s preferable to put the baseDNs in a single backend or to separate them, each one in a separate backend ?
Before we dive in the response, it’s important to understand that a database backend is actually a whole database environment and as such the smallest unit for backup and restore procedure. And also that indexes are configured at the backend level, so all indexes configuration are identical for all base DNs in a backend.
There are several good reasons for using a backend per tenant :
- Backends can be placed in different filesystems and disks, allowing better scalability, consistent performance.
- Maintenance done on a backend does not affect the other backends and thus the other tenants. It’s also possible to define a separate recurrent backup schedule per backend.
- From a security and privacy point of view for the customer, separation of data is better. Even though ACI are meant to prevent one tenant to see the other’s data, having separated backends will also ensure that this is also the case when doing backups, exporting data to LDIF…
- Also, if there is a need to have different configuration of indexes for each tenant, because of the applications accessing the data, or because of the structure of the data itself, then they must be stored in separated backends.
All of this seems to lead to the point that each tenant should be in its own backend. Why supporting multiple base DNs in a single database backend then ? Well, when the data sets are small and consistent, from an administration point of view, it is much easier to deal with a single backend than many of them. It reduces time for configuration, monitoring of disk space and tend to optimize memory usage. It also simplifies the database cache management, as there is a cache per backend and the overall size must not exceed the JVM memory size, nor the machine’s one. As a single backend is able to scale to tens of million entries, there is no real penalty here.
As a conclusion, when deploying OpenDJ for multi-tenant services, make sure you properly evaluate your requirements for performance, security and privacy before configuring the server. But of course, you can also choose to mix backends with multiple tenants and separate backends for some larger and higher value customers (tenants).
Another year is gone, and 2014 is already well started… But it’s still time for me to send you all my best wishes for 2014.
2013 was an amazing year from a professional point of view. Let’s make sure 2014 will be even greater ! Even Mother Nature seems to want to wave a magic wand !
I heard of the Movember movement last year when my friend Pat aka @Metadaddy filled my twitter stream with his moustachy face. I quickly noticed other people growing a moustache, including the Grenoble hockey team : Les Bruleurs de Loups.
So this year, when Andrew Forrest suggested that we create a ForgeRock team for Movember, I didn’t hesitate much, joined, and recruited other coworkers for the French team. I told my wife beforehand and she was not really enthusiastic about the idea of a moustache on my face. But my middle daughter was encouraging me to participate and help improve men’s health research and awareness.
We’re reaching the end of Movember, and the moustache has grown. My wife hates it… So help me proving her that it was worth suffering and make a donation to our team.
With OpenDJ 2.6.0, we’ve introduced a new way to access your directory data, using HTTP, REST and JSon. The REST to LDAP service, available either embedded in the OpenDJ server or as a standalone web application, is designed to facilitate the work of application developers. And to demonstrate the interest and the ease of use of that service, we’ve built a sample application for Android : the OpenDJ Contact Manager
The OpenDJ Contact Manager is an open source Android application that was built by Violette, one of the ForgeRock engineer working in the OpenDJ team. You can get the source code from the SVN repository : https://svn.forgerock.org/commons/mobile/contact-manager/trunk. Mark wrote some quite complete documentation for the project, with details on how to get and build the application. He published it at http://commons.forgerock.org/mobile/contact-manager/.
The whole application is just about 4000 lines of code, and most of it is dealing with the display itself. But you can find code that deals with asynchronous calls to the OpenDJ rest interface, with paging through results, and parsing the resulting JSON stream to populate the Contacts, including photos. Et voila :
The application is just a sample but it clearly is usable in its current form and will allow once a contact was retrieved from the OpenDJ directory, to add it to the Contacts standard application, call the person, locate its address on maps, send the person an email, navigate through the management chain…
In future versions, we are planning to add support for OAuth 2.0, removing the need to store credentials in the application settings.
As it’s open source, feel free to play with it, hack and contribute back your changes.