Portál AbcLinuxu, 19. dubna 2024 13:03
Cílem článku je přiblížit možnosti adresářových služeb a jejich použití v informačních systémech se zaměřením na standardizovaný protokol LDAP.
Obsah
Úvod
1. Adresář
1.1. Komponenty adresáře
1.2. Použití adresáře
1.3. LDAP
1.3.1. Adresáře v informačních systémech
1.4. Závěr
Prezentovat vlastnosti a možnosti adresářových služeb budu na produktu od firmy Sun Microsystems Sun Java System Directory Server (JES DS), který znám a ve své práci používám. Každopádně níže popsané skutečnosti platí ve velké míře na většinu adresářových serverů LDAP typu, z Open Source projektů je třeba zmínit SW Openldap.
Adresářem je například klasický telefonní seznam, organizovaný seznam kontaktů a vizitek nebo seznam uživatelských kont v počítačových systémech. Slouží nám k organizaci a sdružování dat do skupin, aby se v nich uživatel lépe orientoval. Adresáře jsou v podstatě jakési zásobníky (kontejnery) pro ukládání dat, specializované databáze, ve kterých lze uchovat a především vyhledat velké množství informací různého charakteru. Jedná se vlastně o hierarchický seznam objektů a atributů těchto objektů, porovnatelný se strukturou adresářů a podadresářů souborového systému.
Velmi často se spojují termíny adresář a adresářová služba a jsou považovány za synonyma. Naopak adresářové služby v informačních technologiích se skládají z více částí:
Tento dokument je zaměřen na popis použití klientského a serverového SW.
Proč využít adresář s LDAP přístupovým protokolem místo seznamu v souboru nebo relačních databází?
Adresářové služby nejsou určeny k zachycení transakčních dat a neovládají práci s referenční integritou. K tomu se velmi dobře hodí klasické relační databáze využívající SQL jazyka. Nepřipadají v úvahu jakékoliv rozsáhlé transakce spojené například s vkládáním více záznamů do databáze, u kterých je nutné provádět kontrolu správných hodnot dat. Není ovšem velký problém vytvořit jakousi datovou pumpu, která by přečerpávala data mezi SQL databází a adresářovými službami.
Lightweight Directory Access Protocol je standardizovaný protokol pro přístup k adresářovým službám, definuje komunikaci mezi serverem a klientem. Zprávy obsahují také příslušná data a informace o jejich formátu. Protokol běží nad internetovými transportními protokoly jako je TCP/IP. LDAP je jednodušší alternativou k protokolu X.500 Directory Access Protocol (DAP), přičemž slouží i jako brána pro přístup k tomuto protokolu.
LDAP je protokol orientovaný na zprávy (message-oriented protocol). Klient vytvoří zprávu obsahující nějakou žádost a odešle ji serveru. Ten ji zpracuje a odešle výsledek zpět jako sérii jedné nebo více LDAP zpráv.
Obrázek 1.1. LDAP komunikace
Příklad 1.1. LDAP komunikace - access [přístupový] log
Příklad access logu, uspěšné operace vyhledání atributu.
[22/May/2005:15:41:40] conn=1 op=-1 msgId=-1 - fd=35 slot=35 LDAP connection from 127.0.0.1 to 127.0.0.1 [22/May/2005:15:41:40] conn=1 op=0 msgId=1 - BIND dn="cn=Directory manager" method=128 version=3 [22/May/2005:15:41:40] conn=1 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [22/May/2005:15:41:40] conn=1 op=1 msgId=2 - SRCH base="dc=example,dc=cz" scope=2 filter="(uid=kuky)" attrs=ALL [22/May/2005:15:41:40] conn=1 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0 [22/May/2005:15:41:40] conn=1 op=2 msgId=3 - UNBIND [22/May/2005:15:41:40] conn=1 op=2 msgId=-1 - closing - U1 [22/May/2005:15:41:41] conn=1 op=-1 msgId=-1 - closed.
LDAP ve zkratce:
dn: dc=example,dc=cz
dn: o=organizace,dc=example,dc=cz
dn: uid=cirkva,ou=People,o=organizace,dc=example,dc=cz
Příklad 1.2. schéma - 00core.ldif
dn: cn=schema objectclass: top objectclass: ldapSubentry objectclass: subschema cn: schema # # aci # aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymous, no acis"; allow (read, search, compare) userdn = "ldap:///anyone";) # # attribute types: # attributeTypes: ( 2.5.4.1 NAME 'aliasedObjectName' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'RFC 2256' ) ... # # object classes: # objectClasses: ( 2.5.6.2 NAME 'country' DESC 'Standard LDAP objectclass' SUP top MUST ( c ) MAY ( searchGuide $ description ) X-ORIGIN 'RFC 2256' ) ...
Objekty v adresáři jsou vzájemně odděleny prázdným řádkem a skládají se z několika částí:
Příklad 1.3. LDIF se systémovými i uživatelskými informacemi
dn: uid=cirkva,ou=People,o=organizace,dc=example,dc=cz uid: cirkva iplanet-am-modifiable-by: cn=Top-level Admin Role,dc=example,dc=cz icsCalendar: cirkva@example.cz mail: cirkva@example.cz mailUserStatus: active gn: Lukáš sn: Cirkva mailHost: mail.example.cz inetUserStatus: Active userPassword: objectClass: userpresenceprofile objectClass: iplanet-am-managed-person objectClass: top objectClass: icscalendaruser objectClass: iplanet-am-user-service objectClass: inetadmin objectClass: organizationalperson objectClass: person objectClass: sunssoadapterperson mailDeliveryOption: mailbox icsExtendedUserPrefs: ceNotifyEmail=cirkva@example.cz icsExtendedUserPrefs: ceDefaultView=weekview icsExtendedUserPrefs: sunCalEventfilter=accepted,tentative,declined,needs-action icsFirstDay: 1 preferredLanguage: cs sunSSOAdapterConfigurations: default|http:/?configName=sunOneCalendar&configDe sc=SUN-ONE-CALENDAR&domain=example.cz nsRoleDN: cn=Role,o=organizace,dc=example,dc=cz ...
Příkazy k použití:
Příklady SW:
Příklady GUI:
S adresáři v informačních systémech setkáváme a budeme setkávat stále více. Všude se mluví o tom, jak je třeba hierarchické seznamy identit integrovat do jediného adresářového serveru. LDAP adresáře jsou v mnoha případech tím pravým řešením.
Příklady využití LDAP adresáře:
Doufám, že čtenář při čtení toho článku získal alespoň částečný rozhled o možnostech adresářových služeb, a že v něm vzbudil zájem o další informace o této problematice. Tento text ovšem není možno brát jako kompletní manuál, k tomu byly o problematice adresářových služeb napsány obsáhlé publikace.
V dalších části tohoto seriálu bude popsána instalace, administrace i s názornými přiklady.
Speciální poděkování patří Karlu Benákovi, který je spoluautorem této části, a na dalších částech se podílel velmi podmětnými připomínkami.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.