How to store simple name value pairs in an ldap directory

Question

I'm creating a user repository ldap backend for a series of web applications sharing the same users. I would like to store preference information in this ldap location. This way everything related to users is maintained in the same place and can be shared among all applications.

I'm thinking of a general structure like this:

ou=People,dc=domain,dc=com
  uid=jdoe,ou=People,dc=domain,dc=com
    ou=Preferences,uid=jdoe,dc=domain,dc=com
      ou=firstpreference,ou=Preferences,uid=jdoe,dc=domain,dc=com
        value : 123
        value : 456

I have several questions:

1. Is jsut below the user entry the right place to start storing the preferences? What objectClass should this entry be? I'm experimenting with organizationalUnit but it doesn't seem right.

2. What is the best way to store name value pairs for the preferences? Here my best guest is to create an entry just below the preferences having a name and create the value just under it. This way I can account for multiple values. What should be the correct objectClass for those entries?

I'm working with OpenLDAP and wouldn't like to change the schemas that come with it. Is there a way to set this up using available schemas?

Answer 1

1. You can certainly store preferences as children of the user node. Alternatives would be on the user node itself or in a completely separate branch. Depends on how you will be maintaining it (who will have permissions, how granular the permissions are, how often new preferences and applications will be added, etc).

   OU is the wrong object type. You should define your own schema to suit your application. Generally you want to keep schema changes to a minimum, so the schema you define should be designed to be extensible when new preferences / apps are needed.

2. You can either define an attribute for each preference and use the LDAP server's inbuilt name-value pair support. Or you can define a generic 'preferences' attribute and store the name and value in the data. Again, how you do it depends how many preferences there are, frequency of changes, ability to search and index fields, etc.

There's nothing to stop you using inbuilt types for everything. Just like there is nothing to stop you calling all your variables v1, v2 and your files stuff.txt. But when there aren't any inbuilt types that match your needs, this is the time to add your own. It's a pretty simple thing to do.