LDAP, Toruń, Docelowa rola akademickiego systemu katalogowego a schemat zasobów Maja Górecka-Wolniewicz, UCI UMK

LDAP, Toruń, Do czego jest potrzebna baza katalogowa? „white pages service” – baza informacyjno-adresowa o polskim środowisku akademicko-naukowym repozytorium danych powszechnie używanych przez aplikacje sieciowe adresy URL-e zasobów sieciowych klucze wspomagające bezpieczną komunikację w sieci komputerowej (PGP, PKI) „network information service” – baza zawierająca informację o systemach komputerowych, serwerach, urządzeniach sieciowych, użytkownikach

LDAP, Toruń, Do czego jest potrzebna baza katalogowa? gromadzenie danych potrzebnych do tworzenia statystyk wykorzystania systemów, rozliczania użytkowników specyficzne usługi wynikające z potrzeb konkretnych aplikacji sieciowych repozytorium danych służących do utrzymywanie wirtualnej sesji pracy z aplikacją, przechowywanie danych o konfiguracji wspomaganie pracy rozproszonych aplikacji obliczeniowych (systemy GRID) wsparcie dla procesów typu AAA „authentication, authorization, accounting” systemy pracujące w oparciu o procedurę logowania, portale bazy danych o niejednorodnych prawach dostępu systemy obliczeniowe korzystające z rozproszonych zasobów

LDAP, Toruń, Model zasobów katalogowych, nazewnictwo LDAP dziedziczy model bazy danych wprowadzony w standardzie X.500 nazwy wyróżnione obiektów (wpisów) wynikają z: lokalizacji wpisu w globalnym drzewie danych zastosowanych atrybutów wyróżnionych we wpisie dwa podejścia drzewo „organizacyjne” standard X.521, The directory: selected object classes cn=Tomasz Wolniewicz, ou=UCI, o=UMK, c=PL drzewo domenowe RFC 1279, X.500 and Domains, 1991 RFC 2247, Using Domains in LDAP/X.500, 1998 uid=twoln, dc=uci, dc=uni, dc=torun, dc=pl

LDAP, Toruń, Polskie znaki diakrytyczne w nazwach nazwy wyróżnione mogą zawierać polskie znaki diakrytyczne problem dotyczy drzewa „organizacyjnego”, drzewo domenowe nie stosuje znaków spoza ASCII w atrybutach wyróżnionych format wewnętrzny przechowywania danych LDAP: UTF-8 dostosowanie danych wejściowych (np. translacja plików LDIF z postaci ISO do postaci UTF-8) dostosowanie interfejsów wyświetlających dane, wyszukujących dane itp. internacjonalizacja danych stosowanie podtypów do wprowadzania wartości atrybutów specyficznych dla danego języka (wersja angielska, polska itp.)

LDAP, Toruń, Postać drzewa danych usługi ogólnopolskiej gałąź organizacyjna odzwierciedlenie struktury organizacyjnej jednostek lokalizacja danych typu „white pages” lokalizacja certyfikatów kluczy publicznych gałąź domenowa odzwierciedlenie internetowej struktury domenowej lokalizacja danych uwierzytelniających lokalizacja danych o użytkownikach, urządzeniach sieciowych, serwerach, serwisach sieciowych synchronizacja zawartości informacyjnej obu drzew

LDAP, Toruń, Bazowy schemat danych zgodny ze schematem stosowanym w projekcie OpenLDAP core.schema, cosine.schema – klasy obiektów obejmujące: rekomendacje X.521 RFC 1274 – The COSINE and Internet Schema dokumenty RFC od 2251 do 2256 – specyfikacja LDAPv3 RFC 2079 – Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) RFC 2247 – Using Domains in LDAP/X.500 RFC 2377 – Naming plan for Directory-Enabled Applications RFC 2589 – LDAPv3, Extensions for Dynamic Directory Services

LDAP, Toruń, Dodatkowe schematy danych (1) inetorgperson.schema – klasa obiektów oraz atrybuty zdefiniowane w: RFC 2798 – Definition of the inetOrgPerson LDAP Object Class nowe atrybuty opisujące osoby: CarLicense, DepartmentNumber, DisplayName, EmployeeNumber, EmployeeType, jpegPhoto, preferredLanguage, userSMIMECertificate, userPKCS12 nis.schema – klasy obiektów oraz atrybuty zdefiniowane w: RFC 2307 – An Approach for Using LDAP as a Network Information Service nowe klasy obiektów, m.in.: posixAccount, posixGroup, shadowAccount, ipService, ipProtocol, ipHost, bootableDevice nowe atrybuty, m.in.: uidNumber, gidNumber, homeDirectory, loginShell, shadowLastChange,ipServicePort, ipServiceProtocol, ipHostNumber, ipNetworkNumber, macAddress, bootParameter, bootFile

