##### General Information

- Overview
- Features
- Specification
- Getting Started
- Howto Build Turbine
- Changes

##### Documentation

- Services
- Howtos
- Wiki
- JavaDocs

##### Development

- Proposals
- How To Help
- Todo

##### Project Documentation

- Project Information
- Project Reports

##### Apache

- Apache Website
- License
- How the ASF works
- Sponsorship
- Thanks
- Security

## 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 atributes, 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 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.

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.