Technick´ a univerzita v Liberci
Fakulta mechatroniky, informatiky a mezioborov´ ych studi´ı
DIPLOMOV ´ A PR ´ ACE
Bc. Zdenˇek Perutka
Ovˇ eˇ rov´ an´ı Verse serveru proti LDAPu a Kerberos serveru
Verse server authentication over LDAP and Kerberos
Ustav Nov´´ ych technologi´ı a aplikovan´e informatiky Vedouc´ı diplomov´e pr´ace: Ing. Jiˇr´ı Hn´ıdek, Ph.D.
Studijn´ı program: N2612 – Elektrotechnika a informatika Studijn´ı obor: 1802T007 – Informaˇcn´ı technologie
Liberec 2014
Zad´an´ı
1. Nejprve se d˚ukladnˇe seznamte s technologi´ı LDAP a Kerberos.
2. Implementujte do Verse serveru ovˇeˇrov´an´ı uˇzivatelsk´ych ´uˇct˚u proti LDAPu a Ker- beros serveru. Z´aroveˇn proved’te kerberizaci knihovny, kter´a se pouˇz´ıv´a k implementaci Verse klient˚u.
3. Nakonec nov´e metody ovˇeˇrov´an´ı uˇzivatelsk´ych ´uˇct˚u d˚ukladnˇe otestujte a vytvoˇrte k nim odpov´ıdaj´ıc´ı dokumentaci.
Prohl´ aˇ sen´ı
Byl jsem sezn´amen s t´ım, ˇze na mou diplomovou pr´aci se plnˇe vztahuje z´akon ˇc. 121/2000 Sb., o pr´avu autorsk´em, zejm´ena § 60 - ˇskoln´ı d´ılo.
Beru na vˇedom´ı, ˇze Technick´a univerzita v Liberci (TUL) nezasahuje do m´ych au- torsk´ych pr´av uˇzit´ım m´e diplomov´e pr´ace pro vnitˇrn´ı potˇrebu TUL.
Uˇziji-li diplomovou pr´aci nebo poskytnu-li licenci k jej´ımu vyuˇzit´ı, jsem si vˇedom povinnosti informovat o t´eto skuteˇcnosti TUL; v tomto pˇr´ıpadˇe m´a TUL pr´avo ode mne poˇzadovat ´uhradu n´aklad˚u, kter´e vynaloˇzila na vytvoˇren´ı d´ıla, aˇz do jejich skuteˇcn´e v´yˇse.
Diplomovou pr´aci jsem vypracoval samostatnˇe s pouˇzit´ım uveden´e literatury a na z´akladˇe konzultac´ı s vedouc´ım m´e diplomov´e pr´ace a konzultantem.
Datum
Podpis
Podˇekov´an´ı
Na tomto m´ıstˇe bych chtˇel podˇekovat zejm´ena sv´e rodinˇe a pˇr´atel˚um za podporu, sestˇre ˇS´arce za trpˇelivou pomoc s pravopisem. Velk´y d´ık patˇr´ı tak´e vedouc´ımu pr´ace, Ing.
Jiˇr´ımu Hn´ıdkovi, Ph.D., za konzultace a uˇziteˇcn´e rady pˇri ˇreˇsen´ı zad´an´ı.
Kontakt
E-mail: zdenek.perutka@tul.cz, z.perutka@gmail.com
Anotace
Tato diplomov´a pr´ace m´a za ´ukol rozˇs´ıˇren´ı s´ıt’ov´eho protokolu Verse, zab´yvaj´ıc´ıho se real-timov´ym sd´ılen´ım dat o podporu ovˇeˇrov´an´ı uˇzivatelsk´ych ´uˇct˚u proti LDAPu a jeho kerberizac´ı. Toto rozˇs´ıˇren´ı Verse protokolu je d˚uleˇzit´e pro zv´yˇsen´ı jeho komplexnosti.
V ´uvodu pr´ace je struˇcnˇe pops´ana podstata fungov´an´ı protokol˚u LDAP a Kerbe- ros. N´aslednˇe je pˇredloˇzen struˇcn´y pˇrehled implementac´ı LDAP a Kerberos server˚u a knihoven umoˇzˇnuj´ıc´ıch implementaci LDAP nebo Kerberos klient˚u vˇcetnˇe v´ybˇeru nej- vhodnˇejˇs´ıch knihoven pro implementaci do knihovny implementuj´ıc´ı protokol Verse.
Hlavn´ımi ´uˇcely pr´ace bylo vytvoˇren´ı funkc´ı pro naˇc´ıt´an´ı uˇzivatel˚u z LDAP serveru a jejich autentizaci na stranˇe Verse serveru, autentizace Kerberos uˇzivatele a n´asledn´a ker- berizace knihovny protokolu Verse. Pr´ace se zab´yv´a zmˇenou rozhran´ı pro odchyt´av´an´ı sign´al˚u na Verse serveru na robustnˇejˇs´ı rozhran´ı vhodn´e pro v´ıcevl´aknov´e aplikace.
Funkˇcnost a spr´avnost rozˇs´ıˇren´eho Verse protokolu je v z´avˇereˇcn´e ˇc´asti pr´ace vy- zkouˇsena na vzorov´e aplikaci, kter´a byla novˇe rozˇs´ıˇrena za ´uˇcelem testov´an´ı nov´ych funkc´ı. Testov´an´ı prob´ıhalo zad´av´an´ım spr´avn´ych i ˇspatn´ych pˇrihlaˇsovac´ıch ´udaj˚u za uˇzit´ı obou nov´ych autentizaˇcn´ıch metod.
Kl´ıˇcov´a slova: Verse, LDAP, Kerberos, autentizace, s´ıt’ov´y protokol
Annotation
The thesis is focused on extension of the Verse network protocol which is used for real-time data sharing. The extension bases on including support for authentication over LDAP and Kerberos which is very important in context of complexity enhancement.
Introduction of the thesis briefly describes the nature of the LDAP and the Kerberos.
Latter, a brief overview of implementations of LDAP, Kerberos servers and libraries which enable LDAP or Kerberos is offered, following by a selection of the two best libraries, to be used for implementation into the Verse protocol library.
The main aims of the study were to create functions for loading user accounts from LDAP server and authenticating them on Verse server side and authentication of Kerberos user and consecutive Kerberizing of Verse protocol library. Change of the signal interface on Verse server to a more robust interface suitable for multithreaded applications is also included.
Functionality of the extended Verse protocol was checked on a sample application in the final parts of the thesis. An already written sample application was also extended in order to test new functions. Testing was proceeded by inserting valid and invalid credentials, using both new authentication methods.
Key words: Verse, LDAP, Kerberos, authentication, network protocol
Obsah
Prohl´aˇsen´ı 3
Anotace 5
Annotation 6
Seznam symbol˚u a zkratek 10
1 Uvod´ 11
1.1 Souˇcasn´e ˇreˇsen´ı problematiky . . . 11
1.2 C´ıle pr´ace . . . 11
2 Popis protokol˚u Verse, LDAP a Kerberos 13 2.1 Verse . . . 13
2.2 LDAP . . . 13
2.3 Adres´aˇrov´a sluˇzba . . . 14
2.4 X.500 . . . 14
2.5 Informaˇcn´ı model LDAP . . . 14
2.5.1 Objektov´e tˇr´ıdy . . . 15
2.5.2 Atributy . . . 16
2.6 Jmenn´y model LDAP . . . 16
2.6.1 Rozliˇsovac´ı jm´eno . . . 16
2.7 Bezpeˇcnostn´ı model LDAP . . . 17
2.7.1 LDAP autentizace . . . 17
2.7.2 LDAP autorizace . . . 18
2.8 Funkˇcn´ı model LDAP . . . 19
2.9 LDIF . . . 20
2.10 Kerberos . . . 20
2.10.1 Zah´ajen´ı komunikace . . . 21
3 LDAP a Kerberos servery 24
3.1 LDAP servery . . . 24
3.1.1 389 Directory Server . . . 24
3.1.2 Apache Directory . . . 24
3.1.3 OpenDS . . . 24
3.1.4 OpenLDAP . . . 25
3.1.5 Komerˇcn´ı LDAP servery . . . 25
3.2 Kerberos Servery . . . 25
3.2.1 MIT Kerberos . . . 25
3.2.2 Heimdal . . . 26
3.2.3 Komerˇcn´ı Kerberos servery . . . 26
4 Knihovny implementuj´ıci LDAP a Kerberos 27 4.1 Spring LDAP . . . 27
4.2 Python-ldap . . . 27
4.3 Perl LDAP . . . 27
4.4 OpenLDAP . . . 27
4.5 MIT Kerberos . . . 28
5 Ovˇeˇren´ı Verse serveru proti LDAPu 29 5.1 P˚uvodn´ı uˇzivatelsk´e ´uˇcty Verse . . . 29
5.2 Uprava datov´´ ych struktur . . . 29
5.3 Naˇcten´ı uˇzivatel˚u z LDAP serveru . . . 30
5.4 Ovˇeˇren´ı uˇzivatele proti LDAPu . . . 32
5.5 Obnoven´ı seznamu uˇzivatel˚u . . . 33
5.6 Zmˇena rozhran´ı pro odchyt´av´an´ı sign´al˚u . . . 33
5.7 Naˇc´ıt´an´ı uˇzivatele pˇri pokusu o pˇrihl´aˇsen´ı . . . 33
6 Kerberizace Verse protokolu 35 6.1 Uprava datov´´ ych struktur . . . 35
6.2 Nav´az´an´ı spojen´ı a autentizace uˇzivatele . . . 36
6.3 Vyjedn´av´an´ı . . . 36
6.4 Inicializace struktury reprezentuj´ıc´ı TCP spojen´ı . . . 39
6.5 Ovˇeˇren´ı tiketu . . . 41
6.6 Ovˇeˇren´ı existence uˇzivatele v r´amci Verse serveru . . . 41
6.7 Nav´az´an´ı UDP spojen´ı . . . 43
6.8 Kerberizace pˇrenosu pˇres TCP . . . 43
6.9 Kerberizace pˇrenosu pˇres UDP . . . 44
6.10 ´Uprava vzorov´e aplikace . . . 45
7 Testov´an´ı 47 7.1 Naˇcten´ı uˇzivatel˚u z LDAPu . . . 47
7.2 Naˇcten´ı novˇe pˇridan´ych uˇzivatel˚u . . . 49
7.3 Ovˇeˇren´ı uˇzivatele proti LDAPu . . . 49
7.4 Naˇcten´ı LDAP uˇzivatele pˇri pˇrihl´aˇsen´ı . . . 50
7.5 Ovˇeˇren´ı proti Kerberos serveru . . . 52
8 Z´avˇer 54
Reference 56
Pˇr´ıloha - Uˇzivatelsk´a dokumentace 58
Seznam symbol˚ u a zkratek
AES Advanced Encryption Standard API Application Programming Interface AS Authentication Service
CDDL Common Development and Distribution License CMake Cross-Platform Makefile Generator
CSV Comma-Separated Values DED Data Exchange Definition DIT Directory Information Tree DN Distinguished Name
DNS Domain Name System
GPLv3 General Public License version 3 IETF The Internet Engineering Task Force KDC Key Distribution Center
LDAP Lightweight Directory Access Protocol LDIF LDAP Data Interchange Format
MIT Massachusetts Institute of Technology
ITU-T International Telecommunication Union Telecommunication Standardization Sector
PAM Pluggable Authentication Modules RDN Relative Distinguished Name
SASL Simple Authentication and Security Layer TCP Transmission Control Protocol
TGS Ticket-Granting Server TGT Ticket-Granting Ticket TLS Transport Layer Security UDP User Datagram Protocol
UTF-8 Universal Character Set Transformation Format — 8-bit
1 Uvod ´
Uvodem bude struˇ´ cnˇe pops´ano souˇcasn´e ˇreˇsen´ı problematiky uˇzivatelsk´ych ´uˇct˚u a ˇsifrov´an´ı komunikace. D´ale budou pops´any c´ıle pr´ace.
1.1 Souˇ casn´ e ˇ reˇ sen´ı problematiky
V souˇcasn´e dobˇe Verse server naˇc´ıt´a uˇzivatelsk´e ´uˇcty z Comma-Separated Values (CSV) souboru [1]. V nˇem je definov´ano uˇzivatelsk´e jm´eno, heslo, identifikaˇcn´ı ˇc´ıslo uˇzivatele a jeho skuteˇcn´e jm´eno, viz. n´asleduj´ıc´ı v´ypis.
username,password,UID,real name usr@ZDN.LOCAL,abc,2000,Test User
Verse server tyto uˇzivatelsk´e ´uˇcty naˇc´ıt´a pˇri startu. Informace vytˇeˇzen´e z CSV sou- boru ukl´ad´a do struktury pro ukl´ad´an´ı uˇzivatel˚u. Tato struktura m´a atributy pro jed- notliv´e informace definovan´e v CSV souboru. Nav´ıc je zde atribut urˇcuj´ıc´ı, zda je moˇzn´e se k tomuto ´uˇctu pˇrihl´asit a atributy odkazuj´ıc´ı na pˇredchoz´ı a n´asleduj´ıc´ı uˇzivatelsk´y
´
uˇcet. Jednotliv´e ´uˇcty jsou tedy uchov´any ve spojov´em seznamu.
Pˇri pokusu o pˇrihl´aˇsen´ı Verse server obdrˇz´ı od klienta uˇzivatelsk´e jm´eno a heslo. Po obdrˇzen´ı pˇrihlaˇsovac´ıch ´udaj˚u Verse server proch´az´ı spojov´y seznam uˇzivatelsk´ych ´uˇct˚u a porovn´av´a uˇzivatelsk´a jm´ena a hesla jednotliv´ych ´uˇct˚u s obdrˇzen´ymi ´udaji. Jsou-li zad´any spr´avn´e pˇrihlaˇsovac´ı ´udaje, server vytvoˇr´ı uˇzivateli avatar a klientovi odeˇsle zpr´avu o ´uspˇeˇsn´e autentizaci, v opaˇcn´em pˇr´ıpadˇe zpr´avu o ne´uspˇeˇsn´e autentizaci.
Komunikace mezi Verse serverem a Verse klientem je v souˇcasn´e dobˇe ˇsifrov´ana pomoc´ı Transport Layer Security (TLS) [2]. Komunikace m˚uˇze prob´ıhat i neˇsifrovanˇe.
1.2 C´ıle pr´ ace
Prvn´ım c´ılem pr´ace je rozˇs´ıˇrit Verse server, aby byl schopen naˇc´ıst seznam uˇzivatel˚u z LDAP serveru. K tomu bude nutn´e na Verse serveru vytvoˇrit funkci, jej´ıˇz pomoc´ı se server pˇripoj´ı k LDAP serveru a odeˇsle mu dotaz poˇzaduj´ıc´ı seznam uˇzivatel˚u.
identifikaˇcn´ı ˇc´ıslo uˇzivatele jm´eno a pˇr´ıjmen´ı. D´ale je snahou, aby se Verse server pˇri obdrˇzen´ı vhodnˇe zvolen´eho sign´alu pokusil z LDAP serveru naˇc´ıst novˇe pˇridan´e uˇzivatelsk´e ´uˇcty.
Druh´ym c´ılem je vlastn´ı ovˇeˇren´ı uˇzivatelsk´ych ´uˇct˚u proti LDAPu. Verse server se po- kus´ı pomoc´ı pˇrihlaˇsovac´ıch ´udaj˚u obdrˇzen´ych od Verse klinta pˇrihl´asit k LDAP serveru.
Pokud bude toto pˇrihl´aˇsen´ı ´uspˇeˇsn´e a z´aroveˇn se bude uˇzivatel se zadan´ym uˇzivatelsk´ym jm´enem nach´azet v seznamu uˇzivatel˚u Verse serveru, Verse server vytvoˇr´ı uˇzivateli ava- tar a klientovi odeˇsle zpr´avu o ´uspˇeˇsn´e autentizaci, v opaˇcn´em pˇr´ıpadˇe odeˇsle zpr´avu o ne´uspˇeˇsn´e autentizaci.
Tˇret´ım c´ılem je ovˇeˇren´ı Verse serveru proti Kerberos serveru. Verse server si naˇcte uˇzivatelsk´e ´uˇcty z CSV souboru nebo z LDAPu. Verse klient se pˇrihl´as´ı ke Kerbe- ros serveru a zaˇz´ad´a o pˇr´ıstup ke sluˇzbˇe Verse. Pomoc´ı obdrˇzen´ych kl´ıˇc˚u nav´aˇze spo- jen´ı s Verse serverem. Verse server pot´e projde sv˚uj seznam uˇzivatel˚u (zkontroluje zda uˇzivatel s dan´ym uˇzivatelsk´ym jm´enem v r´amci Verse serveru existuje) a odeˇsle klientovi zpr´avu o ´uspˇeˇsn´e respektive ne´uspˇeˇsn´e autentizaci.
Ctvrt´ˇ ym c´ılem pr´ace je kerberizace Verse protokolu. Ta bude realizov´ana ˇsifrov´an´ım dat pˇren´aˇsen´ych mezi Verse serverem a Verse klientem pomoc´ı kl´ıˇce z´ıskan´eho bˇehem autentizace uˇzivatele proti Kerberos serveru.
P´at´ym c´ılem je otestov´an´ı novˇe implementovan´ych autentizaˇcn´ıch metod. Pˇri tomto testov´an´ı bude snaha postihnout a otestovat vˇsechny stavy, kter´ych se mohou novˇe implementovan´e funkce nach´azet.
Nakonec bude seps´ana uˇzivatelsk´a dokumentace. Ta bude obsahovat instrukce k pro- vozov´an´ı Verse serveru a Verse klienta za pouˇzit´ı novˇe implementovan´ych metod ovˇeˇrov´an´ı uˇzivatelsk´ych ´uˇct˚u.
2 Popis protokol˚ u Verse, LDAP a Kerberos
V t´eto kapitole bude struˇcnˇe pops´an s´ıt’ov´y protokol Verse. D´ale bude vysvˇetlen princip funkce protokl˚u LDAP a Kerberos. Pops´any budou i dalˇs´ı pojmy souvisej´ıc´ı s LDAPem, Kerberem a jejich implementac´ı do Verse protokolu.
2.1 Verse
Verse je s´ıt’ov´y protokol typu klient-server. Je urˇcen pro real-timov´e sd´ılen´ı dat pˇredevˇs´ım mezi grafick´ymi aplikacemi.
P˚uvodn´ı Verse protokol byl vyv´ıjen Uni-Verse konsorciem v r´amci 6. r´amcov´eho pro- gramu Evropsk´e unie. Do konsorcia patˇrilo nˇekolik v´yznamn´ych univerzit a v´yzkumn´ych instituc´ı jako KTH, Fraunhoufer Institut, Helsinki University of Technology, Interactive Institute a Blender Foundation. Verse protokol byl od poˇc´atku navrhov´an pro efektivn´ı real-timov´e sd´ılen´ı dat pˇredevˇs´ım mezi grafick´ymi aplikacemi a mˇel ambici st´at se uni- verz´aln´ım protokolem pro komunikaci mezi grafick´ymi aplikacemi. Po ukonˇcen´ı finan- cov´an´ı Evropskou uni´ı v´yvoj protokolu ustal a ten se bohuˇzel z mnoha d˚uvod˚u nakonec nerozˇs´ıˇril [3].
V souˇcasn´e dobˇe vyv´ıj´ı Ing. Jiˇr´ı Hn´ıdek, Ph.D. novou verzi Verse protokolu. Snahou je, aby tato verze byla robustnˇejˇs´ı a pˇredevˇs´ım l´epe implementovateln´a do souˇcasn´ych i budouc´ıch aplikac´ı. Protokol je implementov´an v jazyce C.
2.2 LDAP
Lightweight Directory Access Protocol (LDAP) je odlehˇcenou verz´ı protokolu X.500 [4]. Jedn´a se o protokol urˇcen´y pro pˇr´ıstup k adres´aˇrov´ym sluˇzb´am. Protokol LDAP je standardizov´an organizac´ı The Internet Engineering Task Force (IETF) [5] a je to protokol typu klient-server. Jeden nebo v´ıce LDAP server˚u obsahuj´ı data, jeˇz tvoˇr´ı adres´aˇrov´y strom (Directory Information Tree, DIT). Data na serveru jsou uspoˇr´ad´ana hierarchicky.
Klient pos´ıl´a serveru dotazy. Tyto dotazy slouˇz´ı napˇr´ıklad k autentizaci uˇzivatele, k pˇrid´av´an´ı a modifikaci z´aznam˚u nebo jejich vyhled´av´an´ı ˇci porovn´av´an´ı. Dotazy de-
finuje funkˇcn´ı model LDAP, viz. 2.8. Server odes´ıl´a zpˇet odpovˇedi na dotazy, pˇr´ıpadnˇe odkaz na jin´y LDAP server, z nˇehoˇz lze poˇzadovanou informaci z´ıskat. Protokol LDAP je hojnˇe pouˇz´ıvan´y v praxi. Mezi jeho nejˇcastˇejˇs´ı uplatnˇen´ı patˇr´ı:
• Autentizace uˇzivatel˚u
• ´Uloˇziˇstˇe uˇzivatelsk´ych nastaven´ı
• ˇR´ızen´ı pˇr´ıstupu k dat˚um
• Adres´aˇr kontakt˚u
• ´Uloˇziˇstˇe konfigurac´ı aplikac´ı
• Reprezentace struktury organizace
2.3 Adres´ aˇ rov´ a sluˇ zba
Adres´aˇrov´a sluˇzba je datab´aze optimalizovan´a pro proch´azen´ı a vyhled´av´an´ı z´aznam˚u. Adres´aˇre tvoˇr´ı hierarchickou strukturu a mohou obsahovat r˚uznorod´e datov´e typy. Adres´aˇrov´e sluˇzby obecnˇe nepodporuj´ı komplikovan´e transakce a nekontroluj´ı re- ferenˇcn´ı integritu.
Dobr´ym pˇr´ıkladem adres´aˇrov´e sluˇzby je Domain Name System (DNS). Je to sluˇzba glob´alnˇe distribuovan´a. Jednotliv´e DNS servery jsou uspoˇr´ad´any hierarchicky.
2.4 X.500
Jak jiˇz bylo ˇreˇceno LDAP je odlehˇcenou verz´ı X.500. X.500 je skupina standard˚u popisuj´ıc´ıch adres´aˇrov´e sluˇzby, jeˇz byly schv´aleny v roce 1988 a byly navrˇzeny organizac´ı ITU-T. V Praxi se X.500 pˇr´ıliˇs nepouˇz´ıv´a naopak pˇrevl´ad´a LDAP, kter´y p˚uvodnˇe slouˇzil pouze ke komunikaci s X.500.
2.5 Informaˇ cn´ı model LDAP
Informaˇcn´ı model LDAP definuje, jak´e informace a datov´e typy lze ukl´adat na adres´aˇrov´em serveru. Data jsou uchov´av´ana coby z´aznamy, jeˇz jsou hierarchicky
uspoˇr´ad´any do stromov´e struktury. Jednotliv´e z´aznamy tvoˇr´ı mnoˇzinu atribut˚u. Atri- buty ch´apeme jako dvojici jm´eno - hodnota, kter´a urˇcuje stav konkr´etn´ıho z´aznamu.
Z´aznamy musej´ı odpov´ıdat definovan´emu sch´ematu. Sch´ema urˇcuje povolen´e objek- tov´e tˇr´ıdy a k nim n´aleˇz´ıc´ı atributy. Kaˇzd´y z´aznam je pak instanc´ı nˇejak´e objektov´e tˇr´ıdy. T´ım p´adem z´aznam mus´ı obsahovat vˇsechny povinn´e atributy pˇr´ısluˇsn´e objektov´e tˇr´ıdy a m˚uˇze obsahovat nepovinn´e atributy t´eto tˇr´ıdy.
2.5.1 Objektov´e tˇr´ıdy
Objektov´e tˇr´ıdy mohou b´yt tˇr´ı druh˚u:
• STRUCTURAL - odvozen´a objektov´a tˇr´ıda. Pr´avˇe od tˇechto tˇr´ıd se odvozuj´ı jednotliv´e z´aznamy. Kaˇzd´y z´aznam pak mus´ı b´yt odvozen´y alespoˇn od jedn´e t´eto tˇr´ıdy. Pokud je z´aznam odvozen od v´ıce tˇr´ıd, mus´ı b´yt tyto tˇr´ıdy v dˇediˇcn´em vztahu.
• ABSTRACT - abstraktn´ı objektov´a tˇr´ıda. Nelze od n´ı odvozovat jednotliv´e z´aznamy, slouˇz´ı pouze jako rodiˇcovsk´a tˇr´ıda, od n´ıˇz se odvozuj´ı odvozen´e tˇr´ıdy.
• AUXILIARY - doplˇnkov´e objektov´e tˇr´ıdy. Jejich pomoc´ı lze z´aznam˚um pˇrid´avat dalˇs´ı atributy. Kaˇzd´y z´aznam m˚uˇze b´yt odvozen od libovoln´eho poˇctu doplˇnkov´ych tˇr´ıd.
Na n´asleduj´ıc´ım v´ypisu je uk´azka definice objektov´e tˇr´ıdy.
objectclass ( 2.16.840.1.113730.3.2.2 NAME ’extendedPerson’
SUP organizationalPerson STRUCTURAL
MUST ( uid ) MAY (
employeeNumber $ givenName $ jpegPhoto $ userCertificate )
Direktiva SUP urˇcuje rodiˇcovskou objektovou tˇr´ıdu, tedy tˇr´ıdu od n´ıˇz dan´a tˇr´ıda dˇed´ı vˇsechny povinn´e i nepovinn´e atributy. Direktiva STRUCTURAL urˇcuje, ˇze se jedn´a o odvozenou objektovou tˇr´ıdu, MAY je seznam nepovinn´ych atribut˚u. Povinn´e atributy se urˇcuj´ı direktivou MUST.
2.5.2 Atributy
Podobnˇe jako objektov´e tˇr´ıdy jsou pˇresnˇe definov´any i jejich atributy. Ty se pak skl´adaj´ı pr´avˇe do objektov´ych tˇr´ıd, viz v´yˇse. U atribut˚u funguje, stejnˇe jako u objek- tov´ych tˇr´ıd, dˇediˇcnost. N´asleduj´ıc´ı v´ypis obsahuje uk´azku definice a atributu.
attributetype ( 2.5.4.3 NAME ( ’cn’ ’commonName’ )
DESC ’RFC2256: common name(s) for which the entity is known by’
SUP name )
U atribut˚u je tak´e moˇzno definovat syntaxi, tedy jakou strukturu budou data m´ıt (napˇr. ˇretˇezec znak˚u UTF-8, cel´e ˇc´ıslo, JPEG obr´azek, atd.).
2.6 Jmenn´ y model LDAP
Jmenn´y model LDAP definuje, jak´ym zp˚usobem se pˇristupuje k dat˚um a jak´ym zp˚usobem jsou data organizov´ana.
2.6.1 Rozliˇsovac´ı jm´eno
Rozliˇsovac´ı jm´eno (Distinguished Name, DN) slouˇz´ı k jednoznaˇcn´e identifikaci jed- notliv´ych z´aznam˚u. V r´amci jedn´e vˇetve mluv´ıme o relativn´ım rozliˇsovac´ım jm´enu (Re- lative Distinguished Name, RDN), kter´e mus´ı b´yt v dan´e vˇetvi a ´urovni stromu takt´eˇz jednoznaˇcn´e. RDN se skl´ad´a ze jm´ena atributu, jenˇz jednoznaˇcnˇe identifikuje z´aznam v jeho vˇetvi a ´urovni, a jeho hodnoty.
DN se pak sest´av´a z jednotliv´ych RDN, kter´e se skl´adaj´ı v poˇrad´ı od RDN konkr´etn´ıho z´aznamu postupnˇe aˇz ke koˇreni. DN je tedy urˇceno cestou od koˇrene k z´aznamu.
Obr´azek 1: Pˇr´ıklad DIT
Na obr´azku 1 je pˇr´ıklad DIT fiktivn´ıho LDAP serveru example.com. Jednot- liv´e obd´eln´ıky pˇredstavuj´ı z´aznamy a jsou v nich veps´any RDN tˇechto z´aznam˚u.
Pro z´aznam identifikovan´y ve sv´e vˇetvi RDN cn=John bude DN vypadat n´asledovnˇe:
cn=John,ou=dep-A,dc=example,dc=com.
2.7 Bezpeˇ cnostn´ı model LDAP
Bezpeˇcnostn´ı model LDAP se star´a o ˇr´ızen´ı pˇr´ıstupu k adres´aˇrov´emu serveru. ˇReˇs´ı dva ´uzce spjat´e probl´emy a to autentizaci uˇzivatel˚u a jejich autorizaci.
2.7.1 LDAP autentizace
Autentizac´ı rozum´ıme ovˇeˇren´ı identity uˇzivatele, pˇristupuj´ıc´ıho k LDAP serveru.
Autentizace je ´uspˇeˇsn´a, pokud zadan´e DN odpov´ıd´a nˇejak´emu z´aznamu na tomto LDAP serveru a pokud tento z´aznam m´a atribut userPassword, kter´y obsahuje heslo.
To se mus´ı schodovat s heslem zadan´ym. Heslo je samozˇrejmˇe moˇzn´e ukl´adat v ˇsifrovan´e podobˇe.
Moˇznosti autentizace na LDAP serveru jsou variabiln´ı, mezi nejbˇeˇznˇejˇs´ı patˇr´ı:
• Anonymn´ı autentizace - pˇri navazov´an´ı spojen´ı (operace bind viz. kapitola 2.8) nejsou pˇren´aˇseny autentizaˇcn´ı ´udaje, pˇr´ıstup je tak umoˇznˇen komukoliv.
• Jednoduch´a autentizace - pˇri operaci bind se po nechr´anˇen´em kan´ale poˇsle DN a heslo uˇzivatele.
• Jednoduch´a autentizace pˇres zabezpeˇcen´y kan´al - stejnˇe jako v pˇredchoz´ım pˇr´ıpadˇe je pˇren´aˇseno DN uˇzivatele a jeho heslo, avˇsak v tomto pˇr´ıpadˇe po kan´ale, kter´y je zabezpeˇcen SSL nebo TLS [2]. Heslo je pˇren´aˇseno v nezmˇenˇen´e podobˇe i v pˇr´ıpadˇe, ˇze je na serveru uloˇzeno v podobˇe haˇse.
• Proxy autentizace - v tomto pˇr´ıpadˇe je vytvoˇren uˇzivatel, kter´y m´a pˇridˇeleno pr´avo ˇc´ıst hesla ostatn´ıch uˇzivatel˚u (viz. kapitola 2.7.2). Tento uˇzivatel pak pomoc´ı operace compare (viz. kapitola 2.8) prov´ad´ı autentizaci uˇzivatel˚u.
• Simple Authentication and Security Layer (SASL) [6] je vrstva, umoˇzˇnuj´ıc´ı autentizaci pomoc´ı jin´ych, na spojen´ı zaloˇzen´ych protokol˚u.
2.7.2 LDAP autorizace
Po ´uspˇeˇsn´e autorizaci uˇzivatele pˇrich´az´ı na ˇradu jeho autorizace. Ta se star´a o to, aby mˇel uˇzivatel pˇr´ıstup pouze k z´aznam˚um a atribut˚um, ke kter´ym pˇr´ıstup m´ıt m´a.
Pˇr´ıstupov´a pr´ava je moˇzno nastavit velmi flexibilnˇe. Na n´asleduj´ıc´ım v´ypisu je pˇr´ıklad nastaven´ı uˇzivatelsk´ych pr´av.
access to attr=userPassword by self =xw
by anonymous auth by * none
access to *
by self write by users read by * none
V´ypis zaˇc´ın´a kl´ıˇcov´ymi slovy access to, za nimi n´asleduje urˇcen´ı kter´eho z´aznamu, pˇr´ıpadnˇe atributu, se bude n´asleduj´ıc´ı definice pˇr´ıstupov´ych pr´av t´ykat. V prvn´ı ˇc´asti
tohoto pˇredpisu je ˇreˇsen pˇr´ıstup k atributu userPassword, ve druh´e je *, zastupuj´ıc´ı veˇsker´e z´aznamy na serveru.
N´asleduje by, za n´ımˇz urˇcujeme komu pˇr´ıstupov´a pr´ava pˇridˇelujeme. V tomto pˇr´ıpadˇe jsou pouˇzita kl´ıˇcov´a slova: self, tedy pˇr´ıstup pro DN patˇr´ıc´ı tomuto z´aznamu, anonymous pro anonymn´ı uˇzivatele, * pro vˇsechny uˇzivatele a users pro autentizovan´e uˇzivatele.
D´ale uˇz jsou konkr´etn´ı pˇr´ıstupov´a pr´ava. V naˇsem pˇr´ıpadˇe jsou pouˇzita auth pˇr´ıstupn´e pr´avo pro autentizaci, read lze pouze ˇc´ıst, write lze ˇc´ıst i zapisovat, none nelze ˇc´ıst ani zapisovat a =xw. Pr´avo =xw umoˇzˇnuje dan´y atribut ˇci objekt mˇenit, ale neumoˇzˇnuje jej ˇc´ıst.
2.8 Funkˇ cn´ı model LDAP
Funkˇcn´ı model LDAP se star´a o pˇr´ıstup k z´aznam˚um a o jejich modifikaci. K tomu pouˇz´ıv´a tˇri druhy operac´ı a to autentizaˇcn´ı operace, aktualizaˇcn´ı operace a dotazovac´ı operace. Tyto operace b´yvaj´ı pˇr´ımo obsaˇzeny v jednotliv´ych implementac´ıch LDAP server˚u.
Autentizaˇcn´ı operace, jak jiˇz napov´ıd´a n´azev, slouˇz´ı k pˇrihlaˇsov´an´ı uˇzivatel˚u. Jsou to pˇredevˇs´ım operace bind, slouˇz´ıc´ı k pˇrihl´aˇsen´ı uˇzivatele a unbind, kter´a se star´a naopak o odhl´aˇsen´ı uˇzivatele.
Aktualizaˇcn´ı a dotazovac´ı operace pak slouˇz´ı k manipulaci s daty. Mezi nejbˇeˇznˇejˇs´ı tyto operace patˇr´ı:
• add - pro pˇrid´av´an´ı nov´ych z´aznam˚u
• compare - pro porovn´av´an´ı z´aznam˚u
• delete - pro maz´an´ı st´avaj´ıc´ıch z´aznam˚u
• modify - pro zmˇenu st´avaj´ıc´ıch z´aznam˚u
• search - pro vyhled´av´an´ı z´aznam˚u
2.9 LDIF
LDAP Data Interchange Format, neboli LDIF [7] je standardizovan´y textov´y form´at urˇcen´y k popisov´an´ı z´aznam˚u na adres´aˇrov´em serveru. Tento textov´y form´at je velmi dobˇre ˇciteln´y pro ˇclovˇeka a tak usnadˇnuje pr´aci se z´aznamy. At’ uˇz jde o jejich vytv´aˇren´ı, editaci, maz´an´ı, nebo pˇrenos mezi r˚uzn´ymi LDAP servery. Adres´aˇrov´e servery totiˇz podporuj´ı jak import dat z tohoto form´atu, tak i export do nˇej.
Na n´asleduj´ıc´ım v´ypisu je pˇr´ıklad dat v textov´em form´atu LDIF.
dn: cn=John,ou=dep-A,dc=example,dc=com cn: John
givenName: John sn: Higgins
objectClass: inetOrgPerson objectClass: top
userPassword: {SSHA}36EZHdTOgqbYczBmZe8avOOkNavBcWd+
2.10 Kerberos
Kerberos [8] je s´ıt’ov´y autentizaˇcn´ı protokol. Je urˇcen´y pˇredevˇs´ım pro model klient- server. Obˇema stran´am umoˇzˇnuje bezpeˇcnˇe prok´azat svou identitu, respektive ovˇeˇrit identitu protistrany. Kromˇe toho zabraˇnuje odposlechnut´ı komunikace, jej´ı zopakov´an´ı a zaruˇcuje integritu dat.
Kerberos byl vyvinut na Massachusetts Institute of Technology (MIT) v r´amci pro- jektu Athena. Pojmenov´an je po m´ytick´em ˇreck´em trojhlav´em psu stˇreˇz´ıc´ım br´anu do podsvˇet´ı.
Protokol Kerberos je zaloˇzen na symetrick´e kryptografii a vyˇzaduje d˚uvˇeryhodnou tˇret´ı stranu, Key Distribution Center (KDC). KDC se skl´ad´a ze dvou celk˚u, jimiˇz jsou Authentication Service (AS) a Ticket-Granting Server (TGS). K ˇsifrov´an´ı komunikace pouˇz´ıv´a symetrickou blokovou ˇsifru Advanced Encryption Standard (AES) [9].
Kerberos pouˇz´ıv´a tikety, kter´e slouˇz´ı k prok´az´an´ı totoˇznosti jednotliv´ych uzl˚u.
Kaˇzd´y ´uˇcastn´ık komunikace m´a sv˚uj tajn´y kl´ıˇc, kter´y je uloˇzen v datab´azi KDC. Pr´avˇe
na z´akladˇe znalosti tohoto kl´ıˇce je ovˇeˇrov´ana identita uzlu. Pro ´uˇcely komunikace mezi jednotliv´ymi uzly generuje KDC kl´ıˇc relace (session key), kter´ym svou komunikaci uzly ˇsifruj´ı.
Pokud chce klient pˇristoupit k nˇejak´e sluˇzbˇe nejprve se autentizuje u AS pomoc´ı sd´ılen´eho tajn´eho kl´ıˇce (zadan´eho hesla) a obdrˇz´ı tiket, pot´e m˚uˇze pomoc´ı toho tiketu poˇz´adat o pˇr´ıstup ke sluˇzbˇe u TGS, od kter´eho obdrˇz´ı dalˇs´ı tiket slouˇz´ıc´ı ke komunikaci se serverem sluˇzby. Pomoc´ı tiketu obdrˇzen´eho od AS m˚uˇze u TGS ˇz´adat o pˇr´ıstup k v´ıce r˚uzn´ym sluˇzb´am, pro kaˇzdou tuto sluˇzbu pak obdrˇz´ı od TGS tiket. Podrobnˇeji jsou jednotliv´e f´aze pops´any v kapitole 2.10.1.
2.10.1 Zah´ajen´ı komunikace
Zah´ajen´ı Kerberos komunikace se skl´ad´a ze ˇctyˇr f´az´ı. Ani pˇri jedn´e z nich nen´ı pos´ıl´ano heslo komunikuj´ıc´ıho uzlu po s´ıti. Sch´ema komunikace je na obr´azku 2.
Prvn´ı f´az´ı je login uˇzivatele. Ten prob´ıh´a pouze lok´alnˇe na klientsk´em poˇc´ıtaˇci, kde uˇzivatel zad´a identifik´ator a heslo. N´aslednˇe je na vloˇzen´em hesle provedena haˇsovac´ı funkce. V´ystup z n´ı je pak tajn´ym kl´ıˇcem klienta (K1).
Druhou f´az´ı je autentizace uˇzivatele. V t´eto f´azi jiˇz prob´ıh´a komunikace po s´ıti.
Nejprve klient odeˇsle AS nezaˇsifrovanou ˇz´adost obsahuj´ıc´ı jeho identifik´ator. Podle toho AS vyhled´a uˇzivatele v datab´azi. Pokud jej nalezne, odeˇsle mu dvˇe zpr´avy:
• Zpr´avu A obsahuj´ıc´ı klient-TGS kl´ıˇc (K2), zaˇsifrovanou K1.
• Zpr´avu B obsahuj´ıc´ı Ticket-Granting Ticket (TGT), v nˇemˇz je identifik´ator a adresa klienta, dobu platnosti tiketu a K2. TGT je zaˇsifrov´an tajn´ym kl´ıˇcem TGS (K3).
Po obdrˇzen´ı zpr´av se klient nejprve pokus´ı rozˇsifrovat zpr´avu A a to kl´ıˇcem K1.
V pˇr´ıpadˇe ˇze uˇzivatel zadal chybn´e heslo, se nepodaˇr´ı zpr´avu deˇsifrovat. V opaˇcn´em pˇr´ıpadˇe pak z´ısk´a K2. TGT ze Zpr´avy B nen´ı klient schopen deˇsifrovat, ale tento tiket je pouˇzit v n´asleduj´ıc´ı f´azi.
N´asleduje tˇret´ı f´aze, autorizace pˇr´ıstupu ke sluˇzbˇe. Klient ˇz´ad´a TGS o pˇr´ıstup
• Zpr´avy C kter´a obsahuje TGT a identifik´ator poˇzadovan´e sluˇzby.
• Zpr´avy D obsahuj´ıc´ı identifik´ator klienta a ˇcasovou znaˇcku, zpr´ava je ˇsifrov´ana K2.
TGS pomoc´ı kl´ıˇce K3 rozˇsifruje TGT a z´ısk´a tak K2. T´ım rozˇsifruje zpr´avu D a z´ısk´a tak identifik´ator klienta a ˇcasovou zn´amku. Pak poˇsle klientovi dvˇe zpr´avy:
• Zpr´avu E jenˇz obsahuje klient-server tiket, obsahuj´ıc´ı identifik´ator a adresu klienta, dobu platnosti tiketu a klient-server kl´ıˇc (K4). Klient-server tiket je zaˇsifrov´an tajn´ym kl´ıˇcem sluˇzby (K5).
• Zpr´avu F kter´a obsahuje K4 a je zaˇsifrov´ana kl´ıˇcem K2.
Posledn´ı f´az´ı je ˇz´adost klienta o sluˇzbu. Ten se po obdrˇzen´ı zpr´av E a F spoj´ı s aplikaˇcn´ım serverem a tomu odeˇsle opˇet dvˇe zpr´avy:
• Zpr´avu E, tedy zpr´avu kterou pˇredt´ım obdrˇzel od TGS.
• Zpr´avu G ta je podobn´a zpr´avˇe D, obsahuje identifik´ator klienta a ˇcasovou znaˇcku.
Zpr´ava je ˇsifrov´ana kl´ıˇcem K4.
Aplikaˇcn´ı server deˇsifruje pomoc´ı K5 zpr´avu E. Tak z´ısk´a K4, t´ım deˇsifruje zpr´avu G.
Pro potvrzen´ı sv´e identity pak server odeˇsle n´asleduj´ıc´ı zpr´avu:
• Zpr´avu H obsahuj´ıc´ı inkrementovanou ˇcasovou znaˇcku ze zpr´avy G. Zpr´ava H je zaˇsifrov´ana kl´ıˇcem K4.
Zpr´avu H klient deˇsifruje. Pokud ˇcasov´a znaˇcka souhlas´ı, server je d˚uvˇeryhodn´y.
Mezi klientem a serverem pak prob´ıh´a bˇeˇzn´a komunikace. Tato komunikace je ˇsifrov´ana klient-server kl´ıˇcem. Jednotliv´e zpr´avy jsou ilustrov´any na obr´azku 3.
Aby Kerberos fungoval spr´avnˇe, je nutn´a ˇcasov´a synchronizace ´uˇcastn´ık˚u komu- nikace. Rozd´ıl mezi jednotliv´ymi ´uˇcastn´ıky nesm´ı b´yt v´ıc neˇz 5 minut. D´ale je nutn´y nepˇretrˇzit´y provoz KDC. Hlavn´ı KDC proto b´yv´a duplikov´ano na jin´e servery, takzvan´e ,,slave“ servery, kter´e jej zastoup´ı v pˇr´ıpadˇe v´ypadku. Jelikoˇz KDC zaruˇcuje identitu komunikuj´ıc´ıch stran, mus´ı b´yt samo o sobˇe dobˇre zabezpeˇceno.
Uživatel
Kerberos server
Aplikační server Klient
Authentication Service Zpráva A: K2 (šifrováno K1)
Provedení hašovací funkce na heslu (K1)
Zadání id a hesla
Vyheldání uživatel podle ID Žádost o autentizaci:
id (nešifrováno)
Ticket-Granting Server Zpráva C: TGT + id služby
Zpráva D: id klienta + časová značka (šifrováno K2)
Zpráva E: klient-server ticket (šifrován K5) Zpráva B: TGT (šifrován K3)
Zpráva F: K4 (šifrováno K2) Dešifrování zprávy A
pomocí K1, získá K2
Dešifrování zprávy F pomocí K2, získá K4
Pomocí K3 dešifruje TGT, získá K2 tím rozšifruje zprávu D Zpráva E
Zpráva G: id klienta +časová značka
(šifrováno K4) Pomocí K5 dešifruje
zprávu E, získá K4
tím rozšifruje zprávu G Zpráva H:
časová značka (šifrováno K4)
Obr´azek 2: V´ymˇena zpr´av pˇri Kerberos autentizaci
Žádost o autenizaci (klient->AS) Identifikátor uživatele
Zpráva A (AS->klient) klient-TGS klíč {Tajný klíč klienta}
Zpráva B (AS->klient)
{Tajný klíč TGS}
Zpráva C (klient->TGS)
TGT (ID a adresa klienta,
doba patnosti, klient-TGS klíč) TGT
{Tajný klíč TGS}
Zpráva D (klient->TGS)
ID Klienta
{klient-TGS klíč}
Zpráva F (TGS->klient)
Zpráva E (TGS->klient, klient->server služby)
klient-server ticket (ID a adresa klienta,
doba patnosti, klient-server klíč) {Tajný klíč služby}
{klient-TGS klíč}
ID Klienta Zpráva G (klient->server služby)
klient-server klíč
{klient-server klíč}
Zpráva H (server služby->klient)
inkrementovaná časová známka časová známka
časová známka
{klient-server klíč}
ID služby
Obr´azek 3: Sch´emata jednotliv´ych zpr´av, kl´ıˇc pouˇzit´y k ˇsifrov´an´ı zpr´avy je ve sloˇzen´ych z´avork´ach
3 LDAP a Kerberos servery
Tato kapitola pojedn´av´a o OpenSource implementac´ıch LDAP a Kerberos ser- ver˚u. Je v n´ı tak´e zd˚uvodnˇena volba implementac´ı vybran´ych pro testov´an´ı ovˇeˇrov´an´ı uˇzivatele Verse serveru proti LDAP serveru a Kerberos serveru. Implementacemi LDAP a Kerberos server˚u jsem se jiˇz zab´yval v r´amci sv´eho Magistersk´eho projektu.
3.1 LDAP servery
V t´eto ˇc´asti se nach´az´ı reˇserˇse OpenSource implementac´ı LDAP server˚u.
3.1.1 389 Directory Server
389 Directory Server je vyv´ıjen firmou Red Hat [10]. Podporuje SSL verze 3, TLS verze 1 a SASL. Umoˇzˇnuje tak´e replikaci server˚u. Dok´aˇze vykonat ˇr´adovˇe tis´ıce ope- rac´ı za sekundu, obsluhovat desetitis´ıce uˇzivatel˚u z´aroveˇn a udrˇzovat des´ıtky mili´on˚u z´aznam˚u. Je distribuov´an pod licenc´ı General Public License version 3 (GPLv3) [11].
3.1.2 Apache Directory
Apache Directory je naprogramov´an v jazyce Java, vyv´ıj´ı jej Apache Software Foun- dation [12]. Podporuje Kerberos V5. Klade si za c´ıl zav´est do svˇeta LDAP triggery, uloˇzen´e procedury a pohledy zn´am´e z relaˇcn´ıch datab´az´ı. Je poskytov´an s licenc´ı Apache License, Version 2.0 [13].
3.1.3 OpenDS
OpenDS byl vyv´ıjen firmou Sun Microsystems. Po jej´ım z´aniku je vyv´ıjen komu- nitnˇe. Je navrˇzen tak, aby dok´azal obs´ahnout velk´a nasazen´ı, poskytoval vysok´y v´ykon, byl snadno rozˇsiˇriteln´y a lehce zavediteln´y. OpenDS je rozˇsiˇrov´an s licenc´ı Common Development and Distribution License (CDDL) [14].
3.1.4 OpenLDAP
OpenLDAP je poskytov´an pod OpenLDAP licenc´ı [15], podobnou BSD licenci.
Vyv´ıj´ı jej OpenLDAP Foundation [16] a je naprogramov´an v jazyce C. Jedn´a se v souˇcasn´e dobˇe o nejrozˇs´ıˇrenˇejˇs´ı LDAP server. Nab´ız´ı ˇsirok´e moˇznosti konfigurace a velmi detailn´ı manu´al. Je vhodn´y tak´e proto, ˇze je moˇzn´e k nˇemu na webu naj´ıt velk´e mnoˇzstv´ı n´avod˚u a tutori´al˚u.
Tato implementace byla vybr´ana pro praktick´e testov´an´ı ovˇeˇren´ı uˇzivatele Verse serveru proti LDAPu. D˚uvod˚u pro v´ybˇer t´eto implementace bylo nˇekolik, pˇredevˇs´ım je to velk´a komunita uˇzivatel˚u OpenLDAP. D´ıky tomu se v pˇr´ıpadˇe nˇejak´eho probl´emu l´epe sh´an´ı informace. Dalˇs´ım d˚uvodem je pˇr´ıtomnost t´eto implementace ve standardn´ıch reposit´aˇr´ıch linuxov´ych distribuc´ı.
3.1.5 Komerˇcn´ı LDAP servery
Kromˇe OpenSource implementac´ı existuje i mnoho komerˇcn´ıch implementac´ı. Jsou jimi napˇr. Open Directory od firmy Apple, Active Directory od Microsoftu, eDirectory od Novellu a Oracle Internet Directory od firmy Oracle.
3.2 Kerberos Servery
Tato ˇc´ast pr´ace se vˇenuje OpenSource implementac´ım Kerberos serveru.
3.2.1 MIT Kerberos
MIT Kerberos je vyv´ıjen na Massachusetts Institute of Technology (MIT). Do jeho v´yvoje vˇsak pˇrispˇely i komerˇcn´ı firmy jako: Cygnus Support, Novell, OpenVision Tech- nologies, Oracle, Red Hat, Sun Microsystems a FundsXpress. Pˇresto m´a velmi svobod- nou licenci, umoˇzˇnuj´ıc´ı voln´e uˇz´ıv´an´ı, kop´ırov´an´ı i redistribuci [17].
Tato implementace byla vybr´ana pro praktick´e testov´an´ı ovˇeˇren´ı uˇzivatel˚u Verse ser- veru proti Kerberos serveru jakoˇzto nejˇcastˇeji pouˇz´ıvan´a implementace. Dalˇs´ı v´yhodou je, ˇze je vyv´ıjena na MIT stejnˇe jako protokol Kerberos.
3.2.2 Heimdal
Heimdal je implementace Kerberos vyv´ıjen´a pˇrev´aˇznˇe ve ˇSv´edsku. Je poskytov´an pod BSD-like licenc´ı [18].
3.2.3 Komerˇcn´ı Kerberos servery
Podobnˇe jako v pˇr´ıpadˇe LDAP server˚u existuj´ı i komerˇcn´ı implementace Kerberos server˚u. Pˇr´ıkladem mohou b´yt implementace od firem CyberSafe a Microsoft.
4 Knihovny implementuj´ıci LDAP a Kerberos
V t´eto ˇc´asti pr´ace je obsaˇzena reˇserˇse knihoven umoˇzˇnuj´ıc´ıch implementaci klientsk´e aplikace pro ovˇeˇrov´an´ı proti LDAP serveru a Kerberos serveru.
4.1 Spring LDAP
Spring LDAP je knihovna, kter´a poskytuje zjednoduˇsen´y r´amec operac´ı LDAP.
Je naprogramov´ana v jazyce Java. Vyv´ıj´ı ji SpringSource [19], jeˇz je diviz´ı VMware [20].
Na str´ank´ach knihovny je k dispozici kompletn´ı dokumentace [21]. Knihovna je distri- buov´ana pod licenc´ı Apache License Version 2.0 [13].
4.2 Python-ldap
Knihovna Python-ldap poskytuje objektovˇe orientovan´e API slouˇz´ıc´ı k pˇr´ıstupu k LDAP server˚um z program˚u psan´ych v jazyce Python. Z velk´e ˇc´asti se jedn´a o obalo- vou knihovnu knihovny OpenLDAP viz. 4.4. Knihovna je poskytov´ana pod Python-style licenc´ı [22].
4.3 Perl LDAP
Knihovna Perl LDAP je kolekce Perl modul˚u, kter´e poskytuj´ı objektovˇe oriento- van´e API urˇcen´e k interakci s LDAP serverem. Vˇsechny moduly jsou ps´any kompletnˇe v Jazyce Perl. To ˇcin´ı Perl LDAP nez´avisl´ym na platformˇe. Na str´ank´ach knihovny se nach´az´ı kompletn´ı dokumentace [23]. Perl LDAP je poskytov´an s licenc´ı GPLv3 [11].
4.4 OpenLDAP
OpenLDAP poskytuje kromˇe implementace LDAP serveru tak´e klientsk´e API pro komunikace se serverem. Kromˇe kompletn´ı implementace LDAP obsahuje i funkce umoˇzˇnuj´ıc´ı autentizaci proti Kerberos serveru. Jinak o knihovnˇe OpenLDAP plat´ı to sam´e co o implementaci serveru OpenLDAP viz. 3.1.4. Tato knihovna byla vybr´ana pro implementaci ovˇeˇren´ı Verse serveru proti LDAPu. Mezi d˚uvody v´ybˇeru t´eto
knihovny patˇr´ı svobodn´a licence, implementace v jazyce C a pˇr´ıtomnost ve standardn´ıch reposit´aˇr´ıch linuxov´ych distribuc´ı.
4.5 MIT Kerberos
Tak´e MIT Kerberos obsahuje knihovnu, slouˇz´ıc´ı jako API umoˇzˇnuj´ıc´ı kerberizaci klientsk´e aplikace. Knihovna je poskytov´ana pod stejnou licenc´ı jako implementace serveru, viz. 3.2.1. Tato knihovna byla vybr´ana pro implementaci ovˇeˇren´ı Verse serveru proti Kerberos serveru. A to ze stejn´ych d˚uvod˚u jako knihovna OpenLDAP tedy d´ıky svobodn´e licenci, implementaci v jazyce C a pˇr´ıtomnosti ve standardn´ıch reposit´aˇr´ıch linuxov´ych distribuc´ı.
5 Ovˇ eˇ ren´ı Verse serveru proti LDAPu
Tato ˇc´ast pr´ace popisuje vlastn´ı implementaci ovˇeˇrov´an´ı uˇzivatel˚u Verse serveru proti LDAPu. Obsahuje tak´e popis nˇekter´ych zmˇen, kter´e bylo nutn´e ve Verse serveru, v souvislosti s touto implementac´ı udˇelat.
Samotn´y verse protokol je moˇzn´e z´ıskat z adresy https://github.com/verse/verse, verze implementuj´ıc´ı podporu autentizace uˇzivatel˚u proti LDAPu a Kerberos serveru se nach´az´ı na pˇriloˇzen´em CD a na https://github.com/zdenek-perutka/verse. Postup kompilace je pops´an v pˇr´ıloze a tak´e na v´yˇse zm´ınˇen´em webu.
Jelikoˇz je knihovna Verse protokolu implementov´ana v jazyce C, k vlastn´ı implemen- taci nov´ych autentizaˇcn´ıch metod bylo nutn´e pouˇz´ıt tento programovac´ı jazyk. Jeˇstˇe pˇred zapoˇcet´ım implementace bylo nutn´e zmˇenit soubry CMakeLists.txt, tak aby se Cross-Platform Makefile Generator (CMake) pokusil nal´ezt knihovny OpenLDAP a MIT Kerberos, a aby v pˇr´ıpadˇe jejich nalezen´ı byly zdrojov´e k´ody knihovny Verse pˇri pˇrekladu slinkov´any s tˇemito knihovnami.
Pˇri implementaci bylo nutn´e udˇelat zmˇeny pouze na stranˇe serveru. Na stranˇe klienta nehraje roli, je-li pouˇzita LDAP autentizace.
5.1 P˚ uvodn´ı uˇ zivatelsk´ e ´ uˇ cty Verse
P˚uvodnˇe Verse server naˇc´ıtal uˇzivatelsk´e ´uˇcty pouze ze souboru form´atu CSV.
Soubor byl naˇcten pˇri startu Verse serveru. Informace z nˇej naˇcten´e byly uloˇzeny do struktury VSUser. Ta je definov´ana v souboru vs user.h a slouˇz´ı pr´avˇe k uchov´av´an´ı uˇzivatelsk´ych ´uˇct˚u. Server si tyto ´uˇcty uchov´av´a ve spojov´em seznamu.
5.2 Uprava datov´ ´ ych struktur
Kv˚uli implementaci ovˇeˇrov´an´ı Verse serveru proti LDAPu bylo nutn´e rozˇs´ıˇrit nˇekter´e datov´e struktury. Mezi nimi pr´avˇe strukturu VSUser. Do n´ıˇz byl pˇrid´an atribut ldap dn, uchov´avaj´ıc´ı rozliˇsuj´ıc´ı jm´eno uˇzivatele na LDAP serveru, viz. kapitola 2.6.1. Rozˇs´ıˇren byl t´eˇz kontext Verse serveru, struktura VS CTX, ze souboru vs main.h. Ta byla rozˇs´ıˇrena celkem o pˇet atribut˚u. A to ldap hostname obsahuj´ıc´ı adresu LDAP serveru,
ldap user s uˇzivatelsk´ym jm´enem Verse serveru na LDAPu a ldap passwd s jeho hes- lem. D´ale ldap search base, tento atribut urˇcuje na jak´e ˇc´asti serveru bude prob´ıhat vyhled´av´an´ı uˇzivatel˚u, a nakonec ldap version urˇcuj´ıc´ı pouˇz´ıvanou verzi LDAPu.
5.3 Naˇ cten´ı uˇ zivatel˚ u z LDAP serveru
Naˇcten´ı uˇzivatelsk´ych ´uˇct˚u z LDAP serveru prob´ıh´a podobnˇe jako z CSV souboru pˇri startu serveru. Verse server se nejprve pˇrihl´as´ı sv´ym uˇzivatelsk´ym jm´enem k LDAP serveru a pot´e se jej dot´aˇze na seznam uˇzivatel˚u. Po obdrˇzen´ı seznamu tento seznam projde a informace o uˇzivatel´ıch uloˇz´ı do pˇr´ısluˇsn´ych struktur. Uˇzivatel reprezentuj´ıc´ı Verse server na LDAP serveru mus´ı m´ıt nastaveno pr´avo ˇc´ıst informace o ostatn´ıch uˇzivatel´ıch, viz. kapitola 2.7.2. Veˇsker´e nov´e funkce slouˇz´ıc´ı k ovˇeˇrov´an´ı uˇzivatel˚u Verse serveru proti LDAPu byly um´ıstˇeny do souboru vs auth ldap.c.
int vs_load_user_accounts_ldap_server(VS_CTX *vs_ctx)
Z´ısk´an´ı uˇzivatelsk´ych ´uˇct˚u z LDAP serveru je implementov´ano ve funkci vs load user accounts ldap server, hlaviˇcka na v´ypisu v´yˇse. Ta m´a jako jedin´y parametr kontext Verse serveru. V pˇr´ıpadˇe ´uspˇechu vrac´ı 1, jinak vrac´ı ˇc´ıslo chyby.
Zde je nejprve pomoc´ı funkce ldap initialize zinicializov´an kontext knihovny LDAP a funkce ldap set option nastav´ı poˇzadovanou verzi protokolu LDAP. Pomoc´ı funkce ldap sasl bind s se Verse server pokus´ı pˇrihl´asit k LDAP serveru. O odesl´an´ı do- tazu na LDAP server se postar´a funkce ldap search ext s. Verse server se tak dot´aˇze na seznam uˇzivatel˚u, kter´y obdrˇz´ı ve struktuˇre LDAPMessage. Pot´e je vol´ana funkce vs add users from ldap message, jeˇz se postar´a o vytˇeˇzen´ı informac´ı o jednotliv´ych uˇzivatel´ıch a jejich uloˇzen´ı do pˇr´ısluˇsn´ych struktur.
int vs_add_users_from_ldap_message(struct VS_CTX *vs_ctx, LDAP *ldap, LDAPMessage *ldap_message)
Do funkce vstupuje kontext Verse server, kontext knihovny LDAP a struk- tura LDAPMessage, jeˇz obsahuje zpr´avu se seznamem uˇzivatel˚u. Vr´acen je poˇcet
uˇzivatelsk´ych ´uˇct˚u pˇridan´ych do Verse serveru. ˇCinnost funkce je zn´azornˇena na obr´azku 4.
ldap_message
ldap_entry = ldap_next_entry(ldap, ldap_entry)
user = user->next
user != NULL
user->user_id
==
new_user->user_id
user->username
==
new_user->username ldap_entry != NULL
v_list_add_tail(&vs_ctx->users, new_user) count++
return count
+
-
+
+
+ -
-
-
ldap_entry = ldap_first_entry(ldap, ldap_message) count = 0
user_dn = (char *) ldap_get_dn(ldap, ldap_entry) new_user->ldap_dn = user_dn
user = vs_ctx->users.first
Obr´azek 4: Funkce vs add users from ldap message
Funkce nejprve proch´az´ı jednotliv´e z´aznamy ze zpr´avy od LDAP serveru. Z kaˇzd´eho z´aznamu vytˇeˇz´ı informace o uˇzivatelsk´em ´uˇctu jako jsou uˇzivatelsk´e jm´eno, identifikaˇcn´ı
serveru a porovn´av´a z´ıskan´e uˇzivatelsk´e jm´eno a identifikaˇcn´ıˇc´ıslo s uˇzivatelsk´ymi jm´eny a hesly jiˇz existuj´ıc´ıch uˇzivatel˚u. Pokud se uˇzivatelsk´e jm´eno nebo identifikaˇcn´ı ˇc´ıslo shoduje se jm´enem nebo identifikaˇcn´ım ˇc´ıslem jiˇz existuj´ıc´ıho uˇzivatele, uˇzivatelsk´y
´
uˇcet nem˚uˇze b´yt pˇrid´an. V opaˇcn´em pˇr´ıpadˇe funkce pˇrid´a tohoto uˇzivatele do seznamu uˇzivatel˚u Verse serveru.
5.4 Ovˇ eˇ ren´ı uˇ zivatele proti LDAPu
Pˇri pokusu o autentizaci klient odeˇsle svoje uˇzivatelsk´e jm´eno a heslo Verse serveru.
Ten se pokus´ı nal´ezt uˇzivatele ve sv´em seznamu. Pokud ho nalezne, pokus´ı se pomoc´ı dan´eho jm´ena a hesla pˇrihl´asit k LDAP serveru. V pˇr´ıpadˇe ´uspˇeˇsn´eho pˇrihl´aˇsen´ı je kli- ent autentizov´an k pˇr´ıstupu na Verse server, viz. obr´azek 5. Toto obstar´av´a funkce vs ldap auth user. Ta m´a jako parametry vContext, uˇzivatelsk´e jm´eno a heslo. Funkce vrac´ı identifikaˇcn´ı ˇc´ıslo uˇzivatele a v pˇr´ıpadˇe ne´uspˇechu -1. Na n´asleduj´ıc´ım v´ypisu je hlaviˇcka funkce.
int vs_ldap_auth_user(struct vContext *C, const char *username, const char *pass)
Verse klient Verse server LDAP server
Žádost o autentizaci (jméno + heslo)
Vyhledání uživatele dle jména
Žádost o autentizaci (jméno + heslo)
Autentizace OK
Autentizace OK +UID
Obr´azek 5: Ovˇeˇren´ı uˇzivatele proti LDAPu
5.5 Obnoven´ı seznamu uˇ zivatel˚ u
Na Verse serveru bylo tak´e implementov´ano naˇc´ıt´an´ı novˇe pˇridan´ych uˇzivatel˚u za bˇehu serveru. Naˇc´ıt´an´ı nov´ych uˇzivatel˚u je implementov´ano pro naˇc´ıt´an´ı z LDAP serveru i ze souboru CSV. Spust´ı se, pokud je serveru posl´an sign´al SIGUSR1.
O obsluhu sign´al˚u se star´a funkce vs handle signal volaj´ıc´ı funkce obsluhuj´ıc´ı konkr´etn´ı sign´aly. V pˇr´ıpadˇe sign´alu SIGUSR1 vol´a novˇe implementovanou funkci vs reload user accounts. Obˇe tyto funkce se nach´az´ı v souboru vs main.c.
Funkce vs reload user accounts vol´a podle zvolen´e autentizaˇcn´ı metody konkr´etn´ı funkci naˇc´ıtaj´ıc´ı uˇzivatelsk´e ´uˇcty. V pˇr´ıpadˇe LDAP autentizace je to funkce vs load user accounts ldap server popsan´a v kapitole 5.3.
5.6 Zmˇ ena rozhran´ı pro odchyt´ av´ an´ı sign´ al˚ u
Aby naˇcten´ı nov´ych uˇzivatel˚u po obdrˇzen´ı sign´alu fungovalo, bylo nutn´e zmˇenit rozhran´ı pro odchyt´av´an´ı sign´al˚u. V p˚uvodn´ı implementaci Verse serveru je pouˇzito rozhran´ı signal. Toto rozhran´ı je vˇsak nevhodn´e pro v´ıcevl´aknov´e aplikace.
Pouˇzito tedy bylo robustnˇejˇs´ı rozhran´ı sigaction. Odchyt´av´an´ı sign´al˚u je nastaveno funkc´ı vs config signal handling. Nejprve jsou pomoc´ı sigaction nastaveny odchyt´avan´e sign´aly a funkce obsluhuj´ıc´ı tyto sign´aly, tedy vs handle signal. Pot´e je vytvoˇreno nov´e vl´akno, v nˇemˇz jsou sign´aly odchyt´av´any. Ty jsou nakonec zablokov´any pro ostatn´ı vl´akna pomoc´ı pthread sigmask.
Ve vl´aknu pro zpracov´an´ı sign´al˚u bˇeˇz´ı funkce vs signal thread. Tato funkce pouze ˇcek´a na sign´al. V pˇr´ıpadˇe jeho obdrˇzen´ı je spuˇstˇena funkce nastaven´a pomoc´ı rozhran´ı sigaction.
5.7 Naˇ c´ıt´ an´ı uˇ zivatele pˇ ri pokusu o pˇ rihl´ aˇ sen´ı
Z d˚uvodu sn´ıˇzen´ı z´atˇeˇze Verse serveru pˇri startu, byla pˇrid´ana moˇznost naˇc´ıt´an´ı jednotliv´ych uˇzivatelsk´ych ´uˇct˚u z LDAP serveru aˇz pˇri pokusu o pˇrihl´aˇsen´ı uˇzivatele.
Uˇzivatelsk´a jm´ena takto vytvoˇren´ych uˇzivatel˚u jsou ukl´ad´ana do CSV souboru.
Pˇri dalˇs´ım spuˇstˇen´ı Verse serveru jsou tak naˇc´ıt´any pouze uˇzivatelsk´e ´uˇcty, k nimˇz
se v minulosti nˇekdo pokusil pˇripojit.
K naˇcten´ı tˇechto uˇzivatelsk´ych ´uˇct˚u slouˇz´ı funkce vs load saved ldap users. Proch´az´ı CSV soubor a podle uˇzivatelsk´eho jm´ena se pokus´ı vyhledat ´uˇcet na LDAP ser- veru. Toto vyhled´av´an´ı prov´ad´ı funkce vs ldap add concrete user. Ta je podobn´a funkci vs load user accounts ldap server popsan´e v kapitole 5.3 s t´ım rozd´ılem, ˇze vyhled´av´a pouze jednoho konkr´etn´ıho uˇzivatele.
Pˇri samotn´em pokusu o pˇrihl´aˇsen´ı je vol´ana funkce vs ldap auth and add user.
Ta se nejprve pokus´ı prov´est bˇeˇznou autentizaci pomoc´ı funkce vs ldap auth user popsan´e v kapitole 5.4. Pokud autentizace selˇze, pokus´ı se pˇridat uˇzivatele pomoc´ı funkce vs ldap add concrete user. Pokud je uˇzivatel ´uspˇeˇsnˇe pˇrid´an, znovu se pokus´ı o bˇeˇznou autentizaci, viz. obr´azek 6. V pˇr´ıpadˇe selh´an´ı funkce vs ldap add concrete user a v pˇr´ıpadˇe zad´an´ı chybn´ych pˇrihlaˇsovac´ıch ´udaj˚u funkce vs ldap auth and add user vrac´ı -1. N´avratov´a promˇenn´a uid je totiˇz nastavov´ana pomoc´ı funkce vs ldap auth user, kter´a ji v pˇr´ıpadˇe zad´an´ı chybn´ych pˇrihlaˇsovac´ıch ´udaj˚u nastav´ı na -1.
vContext *C char *username char *pass
int uid = vs_ldap_auth_user(C, username, pass)
uid = vs_ldap_auth_user(C, username, pass) vs_ldap_add_concrete_user
(CTX_server_ctx(C), username, "cn=")
uid return uid
1 -1
else
else
Obr´azek 6: Funkce vs ldap auth and add user
6 Kerberizace Verse protokolu
V t´eto ˇc´asti je pops´ana implementace ovˇeˇrov´an´ı uˇzivatel˚u Verse serveru proti Ker- beru a d´ale n´asledn´a kerberizace knihovny Verse protokolu. Na rozd´ıl od implementace ovˇeˇren´ı proti LDAPu bylo potˇreba zmˇenit jak serverovou, tak klientskou ˇc´ast protokolu a t´eˇz upravit vzorovou klientskou aplikaci.
6.1 Uprava datov´ ´ ych struktur
Podobnˇe jako v pˇr´ıpadˇe LDAPu bylo nutn´e upravit nˇekter´e datov´e struktury.
Pˇredevˇs´ım strukturu obsahuj´ıc´ı informace nutn´e pro pˇrij´ım´an´ı a odes´ıl´an´ı paket˚u. Je to struktura IO CTX, kter´a je definov´ana v souboru v network.h. Na n´asleduj´ıc´ım v´ypisu jsou atributy, jeˇz byly novˇe pˇrid´any t´eto struktury.
typedef struct IO_CTX {
unsigned short use_kerberos;
krb5_keytab krb5_keytab;
krb5_principal krb5_principal;
krb5_context krb5_ctx;
krb5_ccache krb5_cc;
krb5_auth_context krb5_auth_ctx;
krb5_ticket *krb5_ticket;
}
K jiˇz existuj´ıc´ım atribut˚um byli pˇrid´any dalˇs´ı atributy potˇrebn´e k autentizaci proti Kerberos serveru a n´asledn´e kerberizaci verse protokolu. Byly to use kerberos, urˇcuj´ıc´ı zda je Kerberos aktu´alnˇe pouˇz´ıv´an. Pokud ano, tento atribut m´a hodnotu 1. Atribut krb5 keytab odkazuj´ıc´ı na keytab soubor, v nˇemˇz je uloˇzen tajn´y kl´ıˇc sluˇzby viz. 2.10.1.
D´ale krb5 principal obsahuj´ıc´ı informace o Kerberos uˇzivateli, krb5 ctx coˇz je kontext Kerberos knihovny. Atribut krb5 cc reprezentuj´ıc´ı lok´aln´ı ´uloˇziˇstˇe kl´ıˇc˚u, krb5 auth ctx kontext aktu´aln´ıho Kerberos spojen´ı. A nakonec krb5 ticket ve kter´em jsou informace o tiketu.
Atribut use kerberos byl tak´e pˇrid´an jak do struktury VC CTX reprezentuj´ıc´ı stav Verse klienta definovan´e v souboru vc main.h, tak do obdobn´e struktury slouˇz´ıc´ı serveru VS CTX definovan´e v vs main.h.
6.2 Nav´ az´ an´ı spojen´ı a autentizace uˇ zivatele
Pˇri nav´az´an´ı spojen´ı je nutn´e, aby byl na Verse serveru soubor keytab obsahuj´ıc´ı tajn´y kl´ıˇc sluˇzby. Verse server pak naslouch´a na dan´em portu a ˇcek´a na zpr´avu od kli- enta, jeˇz obsahuje klient-server tiket viz. 2.10.1. Pot´e Verse server projde sv˚uj seznam uˇzivatel˚u a pokud nalezne uˇzivatele autentizovan´eho Kerberem, odeˇsle klientovi zpr´avu o ´uspˇeˇsn´e autentizaci, kter´a je jiˇz ˇsifrov´ana pomoc´ı klient-server kl´ıˇce. Klient tak m˚uˇze komunikovat s Verse serverem. Pokud uˇzivatel nebyl nalezen v seznamu uˇzivatel˚u Verse serveru, ten odeˇsle opˇet ˇsifrovanou zpr´avu tentokr´at o tom, ˇze autentizace probˇehla ne´uspˇeˇsnˇe.
Verse klient obstar´av´a veˇskerou komunikaci s Kerberos serverem. Pˇr´ımo v r´amci klientsk´e aplikace je nutn´e vykonat prvn´ı dvˇe f´aze Kerberos autentizace: zad´an´ı hesla na nˇemˇz je vykon´ana haˇsovac´ı funkce a odesl´an´ı neˇsifrovan´e ˇz´adosti o autentizaci Ker- beros serveru. Server mu odeˇsle zpr´avu obsahuj´ıc´ı i kl´ıˇc pro dalˇs´ı komunikaci viz.
2.10.1. Pokud bylo zad´ano spr´avn´e heslo, klient zpr´avu rozˇsifruje a obdrˇzen´y kl´ıˇc uloˇz´ı do lok´aln´ıho ´uloˇziˇstˇe kl´ıˇc˚u.
Dalˇs´ı f´aze jiˇz prob´ıh´a v r´amci knihovn´ıch funkc´ı. Verse klient pomoc´ı kl´ıˇce obdrˇzen´eho v pˇredchoz´ı f´azi ˇz´ad´a o pˇr´ıstup ke sluˇzbˇe (tedy k Verse serveru), pot´e obdrˇz´ı klient-server kl´ıˇc slouˇz´ıc´ı k ˇsifrov´an´ı komunikace s Verse serverem, a tak´e klient- server tiket, jenˇz pˇrepoˇsle serveru, opˇet viz. 2.10.1. Pot´e ˇcek´a na zpr´avu o ´uspˇeˇsnosti autentizace na Verse serveru. Sch´ema autentizace zobrazuje obr´azek 7.
6.3 Vyjedn´ av´ an´ı
Byla upravena specifikace zah´ajen´ı komunikace mezi Verse serverem a klientem.
Nov´a specifikace je pouˇzita pouze v pˇr´ıpadˇe, je-li uˇzivatel autentizov´an proti Kerberos serveru. V opaˇcn´em pˇr´ıpadˇe je pouˇzita p˚uvodn´ı specifikace.
Verse klient Aplikace
Knihovní funkce Uživatel
Uživatelské jméno a heslo
Žádost o autentizaci Autentizace ok + klíč
Žádos o autorizaci přístupu k službě
Autorizace ok + klient-server klíč + klient-server ticket Klient-server ticket
Autentizace ok
Verse server Kerberos server
Obr´azek 7: Autentizace uˇzivatele Verse serveru proti Kerberos serveru
V p˚uvodn´ı specifikaci (sch´ema je na obr´azku 8) server naslouch´a na TCP portu a je ve stavu LISTEN, pˇriˇcemˇz klient je ve stavu CLOSED a zah´aj´ı komunikaci otevˇren´ım TLS spojen´ı. Server pˇrejde do stavu RESPOND methods a d´ale naslouch´a. Klient pˇrejde do stavu USRAUTH none a odeˇsle ˇz´adost o autentizaci se sv´ym uˇzivatelsk´ym jm´enem.
Jako autentizaˇcn´ı metoda je zvolena metoda NONE, tedy ˇz´adn´a. Server by tuto metodu nemˇel podporovat. Odeˇsle tedy zpr´avu o tom, ˇze se autentizace nezdaˇrila, a s n´ı se- znam podporovan´ych metod. V t´eto specifikaci podporuje pouze metodu PASSWORD, tedy autentizaci za pomoci hesla a pˇrejde do stavu RESPOND usrauth. Klient, pot´e co obdrˇz´ı tuto zpr´avu, pˇrejde do stavu USRAUTH data, a opˇet odeˇsle ˇz´adost o autentizaci.
Ta tentokr´at obsahuje kromˇe jm´ena i heslo a jako metoda je nastaveno PASSWORD.
Server po t´e pˇrejde do stavu NEGOTIATE cookie, ded, odeˇsle zpr´avu o ´uspˇeˇsn´e au- tentizaci a pˇripoj´ı pˇr´ıkazy nastavuj´ıc´ı cookie a definici v´ymˇeny dat (Data Exchange Definition, DED). Klient t´eˇz pˇrejde do stavu NEGOTIATE cookie, ded a odeˇsle potvr- zen´ı, ˇze obdrˇzel pˇr´ıkazy. Pak se jiˇz dohaduje UDP spojen´ı.
Ve specifikaci s Kerberos autentizac´ı (sch´ema je na obr´azku 9) je vˇetˇs´ı ˇc´ast auten- tizaˇcn´ıho mechanismu ˇreˇsena jiˇz pˇri otev´ır´an´ı Kerberos spojen´ı. Na zaˇc´atku se server s klientem nach´az´ı ve stejn´ych stavech LISTEN respektive CLOSED. Klient otevˇre Ker-
Oteření TLS spojení
Klient Server
LISTEN CLOSED
USRAUTH none
USER_AUTH_REQUEST user_name=joe auth_method=NONE
RESPOND usrauth USER_AUTH_FAILURE count=1
auth_method=PASSWORD USER_AUTH_REQUEST user_name=joe
auth_method=PASSWORD password=QX9#amD1 USRAUTH
data USER_AUTH_SUCCESS
Change_R(COOKIE(Rt5#i0^f@&z2))
Change_L(DED(http://khronos.org/collada.ded)) NEGOTIATE cookie,ded Change_R(HOST(verse-udp-dtls://5.6.7.8:*))
Confirm_R(COOKIE(Rt5#i0^f@&z2)) Change_R(COOKIE(^DD31*$cZ6#t)) Confirm_L(DED(http://khronos.org/collada.ded)) NEGOTIATE
cookie,ded
RESPOND methods
Obr´azek 8: P˚uvodn´ı specifikace vyjedn´av´an´ı mezi serverem a klientem
beros spojen´ı a pˇrejde do stavu USRAUTH krb. Server pˇrejde do stavu RESPOND krb auth, v nˇem ovˇeˇr´ı zda m´a uˇzivatele se jm´enem z´ıskan´ym pˇri nav´az´an´ı Kerberos spojen´ı ve sv´em seznamu uˇzivatel˚u. Po nalezen´ı tohoto uˇzivatele pˇrejde do stavu NE- GOTIATE cookie, ded a odeˇsle zpr´avu o ´uspˇeˇsn´e autentizaci a pˇr´ıkazy nastavuj´ıc´ı cookie a DED. Klient opˇet pˇrejde tak´e do stavu NEGOTIATE cookie, ded a potvrd´ı pˇrijet´ı pˇr´ıkaz˚u. N´asleduje dohadov´an´ı UDP spojen´ı.
Klient Server
LISTEN CLOSED
USER_AUTH_SUCCESS Change_R(COOKIE(Rt5#i0^f@&z2))
Change_L(DED(http://khronos.org/collada.ded)) NEGOTIATE cookie,ded Change_R(HOST(verse-udp-dtls://5.6.7.8:*))
Confirm_R(COOKIE(Rt5#i0^f@&z2)) Change_R(COOKIE(^DD31*$cZ6#t)) Confirm_L(DED(http://khronos.org/collada.ded)) NEGOTIATE
cookie,ded
Oteření Kerberos spojení
RESPOND krb_auth USRAUTH
krb
Obr´azek 9: Nov´a specifikace vyjedn´av´an´ı mezi serverem a klientem pˇri ´uspˇeˇsn´em ovˇeˇren´ı klienta
6.4 Inicializace struktury reprezentuj´ıc´ı TCP spojen´ı
Pˇri navazov´an´ı TCP spojen´ı je potˇreba inicializovat strukturu reprezentuj´ıc´ı toto spojen´ı a to jak na stranˇe klienta, tak na stranˇe serveru. Tato struktura se naz´yv´a VStreamConn a je definov´ana v souboru v connection.h. Na stranˇe klienta se toto dˇeje ve funkci vc create client stream conn um´ıstˇen´e v souboru vc tcp connect.c. Vstupn´ımi argumenty jsou struktura reprezentuj´ıc´ı stav klienta VC CTX, ˇretˇezec znak˚u reprezen- tuj´ıc´ı adresu serveru a ˇretˇezec znak˚u reprezentuj´ıc´ıch jm´eno sluˇzby nebo ˇc´ıslo portu.
V´ystupn´ım parametrem je ˇc´ıslo chyby. Funkce vrac´ı ukazatel na strukturu reprezentuj´ıc´ı TCP spojen´ı, viz. n´asleduj´ıc´ı v´ypis.
struct VStreamConn *vc_create_client_stream_conn(const struct VC_CTX *ctx, const char *node, const char *service, uint8 *error)
V r´amci t´eto funkce tak´e klient otev´ır´a Kerberos spojen´ı. Nejprve je nutn´e zinicia- lizovat kontext knihovny Kerberos. K tomu slouˇz´ı funkce krb5 init context. D´ale je na- staveno ´uloˇziˇstˇe kl´ıˇc˚u pomoc´ı funkce krb5 cc default. Pot´e je pomoc´ı funkce krb5 mk req z´ısk´an klient-server tiket a klient-server kl´ıˇc. Klient-server tiket je pomoc´ı funkce send odesl´an Verse serveru. Pomoc´ı funkc´ı krb5 get server rcache a krb5 auth con setrcache je nastavena z´aznamov´a mezipamˇet’, kter´a slouˇz´ı k zamezen´ı duplicitn´ıch autenti- zac´ı. Pro dalˇs´ı ´uˇcely bˇehu Verse klienta je tˇreba z´ıskat strukturu reprezentuj´ıc´ı Ker- beros uˇzivatele. To umoˇzˇnuje funkce krb5 cc get principal. Nakonec je do vstupnˇe v´ystupn´ıho kontextu nastaveno, ˇze je pouˇz´ıv´ano Kerberos spojen´ı, viz. obr´azek 10.
Pokud v nˇekter´em z krok˚u nastane chyba, je vyps´ano hl´aˇsen´ı o t´eto chybˇe a funkce vrac´ı NULL. V opaˇcn´em pˇr´ıpadˇe funkce vrac´ı ukazatel na pr´avˇe vytvoˇrenou strukturu reprezentuj´ıc´ı TCP spojen´ı. Pot´e klient pˇrejde do stavu USRAUTH krb.
Na stranˇe serveru stejn´emu ´uˇcelu slouˇz´ı funkce vs init stream ctx, ze kter´e je vol´ana funkce vs init kerberos. Obˇe tyto funkce maj´ı jako jedin´y parametr strukturu reprezen- tuj´ıc´ı stav serveru a jsou um´ıstˇeny v souboru vs tcp connect.c. N´avratov´a hodnota je cel´e ˇc´ıslo. V pˇr´ıpadˇe ˇze vˇse probˇehne v poˇr´adku vrac´ı 1, jinak vrac´ı -1. Na n´asleduj´ıc´ım v´ypisu je hlaviˇcka funkce vs init kerberos.
V r´amci t´eto funkce je zinicializov´an kontext knihovny Kerberos funkc´ı krb5 init context. Pot´e je vytvoˇrena struktura reprezentuj´ıc´ı Kerberos uˇzivatele, jeˇz na Kerberos serveru pˇredstavuje sluˇzbu Verse. K tomu slouˇz´ı funkce krb5 sname to principal.
return NULL krb5_init_context
krb5_cc_default
krb5_mk_req
send
krb5_get_server_rcache
krb5_auth_con_setrcache
krb5_cc_get_principal
stream_conn->io_ctx.use_kerberos = USE_KERBEROS
return stream_conn OK
OK
OK
OK
OK
OK
OK
Chyba
Chyba
Chyba
Chyba
Chyba
Chyba
Chyba
Obr´azek 10: Diagram vytv´aˇren´ı Kerberos spojen´ı na stranˇe klienta
6.5 Ovˇ eˇ ren´ı tiketu
Po inicializaci struktury Verse server obdrˇz´ı a ovˇeˇr´ı klient-server tiket. To se dˇeje ve funkci vs kerberos auth. Funkce je um´ıstˇena v souboru vs handshake.c s parametrem vContext, coˇz je struktura obsahuj´ıc´ı vˇsechny nezbytn´e informace nutn´e ke bˇehu Verse serveru i Verse klienta. V´ystupn´ım parametrem je ukazatel na ˇretˇezec, do nˇejˇz se ukl´ad´a uˇzivatelsk´e jm´eno klienta, kter´y poslal klient-server tiket. Hlaviˇcka v´yˇse zm´ınˇen´e funkce je na n´asleduj´ıc´ım v´ypisu.
int vs_kerberos_auth(struct vContext *C, char **u_name)
Nejprve je nutn´e tiket pˇrijmout. K tomu je pouˇzita funkce recvfrom. Vlastn´ı kont- rola pˇrijat´eho tiketu prob´ıh´a pomoc´ı funkce krb5 rd req. Nakonec se server pokus´ı z´ıskat uˇzivatelsk´e jm´eno pomoc´ı funkce krb5 unparse name. Pokud vˇse probˇehne ´uspˇeˇsnˇe funkce vrac´ı 1, v opaˇcn´em pˇr´ıpadˇe vrac´ı 0.
6.6 Ovˇ eˇ ren´ı existence uˇ zivatele v r´ amci Verse serveru
Po ´uspˇeˇsn´em nav´az´an´ı Kerberos spojen´ı se Verse server pˇrepne do stavu RESPOND usrauth krb a pokus´ı se naj´ıt uˇzivatele z klient-server tiketu ve sv´em seznamu uˇzivatel˚u, aby zjistil jeho identifikaˇcn´ı ˇc´ıslo. Tento seznam uˇzivatel˚u byl vytvoˇren pˇri startu Verse serveru naˇcten´ım z LDAPu nebo CSV souboru. To obstaraj´ı funkce v souboru vs handshake.c. Je to funkce vs RESPOND krb auth loop, kter´a zpracov´av´a nˇekter´e pˇr´ıkazy pˇrijat´e v r´amci vyjedn´av´an´ı. A tak´e vol´a funkci vs krb make user, jeˇz slouˇz´ı pr´avˇe k nalezen´ı dan´eho uˇzivatele mezi uˇzivateli Verse serveru. Pokud se podaˇr´ı uˇzivatele nal´ezt, funkce vs RESPOND krb auth loop pˇriprav´ı k odesl´an´ı zpr´avu o ´uspˇeˇsn´e auten- tizaci obsahuj´ıc´ı identifikaˇcn´ı ˇc´ıslo uˇzivatele, toto ˇc´ıslo uloˇz´ı do struktury VSession re- prezentuj´ıc´ı aktu´aln´ı relaci a vytvoˇr´ı uˇzivateli avatar. Jinak pˇriprav´ı zpr´avu o ne´uspˇeˇsn´e autentizaci.
static int vs_krb_make_user(struct vContext *C, const char *username) Na v´ypisu v´yˇse je hlaviˇcka funkce vs krb make user. Ta, jak jiˇz bylo zm´ınˇeno, slouˇz´ı pˇr´ımo k nalezen´ı uˇzivatele. V pˇr´ıpadˇe ´uspˇechu vrac´ı identifikaˇcn´ı ˇc´ıslo uˇzivatele,
uid = -1
vs_ctx = CTX_server_ctx(C) vsuser = vs_ctx->users.first
vContext *C char *username
vsuser != NULL
vsuser->fake_user != 1
vsuser->username == username
uid = vsuser->user_id return uid
vsuser = vsuser->next +
-
+
+ -
-
Obr´azek 11: Hled´an´ı uˇzivatele v seznamu Verse uˇzivatel˚u
Po ´uspˇeˇsn´e autentizaci uˇzivatele se server pˇrepne do stavu NEGOTIATE cookie, ded a odeˇsle zpr´avu pˇripravenou v r´amci funkce vs RESPOND krb auth loop.
Klient tuto zpr´avu pˇrijme a zpracuje funkc´ı vc USRAUTH krb loop um´ıstˇenou v sou- boru vc tcp connect.c. Tato funkce zpracuje a pˇriprav´ı k odesl´an´ı vyjedn´avac´ı pˇr´ıkazy.
Pˇredevˇs´ım vˇsak v pˇr´ıpadˇe obdrˇzen´ı zpr´avy o ´uspˇeˇsn´e autentizaci nastav´ı ve struktuˇre reprezentuj´ıc´ı aktu´aln´ı relaci identifikaˇcn´ı ˇc´ıslo uˇzivatele a jeho avataru. Klient pak pˇrejde do stavu NEGOTIATE cookie, ded. Mezi Verse klientem a Verse serverem pak probˇehne jeˇstˇe nˇekolik vyjedn´avac´ıch zpr´av, kter´e dohaduj´ı parametry pˇrenosu dat po UDP a TCP spojen´ı je ukonˇceno.
