Title: Introduction to LDAP
Course: RHEA Provider Registry > Section: Introduction to LDAP

LDAP and the Provider Registry User Interface

Data on the providers and their postings are stored in LDAP.

The Provider Registry user interface know how to read data from LDAP as well as MySQL.

The reports in the provider registry are run in MySQL

In order to run reports, data from the provider registry is stored in a cache table.

LDAP Schema

LDAP Schema defines data structure for data stored in LDAP server.

Data structures are more like objects in programming.

To define an data structure you define objectclass

An object class has a list of attributes

Provider Post Object Class Defintion

The proverPerson object class has the following below.

We need to name the object class and provider a unique numeric ID.


objectclass ( 2.25.128424792425578037463837247958458780699.1
    NAME 'providerPerson'
    DESC 'providerPerson'
    SUP inetOrgPerson
    STRUCTURAL
    MUST  ( nid  )
    MAY  ( dateOfBirth $ mutuelle $ csr $ passport $ countryName   $ locationCode )   )

Provider Person Object Class Defined Attributes

The providerPerson objectclass defines one required attribute: nid.

The providerPerson objectclass defines several optional attributes: dateOfBirth, mutuelle, case, paspport....


objectclass ( 2.25.128424792425578037463837247958458780699.1
    NAME 'providerPerson'
    DESC 'providerPerson'
    SUP inetOrgPerson
    STRUCTURAL
    MUST  ( nid  )
    MAY  ( dateOfBirth $ mutuelle $ csr $ passport $ countryName $ friendlyCountryName  $ locationCode )   )

Provider Person Inherited Attributes

The providerPerson objectclass inherits the defintion of its superior (parent) objectClass, the inetOrgPerson

The inetOrgPerson objectclass in turn inherits the defintion of its superior (parent) objectClass, the organizationalPerson

The organizationalPerson objectclass in turn inherits the defintion of its superior (parent) objectClass, the person

The person objectclass has required attributes sn for surname, and cn form commonname.


objectclass ( 2.25.128424792425578037463837247958458780699.1
    NAME 'providerPerson'
    DESC 'providerPerson'
    SUP inetOrgPerson
    STRUCTURAL
    MUST  ( nid  )
    MAY  ( dateOfBirth $ mutuelle $ csr $ passport $ countryName $ friendlyCountryName  $ locationCode )   )



objectclass     ( 2.16.840.1.113730.3.2.2
    NAME 'inetOrgPerson'
        DESC 'RFC2798: Internet Organizational Person'
    SUP organizationalPerson
    STRUCTURAL
        MAY (
                audio $ businessCategory $ carLicense $ departmentNumber $
                displayName $ employeeNumber $ employeeType $ givenName $
                homePhone $ homePostalAddress $ initials $ jpegPhoto $
                labeledURI $ mail $ manager $ mobile $ o $ pager $
                photo $ roomNumber $ secretary $ uid $ userCertificate $
                x500uniqueIdentifier $ preferredLanguage $
                userSMIMECertificate $ userPKCS12 )
        )

objectclass ( 2.5.6.7 NAME 'organizationalPerson'
        DESC 'RFC2256: an organizational person'
        SUP person STRUCTURAL
        MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $
                preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
                telephoneNumber $ internationaliSDNNumber $
                facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
                postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )



objectclass ( 2.5.6.6 NAME 'person'
        DESC 'RFC2256: a person'
        SUP top STRUCTURAL
        MUST ( sn $ cn )
        MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Provider Person and Post Example Record

Records for LDAP are stored in the LDIF file format where records are seperated by lines.

In the example record below, exported from HRHIS, we have a provierPerson and a providerPost

All the required attributes are defined as well as some optional ones.

#iHRIS Provider Registry export for post with internal id person|127406
dn: nid=10222034995, ou=Providers, dc=moh, dc=gov, dc=rw
objectclass: providerPerson
nid: 10222034995
cn: Chibalonzi Zainda
sn: Chibalonzi Zainda
countryName: country|CD

#Most recent posting for person Chinaloniz Babwine
dn: ou=facility|372, nid=10222034995,ou=Providers, dc=moh, dc=gov, dc=rw
objectclass: providerPost
ou: facility|372
description: Katabagemu
employeeType: post_type|pps
locationCode: county|AU050204

Distinguised Names

Data in a LDAP server is stored hierarchically.

The distinguished name (dn) of an LDAP defines the path to the data.

The distinguished name is read from right to left as we go down the hierarchy.

In our providerPerson example, we have a distinguised name nid=10222034995, ou=Providers, dc=moh, dc=gov, dc=rw

This means that the provider with National ID 10222034995 sites under the node with ou=Providers, dc=moh, dc=gov, dc=rw

The post for the provider has distringuished node ou=facility|372, nid=10222034995,ou=Providers, dc=moh, dc=gov, dc=rw so that the provider's post sits underneath the provider

#iHRIS Provider Registry export for post with internal id person|127406
dn: nid=10222034995, ou=Providers, dc=moh, dc=gov, dc=rw
objectclass: providerPerson
nid: 10222034995
cn: Chibalonzi Zainda
sn: Chibalonzi Zainda
countryName: country|CD

#Most recent posting for person Chinaloniz Babwine
dn: ou=facility|372, nid=10222034995,ou=Providers, dc=moh, dc=gov, dc=rw
objectclass: providerPost
ou: facility|372
description: Katabagemu
employeeType: post_type|pps
locationCode: county|AU050204

Tree View of Distinguished Names

All providers are defined by their National ID (nid) and sit under the Provders node.

Any postings that a provider has sits underneath them as is defined by the facility code.