Docelowa rola akademickiego systemu katalogowego a schemat zasobów

1. Docelowa rola akademickiego systemu katalogowego a schemat zasobów Maja Górecka-Wolniewicz, UCI UMK

2. 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 e-mail • 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

3. 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” • systemypracujące w oparciu o procedurę logowania, portale • bazy danych o niejednorodnych prawach dostępu • systemy obliczeniowekorzystające z rozproszonych zasobów

4. 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

5. 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-8859-2 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.)

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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 : http://ldap2dns.tiscover.com/ • 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

12. 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

13. 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

14. 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 e-mail) • dokument eduPerson 1.0 Specification • podobny projekt ma być rozwijany w ramach prac organizacji TERENA: Definition of an European Educational Person (DEEP)

15. 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

16. 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?