|
|||||||
|
|
||||||||
|
||||||||
|
OM LDAP |
|
1.
Introduktion |
 |
LDAP har en objektmodell där information lagras i en hierarki där olika noder har namn och attribut. Modellen grundar sig på en standard som heter X.500 som utvecklades inom Internationella Teleunionen innan Internet och TCP/IP blev basen för all kommunikation mellan företag och privatpersoner. Det gör att LDAPs modell inte riktigt stämmer överens med Internet. Förslag finns nu på metoder att justera detta, så att katalogtjänsten blir mer kompatibel med Internet-modellen, både i PKIX-projektet och i separata RFC.
LDAP-modellen är en hierarki som kallas Directory Information Tree, DIT.
LDAP är baserat på kataloguppgifter, låt oss kalla det katalogkort, på engelska entries. Varje kort har ett unikt ID, som kallas RDN, Relative Distinguished NAME. Det är central-identifikationen för katalogkort i LDAP. (För dig som använder Internet e-post hade det lika bra gått att använda james.hacker@widget.co.uk som unikt begrepp, men betänk att det här härstammar från tiden innan Internet var det gemensamma nätverket.). RDN används som del av en adress till entriet som kallas Distinguished Name, DN. Ett DN består av flera uppgifter. Varje katalogkort är medlem av en eller flera kategorier (objectClass). För varje kategori finns en mall (eng: schema) som specificerar vilka attribut som skall eller får användas för just den här kategorin av uppgifter.
Ett vanligt attribut är C, som står för Country - Land. Under landet har varje organisation sin egen kod, som heter O - Organization. Varje enhet, t.ex. anställd, i organisationen får ett "vanligt namn", common name - CN. L står för Location, dvs ort.
Exempel: CN=James Hacker, L=Basingstoke, O=Widget Inc, C=GB
På internet hör varje företag till en toppdomän. I domänen har man en organisationskod, sin domän. Det vore ju bra om dessa mappades till O och C, men det är tyvärr inte fallet. Domännamnet får i stället införas på annat ställe i katalogen och olika leverantörer och standardorgan har gjort detta på olika sätt. Samma sak gäller epostadress. PKIX-projektet försöker råda bot på detta, likaså arbetet inom Directory Interoperability Forum. Så här kan det se ut:
Exempel: CN=James Hacker, OU=marketing, DC=widget.co.uk
I LDAP version 3 lagras mallarna i katalogtjänsten och kan dynamiskt uppdateras och sökas med LDAP-protokollet. Basmallarna definieras i olika RFC (se förteckning nedan). Andra mallar definieras av olika applikationer, leverantörer eller organisationer, på samma sätt som med XML. För att uppnå interoperabilitet är det önskvärt att mallarna är gemensamma där så är möjligt. Med fastställda mallar kan klienterna dessutom programmeras statiskt, vilket gör sökningen snabbare.
Varje kataloguppgift hör till en eller flera objekt-klasser. Objektklassen kännetecknas av en OID, Object Identifier och har en tillhörande mall, ett schema. I mallen definieras ett antal attribut som kan användas till objekt i tillhörande klassen. Varje attribut kan definieras som skall-krav eller frivilliga. Attribut kan tillhöra ett par olika klasser:
| Attribut-Typ | Förklaring |
| bin | Binära data |
| ces | Case Extact String eller directory string. Skiftläge (STORA eller små tecken) är signifikant vid sökning |
| cis | Case Ignore String |
| tel | Telefonnummber |
| dn | Distinguished Name |
| Generalized Time | År, månad, dag och tid |
| Postal Address | postadress |
|
|||||