LDAP, Toruń, Dodatkowe schematy danych (2) misc.schema – klasa obiektów oraz atrybuty zdefiniowane w: Internet-Draft – LDAP Schema for Internet Mail Routing (draft-lachman-laser-ldap-mail-routing-02.txt) np. wykorzystywane w programie sendmail skonfigurowanym do współpracy z LDAP-em klasa obiektów inetLocalMailRecipient atrybuty: mailLocalAddress, mailHost, mailRoutingAddress

LDAP, Toruń, Rozszerzenia specjalizowane schemat rozszerzający możliwości współpracy programu sendmail z LDAP-em, sendmail.schema klasy obiektów: sendmailMTA, sendmailMTAMap, sendmailMTAMapObject, sendmailMTAAlias, sendmailMTAAliasObject, sendmailMTAClass atrybuty: sendmailMTAHost, sendmailMTACluster, sendmailMTAKey, sendmailMTAMapName, sendmailMTAMapValue, sendmailMTAAliasGrouping, sendmailMTAAliasValue, sendmailMTAClassName, sendmailMTAClassValue

LDAP, Toruń, Schemat LDAP dla DNS-a propozycja schematu: LDAP: Schema for Domain Name System (draft-miller-dns-ldap-schema-00) klasy obiektów: DNS Zone, DNS RR Set, DNS Server atrybuty: DNIPZoneDomainName, DNIPSecondaryZone, DNIPSOASerial, DNIPRR, DNIPMACAddress cele integracji LDAP-DNS możliwość utrzymywania centralnego źródła informacji DNS ułatwienie administrowania gateway LDAP – DNS : program ldap2dns tworzy rekordy RR na podstawie bazy LDAP ldap2dns tworzy pliki tekstowe ASCII, z których korzysta program tinydns z pakietu djbdns, może również zapisać pliki.db, używane przez program named z pakietu BIND

LDAP, Toruń, Samba a schemat LDAP integracja Samby z LDAP-em jest realizowana w eksperymentalnej gałęzi projektu Samba-TNG są uwzględniane schematy stosowane w projekcie OpenLDAP oraz schematy Microsoft (Active Directory) ldap-smb-HEAD – schemat LDAP dla wersji HEAD pre-2.1, zawiera definicję: klasy obiektów: sambaAccount, sambaGroup, sambaBuiltin atrybutów: uid, uidNumber, ntuid, rid, sid ldap-smb-TNG – schemat LDAP dla wersji TNG, zawiera definicję schematu zgodną z wersją HEAD i dodatkowo definicję: klas obiektów: sambaConfig, sambaAlias

LDAP, Toruń, Active Directory a Samba integracja Samby ze schematem Active Directory np. obok standardowej klasy obiektów top istnieje klasa Top, zawierająca dodatkowe atrybuty (m.in. klasa Top wymaga określenia wartości wielu atrybutów, np.: cn, defaultObjectCategory, objectCategory, objectClassCategory) lokalizacja komputera w drzewie AD top | person | organizationalPerson | User | Computer

LDAP, Toruń, Klasa eduPerson amerykańska inicjatywa stworzenia nowej klasy obiektów opisującej osoby zgodnie z potrzebami środowiska akademickiego zestaw dodatkowych atrybutów, m.in. eduPersonAffiliation (student, pracownik, doktorant), eduPersonNickname, eduPersonOrgDN (wyróżniona nazwa instytucji związanej z pracownikiem), eduPersonOrgUnitDN (wyróżniona nazwa jednostki związanej z pracownikiem), eduPersonPrimaryAffiliation, eduPersonPrincipalName („sieciowy” identyfikator osoby, np. w postaci adresu ) dokument eduPerson 1.0 Specification podobny projekt ma być rozwijany w ramach prac organizacji TERENA: Definition of an European Educational Person (DEEP)

LDAP, Toruń, Systemy obliczeniowe a LDAP lokalizacja zasobów obliczeniowych jednorodne techniki informowania o stanie oraz strukturze systemów wspomaganie obsługi podstawowych technik pracy systemów rozproszonych: przekazywanie komunikatów (message passing), wywoływanie zdalnych procedur (remote procedure call), obsługa wspólnej pamięci rozproszonej (distributed shared memory) itp. pakiet openldap zawiera definicje java.schema i corba.schema klasy: javaObject, javaContainer, javaNamingReference, corbaObject, corbaContainer, corbaObjectReference

LDAP, Toruń, Uwierzytelnianie i autoryzacja uwierzytelnianie, poświadczanie tożsamości, autentykacja hasła, dokumenty poświadczające tożsamość, karty elektroniczne (smartcards), techniki kryptograficzne LDAP jako repozytorium haseł, certyfikatów kluczy publicznych itp. autoryzacja dotyczy praw dostępu do określonych zasobów sieciowych, danych, usług itp. (tzw. access control lists) najczęściej opiera się na wynikach procesu uwierzytelnienia może uwzględniać przynależność do grup, zespołów, pełnioną funkcję problemy: gdzie zapamiętywać dane związane z autoryzacją? jak przekazywać te dane do aplikacji? jak zagwarantować aktualność danych służących do autoryzacji? jak egzekwować stosowane polityki dot. autoryzacji?