Information Technology Reference
In-Depth Information
Separating Church and State - The Roles of Directory and
Database
If you follow no other recommendation in this document but this one, you
will still save yourself hundreds of thousands of dollars of unnecessary
effort. It is simply this - split your user data into an LDAP-based directory
and a relational database, with only authentication credentials in the
directory and everything else in the database. There were many occasions
when we had to implement a new feature and thought to ourselves, “Thank
goodness we chose to split the user data!” This is such a fundamental design
characteristic of a flexible IAM.
A directory server is a strange beast. It evolved at a time when relational
databases were being tuned for mixed read-update loads and were not fast
enough for read-mostly use cases. Directories emerged to cater to this need.
Directory servers were very fast on reads but very slow on updates. This was
OK for situations that required lookups much more frequently than updates.
However, in recent times, relational databases have become extremely fast
for any kind of load, so performance is no longer a differentiator. On the
contrary, the tree structure of a directory is needlessly constraining when
you have to model all sorts of complex data relationships. Many data
elements in an IAM have a many-to-many relationship
34
, and directories
simply suck at modelling anything but one -to-one and one -to-many
relationships. For example, if you're trying to put user role information into a
directory, be warned that you're stepping into quicksand. You will be tearing
your hair out very soon. Relational databases are a much better fit for all
such information.
You may wonder then why we don't put all our data into a relational
database. Is a directory useful at all any more? The short answer is yes.
Directories still do certain things extremely well:
They are good at storing passwords in a secure encrypted form and
performing password validations internally with a single operation.
Implementing this functionality in a generic relational database will
require the application to perform encryption and/or decryption in
memory and perform retrievals and comparisons as separate
operations. Subsequent functions like recording the number of failed
34
Association tables are usually employed to split many-to-many relationships into
two one-to-many relationships back-to-back, but they're still hard to fit into a tree-
structured data store.
