<?xml version="1.0"?>
<!--
 Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
-->

<document>

 <properties>
   <title>LDAP Howto</title>
 </properties>

 <body>

 <section name="LDAP Details">
  <p>
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 atributes, but finally decided to start the
discussion with the turbine stuff.
</p>
<p>
We also had to make some assumptions regarding the present use of the
user-group-permission tables. This gave us the following schema:
  </p>
 </section>
 <section name="Schema">
<source>
-- 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 )
)
</source>
 </section>
<section name="More Details">
<p>
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 releation 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 dependancy 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.
</p>
<p>
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 dicussion
and appreciate your feedback on the mailing list.
</p>
</section>
 </body>
</document>
