Hi Guys, Colin Chalmers already sent this schema to Jason directly but I wanted to give you guys some more details on how we came up with this schema for putting the user-group-permission tables in an LDAP directory. I 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: -- 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 ) ) 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. Regards, Walter, Colin and Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
