LDAP Details

These are the details on how we came up with this schema for putting the user-group-permission tables in an LDAP directory. We want to start with the fact that for the schema proposed we have taken all new objectClasses and Attributes preceded by turbine to indicate that they are Turbine specific. We have thought about using the standard and available LDAP objectClasses and attributes, but finally decided to start the discussion with the turbine stuff.

We also had to make some assumptions regarding the present use of the user-group-permission tables. This gave us the following schema:

Schema

-- Attribute types --

( 1000.1.1
  NAME 'turbineGroupMember'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)

( 1000.1.2
  NAME 'turbineObjectData'
  DESC ''
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
)

( 1000.1.3
  NAME 'turbinePermission'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)

( 1000.1.4
  NAME 'turbineRoleMember'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
)

( 1000.1.5
  NAME 'turbineUserCreationDate'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.53
  SINGLE-VALUE
)

( 1000.1.6
  NAME 'turbineUserFirstName'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)

( 1000.1.7
  NAME 'turbineUserLastLogon'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.53
  SINGLE-VALUE
)

( 1000.1.8
  NAME 'turbineUserLastModifiedTime'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.53
  SINGLE-VALUE
)

( 1000.1.9
  NAME 'turbineUserLastName'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)

( 1000.1.10
  NAME 'turbineUserMailAddress'
  DESC ''
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
)

( 1000.1.11
  NAME 'turbineUserPassword'
  DESC ''
  EQUALITY caseExactMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE
)

( 1000.1.12
  NAME 'turbineUserUniqueId'
  DESC ''
  EQUALITY caseIgnoreMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE
)
-- Object classes --

( 1000.2.1
  NAME 'turbineGroup'
  DESC 'Turbine group'
  SUP top
  AUXILIARY
  MAY ( turbineGroupMember $ turbineObjectData )
)

( 1000.2.2
  NAME 'turbineRole'
  DESC 'Turbine role'
  SUP top
  AUXILIARY
  MAY ( turbineObjectData $ turbinePermission $ turbineRoleMember )
)

( 1000.2.3
  NAME 'turbineUser'
  DESC 'Turbine user'
  SUP top
  AUXILIARY
  MUST ( turbineUserUniqueId )
  MAY ( turbineObjectData $ turbineUserCreationDate $ turbineUserFirstName $
turbineUserLastLogon $ turbineUserLastModifiedTime $ turbineUserLastName $
turbineUserMailAddress $ turbineUserPassword )
)

More Details

We have turbineRole that can have many turbinePermission entries. These are DN pointing to the turbinePermission objects. turbineUser will hold all user related information. turbineGroup can hold in the turbineGroupMember DNs of turbineUser objects. Thus having multiple users being member of a group. There is however no relation with role at this stage. The relation role - user is stored in the turbineRole having multiple DNs in turbineRoleMember. Then we have a user - role relation thus giving user permission via roles they can perform. There is no relation between role - user - group in one record. This could be possible with the DB model, but we could you put this dependency in the hierarchical structure of a directory. With the separate user - role and user - group relations we thought we'd have the most desired relations.

Please note that the Object Identifiers (OID) in this example are not real ones. When we go for the turbine objectClasses and attributes Turbine (or Apache) have to register (if they not already have) their own OID starting point in the IANA tree. We are fully open for discussion and appreciate your feedback on the mailing list.