| LDAP Schema Design - a Case study | Home | |
|
LDAP Schema Design - case study ABSTRACTThis document describes about the design of LDAP schema by taking a case study. Explains about LDAP, object class, attributes and a case study with college administration information. Case study mentioned in this document is tested in OpenLDAP ver 2.0.18 stable version. SCOPEScope of this document is limited to explaining how to design LDAP schema with a case study. This document expects users with basic knowledge of LDAP. For more information about LDAP please refer www.openldap.org INTRODUCTIONWhat is LDAP?LDAP stands for Lightweight Directory Access Protocol. This is a lightweight protocol for accessing directory services. This runs over TCP/IP or connection oriented transfer services. The LDAP model is based on entries. Entry will have set of attributes. It will be uniquely identified by Distinguished Name (DN). Attribute can have multiple values also. Entry can be numeric, string, binary etc.. The arrangement of the LDAP is like hierarchical tree. Each node in a tree should be uniquely identified with DN. Entry will have objectclass which describes the attributes of object classes and it can have multiple objectclasses. Following are the steps for defining new schema:
Object IdentifiersEach schema element is identified by a globally unique
You are, of course, free to design a hierarchy suitable to your organizational needs under your organization's OID. No matter what hierarchy you choose, you should maintain a registry of assignments you make. For more information about Object Identifiers (and a listing service) see http://www.alvestrand.no/harald/objectid/. Under no circumstances should you hijack OID namespace! To obtain a registered OID at no cost, apply for an OID under the Internet Assigned Numbers Authority (IANA) maintained Private Enterprise arc. Any private enterprise (organization) may request an OID to be assigned under this arc. Just fill out the IANA form at http://www.iana.org/cgi-bin/enterprise.pl and your official OID will be sent to you usually within a few days. Your base OID will be something like 1.3.6.1.4.1.X where X is an integer. Note: Don't let the "MIB/SNMP" statement on the IANA page confuse you. OIDs obtained using this form may be used for any purpose including identifying LDAP schema elements. Alternatively, OID name space may be available from a national authority (e.g., ANSI, BSI). For private experiments, OIDs under 1.1 may be used. The OID 1.1 arc is regarded as dead name space. Attribute Type SpecificationThe attributetype directive is used to define a new attribute type. The directive uses the same Attribute Type Description used by the attributeTypes attribute found in the subschema subentry, e.g.: attributetype <Attribute Type Description> where Attribute Type Description is defined by the following
AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other
; AttributeType
[ "EQUALITY" woid ; Matching Rule name
[ "ORDERING" woid ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; Syntax OID
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ]; default user modifiable
[ "USAGE" whsp AttributeUsage ]; default userApplications
whsp ")"
AttributeUsage =
"userApplications" /
"directoryOperation" /
"distributedOperation" / ; DSA-shared
"dSAOperation" ; DSA-specific, value depends on server
where whsp is a space (' '), numericoid is a globally unique OID in dotted-decimal form (e.g. 1.1.0), qdescrs is one or more names, woid is either the name or OID optionally followed by a length specifier (e.g {10}). For example, the attribute types name and cn are defined in core.schema as: attributeType ( 2.5.4.41 NAME 'name'
DESC 'name(s) associated with the object'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
attributeType ( 2.5.4.3 NAME ( 'cn' $ 'commonName' )
DESC 'common name(s) assciated with the object'
SUP name )
Notice that each defines the attribute's OID, provides a short name, and a brief description. Each name is an alias for the OID. slapd(8) returns the first listed name when returning results. The first attribute, name, holds values of directoryString (UTF-8 encoded Unicode) syntax. The syntax is specified by OID (1.3.6.1.4.1.1466.115.121.1.15 identifies the directoryString syntax). A length recommendation of 32768 is specified. Servers should support values of this length, but may support longer values The field does NOT specify a size constraint, so is ignored on servers (such as slapd) which don't impose such size limits. In addition, the equality and substring matching uses case ignore rules. Below are tables listing commonly used syntax and matching rules.
The second attribute, cn, is a subtype of name hence it inherits the syntax, matching rules, and usage of name. commonName is an alternative name. Neither attribute is restricted to a single value. Both are meant for usage by user applications. Neither is obsolete nor collective. Object Class SpecificationThe objectclasses directive is used to define a new object class. The directive uses the same Object Class Description used by the objectClasses attribute found in the subschema subentry, e.g.: objectclass <Object Class Description> where Object Class Description is defined by the following
ObjectClassDescription = "(" whsp
numericoid whsp ; ObjectClass identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ] ; Superior ObjectClasses
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
; default structural
[ "MUST" oids ] ; AttributeTypes
[ "MAY" oids ] ; AttributeTypes
whsp ")"
where whsp is a space (' '), numericoid is a globally unique OID in numeric form (e.g. 1.1.0), qdescrs is one or more names, and oids is one or more names and/or OIDs.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LDIF FormatThe
The basic form of an entry is: # comment
dn: <distinguished name>
<attrdesc>: <attrvalue>
<attrdesc>: <attrvalue>
...
Lines starting with a '#' character are comments. An attribute
description may be a simple attribute type like cn or objectClass
or 1.2.3 (an
A line may be continued by starting the next line with a single space or tab character. For example: dn: branch=Electronics Communication,dept=Civil,o=
college
branch: Electronics
Communication
is equivalent to: dn: branch=Electronics Communication,dept=Civil,o=college
branch: Electronics Communication
Multiple attribute values are specified on separate lines. e.g., BoardMember: abc BoardMember: cde If an <attrvalue> contains non-printing characters or begins with a space, a colon (':'),
or a less than ('<'), the <attrdesc> is followed by a double colon and the base64 encoding
of the value. For example, the value " begins with a space" would be encoded like this:
cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U= You can also specify a
cn:< file:///path/to/file.jpeg Multiple entries within the same LDIF file are separated by blank lines. Here's an example of an LDIF file containing three entries. # Barbara's Entry
dn: cn=Barbara J Jensen,dc=example,dc=com
cn: Barbara J Jensen
cn: Babs Jensen
objectClass: person
sn: Jensen
# Bjorn's Entry
dn: cn=Bjorn J Jensen,dc=example,dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectClass: person
sn: Jensen
# Base64 encoded JPEG photo
jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
# Jennifer's Entry
dn: cn=Jennifer J Jensen,dc=example,dc=com
cn: Jennifer J Jensen
cn: Jennifer Jensen
objectClass: person
sn: Jensen
# JPEG photo from file
jpegPhoto:< file:///path/to/file.jpeg
Notice that the jpegPhoto in Bjorn's entry is base 64 encoded and the jpegPhoto in Jennifer's entry is obtained from the location indicated by the URL. Note: Trailing spaces are not trimmed from values in an LDIF file. Nor are multiple internal spaces compressed. If you don't want them in your data, don't put them there.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The top node is college with unique DN as o=college. College will have different departments like Civil, Electronics, Mechanical etc.. The number of child nodes depends on the number of departments in the college. Let us take, college has two departments Civil and Electronics. Then the o=college parent node will have two child nodes deptName=Civil and deptName=Electronics. Each node can be identified as deptName=Civil,o=college and deptName=Electronics,o=college. If searched with DN deptName=Electronics,o=college, attributes at this entry will be retrieved. The subtree is
o=college Consider the department Electronics has three branches ECE, EEE & CSE. The DN
for each branch will be
branchName=ECE,deptName=Electronics,o=college, Now take the branch ECE, each branch will have students and staff. Each
student belongs to a particular year and each staff belongs to either teaching
or non-teaching staff. So consider the sub tree under the dn
branchName=ECE,deptName=Electronics,o=college is Each academicYear consists of students and each student will be studying the subjects, each staff will have salary details and subjects he/she is handling. The subtrees for academicYear, teaching and nonteaching are
ademicYear=1999-2000 ou=teaching
ou=nonteaching COLLEGE LDAP Tree
o=college AttributesThis section contains attribute file for College LDAP tree attributetype ( 1.3.6.1.4.1.2.1 NAME 'collegeName' Object classThis section gives objectclass details for College LDAP
tree. Sample LDIF FileThis section gives sample ldif file for creating LDAP tree, dn: o=college dn: deptName=Civil,o=college dn: deptName=Electronics,o=college dn: branchName=ECE,deptName=Electronics,o=college dn: ou=student,branchName=ECE, deptName=Electronics,o=college dn: ou=staff,branchName=ECE, deptName=Electronics,o=college dn: academicYear=1999-2000,ou=student,branchName=ECE,
deptName=Electronics,o=college dn: academicYear=2000-2001,ou=student,branchName=ECE,
deptName=Electronics,o=college dn: studentNumber=100,academicYear=1999-2000,ou=student,branchName=ECE,
deptName=Electronics,o=college dn: studentNumber=101,academicYear=1999-2000,ou=student,branchName=ECE,
deptName=Electronics,o=college dn: subjectCode=001,studentNumber=101,academicYear=1999-2000,ou=student,branchName=ECE,
deptName=Electronics,o=college dn: subjectCode=002,studentNumber=101,academicYear=1999-2000,ou=student,branchName=ECE,
deptName=Electronics,o=college dn: ou=teaching,ou=staff,branchName=ECE, deptName=Electronics,o=college dn: ou=nonteaching,ou=staff,branchName=ECE, deptName=Electronics,o=college dn: staffID=001,ou=teaching,ou=staff,branchName=ECE,
deptName=Electronics,o=college staffAddress: sdflasjflasd dn: staffID=002,ou=teaching,ou=staff,branchName=ECE,
deptName=Electronics,o=college dn: staffID=101,ou=nonteaching,ou=staff,branchName=ECE,
deptName=Electronics,o=college dn: staffID=102,ou=nonteaching,ou=staff,branchName=ECE,
deptName=Electronics,o=college dn: ou=Salary Details,staffID=002,ou=teaching,ou=staff,branchName=ECE,
deptName=Electronics,o=college dn: subjectCode=001,staffID=002,ou=teaching,ou=staff,branchName=ECE,
deptName=Electronics,o=college dn: ou=Salary Details,staffID=102,ou=nonteaching,ou=staff,branchName=ECE,
deptName=Electronics,o=college CONCLUSIONCopy the ldap object class file and ldap attribute file and run LDAP server. Add the ldif file into LDAP server and check the LDAP tree. Above files are tested using OpenLDAP v2.0.18 stable version. This is only an approach for designing LDAP schema. This can be tuned/modified to requirements of a college. REFERENCES[1] www.openldap.org describes about OpenSource LDAP(OpenLDAP) ACRONYMSLDAP
Lightweight Directory Access Protocol |
Copyright (C), All rights reserved-2008
No warranty or guarantee not limited to these are provided with above free
software. Send your comments or feedback
to
feedback@prasannatech.com. For
advertising contact
advertise@prasannatech.com
