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 22.214.171.124.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 126.96.36.199.4.1.14188.8.131.52.15.
ldapSyntaxes: ( 184.108.40.206.4.1.4401.1.1.1 DESC ‘URI’ X-SUBST ‘220.127.116.11.4.1.1418.104.22.168.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).