xdocs/howto/ldap-howto.xml (152 lines of code) (raw):
<?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>