Active Directory autentikointi ja auktorisointi
Van Vo
Opinnäytetyö Marraskuu 2021 Tekniikan ala
Insinööri (AMK), Tieto- ja viestintätekniikka
Kuvailulehti
Tekijä(t)
Vo, Van Julkaisun laji
Opinnäytetyö, AMK Päivämäärä Marraskuu 2021 Sivumäärä
63 Julkaisun kieli
Suomi
Verkkojulkaisulupa myönnetty: x Työn nimi
Active Directory -autentikointi ja -auktorisointi
Tutkinto-ohjelma
Tieto- ja viestintintätekniikka Työn ohjaaja(t)
Lappalainen-Kajan Tarja, Häkkinen Antti Toimeksiantaja(t)
Combitech Oy Tiivistelmä
Opinnäytetyössä tehtiin selvitys ja toteutus Combitech Oy:lle liittyen Active Directory - autentikointiin ja -auktorisointiin. Tavoitteena oli selvittää ja tuottaa esimerkkitoteutus, jossa web-sovellukseen voidaan kirjautua Active Directory -tunnuksilla sekä käyttäjän auktorisointi tulee perustua ryhmiin mihin käyttäjä kuuluu Active Directoryssa.
Toteutukselta on myös muita vaatimuksia kuten se, että toteutusta voitaisiin hyödyntää muissakin projekteissa. Toteutuksen pitää kyetä toimimaan suljetussa verkossa, johon ei ole yhteyttä ulkoverkkoon.
Työ toteutettiin perehtymällä Active Directoryn ja sen autentikointimenetelmiin sekä selvitettiin auktorisointitapoja web-sovellukseen. Toteutuksessa oli myös oma kertakirjautuminen, jolla ei ole riippuvuutta kolmannen osapuolen komponentteihin johtuen suljetun verkon vaatimuksesta.
Lopputulokseksi saatiin vaatimuksia vastaava palvelu, jolle on delegoitu käyttäjän autentikointi ja auktorisointi. Tämä palvelu perustuu mikropalveluarkkitehtuuriin ja luo onnistuneen kirjautumisen jälkeen käyttäjästä poletin, jota palvelut käyttävät
auktorisoinnissa. Lisäksi se toimii identiteettisiltana muille palveluille. Tällöin muut palvelut voivat hakea siltä poletin, jossa on tarvittavat tiedot käyttäjästä sekä hänen
identiteetistänsä.
Avainsanat (asiasanat)
Autentikointi, Auktorisointi, Kertakirjautuminen, Mikropalvelut Muut tiedot (salassa pidettävät liitteet)
Description
Author(s)
Vo, Van Type of publication
Bachelor’s thesis Date November 2021 Language of publication:
Finnish
Number of pages
63 Permission for web publi-
cation: x Title of publication
Active Directory authentication and authorization
Degree programme
Information and communications technology Supervisor(s)
Lappalainen-Kajan Tarja, Häkkinen Antti Assigned by
Combitech Oy Abstract
In the thesis, a study about Active Directory authentication and authorization was con- ducted research with an implementation for Combitech Oy. The goal was to research and present an example implementation where Active Directory credentials can be used for login in a web application. Additionally, the authorization should be determined by groups where the user belongs in Active Directory. The implementation includes other require- ments. It should be reusable for other projects. Also, the implementation must be able to operate in an offline closed network.
The study was conducted by acquainting with active directory authentication methods and research methods for authorization to a web application. The implementation also has its own single sign-on implementation and is not dependable on any third-party component, due to the closed network requirement.
The result is a compliant service with the capability to handle authentication and authori- zation delegation. This service is based on a micro-service architecture and after successful authentication, it creates a token from the user for authorization purpose.
Additionally, it also works as an identity provider. Other applications and services can ac- quire tokens from it to get all necessary information and user’s identity.
Keywords/tags (subjects)
Authentication, Authorization, Single sign-on, Microservices Miscellaneous (Confidential information)
Sisältö
1 Johdanto ... 5
1.1 Toimeksiantajan esittely ... 5
1.2 Lähtökohdat ... 5
1.3 Tavoitteet ... 5
1.4 Tutkimusmenetelmä ... 6
2 Active Directory ... 6
2.1 Rakenne ... 6
2.2 Toimialue ... 8
2.3 Toimialuemetsä ... 8
2.4 Toimialuepuu ... 9
2.5 Organisaatioyksikkö ... 9
2.6 Objektit ... 10
2.6.1 Käyttäjäryhmä ... 10
2.6.2 Käyttäjä ... 11
3 Active Directory autentikointimenetelmät ... 11
3.1 Active Directory Federation Services ... 11
3.2 LDAP ... 13
3.2.1 LDAP-attribuutit ... 15
4 Autentikointi ... 16
4.1 Tunnistetietoihin perustuva autentikointi ... 16
4.2 Monivaiheinen autentikointi ... 16
4.3 Web-sovelluksen autentikointimenetelmät ... 17
4.3.1 Basic-autentikointi ... 17
4.3.2 Polettiin perustuva autentikointi ... 18
5 Auktorisointi ... 19
5.1 Pääsynvalvonta ... 19
5.1.1 Roolipohjainen pääsynvalvonta ... 19
5.1.2 Pakollinen pääsynvalvonta ... 20
5.1.3 Harkinnanvarainen pääsynvalvonta ... 21
5.2 Auktorisointi poletit ... 21
5.2.1 JWT-poletti ... 21
5.2.2 SAML-poletti ... 22
6 Kertakirjautuminen ... 24
7 Toteutus ... 26
7.1 Menetelmien valinta ... 26
7.2 Valmistelu ... 27
7.3 Mikropalveluarkkitehtuuri ... 30
7.3.1 Rekisteripalvelu ... 31
7.3.2 Yhdyskäytäväpalvelu ... 34
7.4 Autentikointi ... 36
7.4.1 Autentikointipalvelu ... 36
7.5 Auktorisointi ... 42
7.5.1 Auktorisointipalvelu ... 43
7.5.2 Polettien hallinta ... 46
7.6 Kertakirjautuminen ... 49
8 Tuloksen tarkastelu ja analyysi ... 56
9 Pohdinta ... 62
Lähteet ... 63
Kuviot Kuvio 1. Active Directory komponentit ... 7
Kuvio 2. Organisaatioyksikkö ... 9
Kuvio 3. AD FS -toimintaperiaaate ... 12
Kuvio 4. LDAP prosessi ... 14
Kuvio 5. Basic-autentikoinnin sekvenssikaavio ... 17
Kuvio 6. Polettiin perustuva autentikointi ... 18
Kuvio 7. Roolipohjainen pääsynvalvonta ... 20
Kuvio 8. JWT rakenne ... 22
Kuvio 9. SAML todennus- ja attribuuttilausunto ... 23
Kuvio 10. Kertakirjautumisen todennuspalvelu ja muut palvelut ... 25
Kuvio 11. Active Directory palvelimeen asennetut palvelinroolit ... 28
Kuvio 12. ADUC käyttöliittymä ... 29
Kuvio 13. Todennuspalvelun mikropalveluarkkitehtuuri ... 30
Kuvio 14. Rekisteripalvelun konfiguraatio ... 31
Kuvio 15. Rekisteripalvelun @EnableEurekaServer-annotaatio ... 32
Kuvio 16. Mikropalvelun konfiguraatio ... 33
Kuvio 17. Mikropalvelun rekisteröinti annotaatiolla ... 33
Kuvio 18. Yhdyskäytäväpalvelun konfiguraatio ... 34
Kuvio 19. Yhdyskäytäväpalvelun @EnableEurekaClient-annotaatio ... 35
Kuvio 20. Active Directory palvelimen tiedot konfiguraatiotiedostossa ... 36
Kuvio 21. WebSecurityConfig-luokan konfiguraatio... 37
Kuvio 22. Spring LDAP-moodulin käyttö ... 38
Kuvio 23. Active Directoryn kirjautuminen Postman-sovelluksella ... 39
Kuvio 24. Päätepiste käyttäjän käyttäjäryhmien hakemiseen ... 40
Kuvio 25. UnBoundID-kirjaston käyttö. ... 41
Kuvio 26. Käyttäjäryhmän hakeminen päätepisteestä DN-attribuutilla ... 42
Kuvio 27. Roolin oikeudet ... 44
Kuvio 28. JWT-poletin väite JSON-muodossa ... 45
Kuvio 29. Pääsy- ja päivityspoletin toimintaperiaate ... 46
Kuvio 30. Pääsy- ja päivityspoletit evästeissä ... 47
Kuvio 31. Todennuspalvelun ja dokumenttipalvelun Eureka-paneeli ... 49
Kuvio 32. Kirjautumisprosessi todennus- ja dokumenttipalveluun ... 51
Kuvio 33. Todennuspalvelun poletin hakeminen ... 53
Kuvio 34. Uloskirjautuminen ... 54
Kuvio 35. Dokumenttipalvelun pääsypoletin mitätöinti ... 55
Kuvio 36. Järjestelmä kokonaisuudessa ... 56
Kuvio 37. Dokumenttipalvelun poletin haku ... 57
Kuvio 38. Pääsypoletin uusiutuminen käytännössä ... 58
Kuvio 39. Todennuspalvelun hallintapaneeli ... 59
Kuvio 40. Käyttäjä Bart kirjautuneena dokumenttipalveluun ... 60
Kuvio 41. Käyttäjä Homer kirjautuneena dokumenttipalveluun ... 61
Taulukot
Taulukko 1. LDAP-attribuutit ... 15
1 Johdanto
1.1 Toimeksiantajan esittely
Combitech Oy on turvallisuus-, puolustus ja tietoturvaratkaisuja tarjoava yritys, joka työllistää yli 1900 henkilöä Ruotsissa, Suomessa, Norjassa ja Tanskassa. Suomessa Combitech Oy työllistää yli 80 työntekijää neljässä eri toimipisteessä Espoossa, Tampereella, Jyväskylässä ja Säkylässä. Combitech Oy tarjoaa räätälöityjä ja kestäviä ratkaisuja niin kotimaisille ja kansainvälisiin asiakkaiden tarpeisiin. Combitech Oy asiakaskuntaan kuuluu mm. puolustusvoimat, -teollisuus, yritykset ja julkinen sektori.
(Tietoja meistä n.d.) 1.2 Lähtökohdat
Combitech Oy:lla oli tarvetta löytää web-pohjaisille sovelluksille Active Directory - autentikointi ratkaisua, jossa käyttäjä voi kirjautua sovellukseen samoilla tunnuksilla, jolla hän kirjautuu Microsoft Windows -työkoneelle. Tämän lisäksi ratkaisussa tulee olla auktorisointi, joka perustuu siihen mihin ryhmään käyttäjä kuuluu Active Directoryssa. Tehtävänannon alkuvaiheessa keskusteltiin myös lisävaatimuksista, joita toivottiin esimerkkiratkaisuun. Nämä lisävaatimukset olivat seuraavanlaiset:
esimerkkitoteutus tulee toimia suljetussa verkossa, yhteys esimerkkitoteutuksen ja Active Directory -palvelimen välinen yhteys tulee olla salattu ja toteutuksen pitää olla uudelleen käytettävä sekä toivottiin myös kertakirjautumista.
1.3 Tavoitteet
Tehtävänanto Combitech Oy:lta on Active Directory -autentikointi ja -auktorisointi tutkimustyö, jolla pyritään löytämään ratkaisu Active Directory -autentikointi web- sovellukseen sekä käyttäjän auktorisointi perustuu siihen mihin käyttäjä kuuluu Active Directory -käyttäjäryhmässä. Tutkimustyön tuloksena haluttiin
esimerkkitoteutusta, jossa on sovellettu tutkitut asiat.
Täten opinnäytetyön tavoitteena on ensin selvittää mahdollisia Active Directory - autentikointi menetelmiä ja miten web-sovellukseen voidaan soveltaa auktorisointi, joka perustuu Active Directory -käyttäjäryhmiin. Selvityksen tuloksena on tuottaa Combitech Oy:lle esimerkkitoteutus, jossa on sovellettu vaadittu Active Directory - autentikointi ja -auktorisointi web-sovellukseen sekä toivotut lisävaatimukset.
1.4 Tutkimusmenetelmä
Opinnäytetyön tutkimusmenetelmänä käytetään soveltavaa tutkimusta.
Tutkimuksessa selvitetään, miten web-sovellukseen voidaan kirjautua Active Directoryn tunnuksilla ja miten auktorisointi sovelletaan web-sovellukseen käyttämällä Active Directory -käyttäjän käyttäjäryhmä tietoja. Tutkimuksessa hyödynnetään tietoa alan kirjallisuutta ja internettiä.
2 Active Directory
Active Directory on Microsoftin kehittämä hakemistopalvelu, jolla hallinnoidaan Windows-toimialueen käyttäjätietokantaa. Sen tarkoituksena on tarjota laajan ja tehokkaan käyttäjähallinnan organisaatiolle, nimittäin Active Directory mahdollistaa mm. keskitetyn resurssien ja oikeuksien jakaminen niin käyttäjille, laitteille ja
mahdollisesti myös sovelluksille. Active Directoryssä käyttäjät, käyttäjäryhmät ja laitteet ovat tallennettu objekteina, jotka kategorisoidaan nimen ja attribuuttien perusteella. (Alexander n.d.)
2.1 Rakenne
Active Directory rakentuu komponenteista, joilla hallinnoidaan ja kuvataan hakemistopalvelun tietoja (ks. kuvio 1). Nämä komponentit ovat toimialuemetsä (Domain Forest), toimialuepuu (Domain Tree), toimialue (Domain) ja
organisaatioyksikkö (Organizational Unit).
Kuvio 1. Active Directory komponentit
Komponenteista korkein hierarkkinen taso on toimialuemetsä. Toimialuemetsä koostuu yhdestä tai useammasta toimialueesta sekä toimialuepuista.
Toimialuemetsässä kuitenkin täytyy olla ainakin yksi toimialue. Toimialuepuu myös koostuu yhdestä tai useammasta toimialueesta sekä toimialuepuista, kuitenkin erona on se, että toimialuepuu on yksi solmusta isäntä toimialueesta. Toimialueeseen sisältyy organisaatioyksikköitä ja organisaatioyksikköön sisältyy objekteja.
(Understanding the Active - - 2021.)
2.2 Toimialue
Toimialue on yksi keskeisimmistä toiminnoista Active Directoryssa. Toimialueella voidaan hallita keskitetysti joukko Microsoft Windows -tietokoneita yhdeltä
palvelimelta. Palvelimet, jotka hallitsevat toimialueen tietokoneita tunnetaan nimellä toimialueen ohjauskoneeksi. Toimialueeseen luodut Active Directory -käyttäjät voivat kirjautua toimialueeseen riippumatta, siitä onko toimialue primaarinen tai liitetty toimialue, kunhan toimialueet kuuluvat yhteen toimialuemetsään. Toimialueeseen liitetyt laitteet hakevat käyttäjätietoja toimialueen ohjauskoneelta, jolloin Active Directory -käyttäjät voivat kirjautua organisaation toimialueeseen omilla tunnuksilla riippumatta siitä, millä yrityksen työkoneelta kirjaudutaan. (Hoffman 2017.)
2.3 Toimialuemetsä
Toimialuemetsä on Active Directoryssa korkein hierarkkinen taso. Kaikki
toimialuemetsässä olevat toimialuepuut hyötyvät toimialuemetsästä seuraavanlaiset hyödyt kuten hakemistonmalli, hakemiston konfiguraatio, infrastruktuuri tieto Active Directorysta ja myös sen, että toimialuemetsässä olevat toimialueet luovat toisiinsa transitiivisen luottamussuhteen. (What Are Domains and Forests? 2014.)
Näiden lisäksi toimialuepuut hyötyvät erikoisesta luettelosta, jota kutsutaan Global Catalogiksi (GC). Tämä luettelo on ”super-hakemisto”, jossa on replikaatio jokaisesta objektista toimialuemetsästä. GC-luettelossa tallennetaan objektit tiettyjen
attribuuttien kanssa jokaisesta toimialueesta. Tämä mahdollistaa nopean objektien haun, kun käytetään GC-luetteloa. (Global Catalog 2021.) Edellä mainitun lisäksi GC- luettelo mahdollistaa sen, että jos toimialueen ohjauskone on kaatunut, niin GC- luetteloa käytetään Active Directory -käyttäjän löytämiseen toisen ohjauskoneen avulla, joka hakee tietoa CG-luetteloa ylläpitävältä ohjauskoneelta.
2.4 Toimialuepuu
Toimialuepuu tasossa toimialueet ja toimialuepuut luovat toisiinsa transitiivisen luottamussuhteen. Kun toimialuepuuhun lisätään toimialue- tai toimialuepuusolmu, niin ne perivät saman osoite avaruuden, jossa liitetty toimialue- tai
toimialuepuusolmu saa oman osoitteen lisäksi jälkiliitteen kuvamaan isäntä toimialue- tai toimialuepuusolmua. (Domain Trees 2019).
2.5 Organisaatioyksikkö
Organisaatioyksikkö edustaa yrityksen tiettyä osastoa, organisatorista rakennetta Active Directoryn toimialueessa. Tähän orgaaniseen säiliöön voidaan ryhmittää Active Directoryn objekteja kuten käyttäjäryhmiä, käyttäjiä ja laitteita
(Understanding the Active - -2021.). Myös organisaatioyksikköön voidaan ryhmittää toinen organisaatioyksikkö. Kuviossa 2 organisaatioyksikön rakenteesta.
Kuvio 2. Organisaatioyksikkö
Organisaatioyksiköllä tavoitellaan sitä, että organisaatioyksikössä on mahdollista delegoida valtuuksia käyttäjille tai käyttäjäryhmille (Understanding the Active - - 2021.). Tällöin valtuuksia omaava objekti voi muokata, lisätä käyttäjiä tai
käyttäjäryhmiä omaan organisaatioyksikköön, mutta ei kuitenkaan pysty tekemään mitään muuta organisaatioyksikön ulkopuolelle.
2.6 Objektit
Active Directoryssa tiedot ovat tallennettuna hierarkkisesti objekteina. Objekteille luodaan Globally Unique Identifier (GUID) ja Security Identifier (SID) attribuutteja luonti vaiheessa. GUID on yksilöllinen 128-bittinen tunnistetieto, jota Active Directory käyttää objektin tunnistamiseen. GUID pysyy muuttumattomana koko objektin elinkaaren ajan. Kuitenkin käyttäjän SID-tunnus voi muuttua esimerkiksi toimialueen vaihtuessa. Sen sijaan käyttäjäryhmän SID tunnus ei voi muuttua. (User Naming Attributes 2018.) SID käytetään käyttöoikeuksien hallinnassa Active
Directoryssä (GUID vs SID 2010.).
2.6.1 Käyttäjäryhmä
Active Directory -käyttäjäryhmä on säiliö, johon ryhmitetään käyttäjiä ja laitteita.
Käyttäjäryhmän avulla saadaan helposti oikeuksia käyttäjille, jotka kuuluvat siihen ryhmään. Tällöin ylläpidon ei tarvitse määrittää erikseen oikeuksia jokaiselle käyttäjälle. Käyttäjäryhmän oikeuksia määritellään ryhmäkäytännöillä. Yhdelle ryhmäkäytännöillä voidaan määrittää joko tietokonekäytäntöjä, käyttäjäkäytäntöjä tai molempia. (Melnick 2017.)
Käyttäjäryhmän luontivaiheessa asetetaan joko distribuutio- tai turvallisuusasetus.
Distribuutio asetuksessa käyttäjäryhmällä ei ole turvallisuuskontekstia ja sitä käytetään muodostamaan sähköpostituslistaa. Tällöin kun käyttäjäryhmälle
lähetetään sähköpostiviesti niin kaikki, jotka kuuluvat kyseiseen käyttäjäryhmään saa lähetetyn viestin. Turvallisuus sen sijaan määrittää käyttäjäryhmälle käyttöoikeudet resurssiin, jolloin käyttäjäryhmään kuuluvilla on oikeus päästä käyttämään
organisaation resursseja esimerkiksi SharePointia. (Compare Groups 2012.)
2.6.2 Käyttäjä
Active Directoryn käyttäjäobjekteilla on sAMAccountName-attribuutti, jota voidaan käyttää kirjautumiseen Microsoft Windowsin toimialueelle. Kyseinen attribuutti on rakenteeltaan toimialue\logon-nimi. Tämän lisäksi käyttäjäobjekteilla on vielä UserPrincipalName-attribuutti (UPN), joka näyttää samalta kuin sähköpostiosoite.
UPN on rakenteeltaan logon-nimi ja @-merkin jälkeen tulee toimialueen tunniste.
Toimialueeseen voidaan kirjautua jommallakummalla. (User Naming Attributes 2018.)
3 Active Directory autentikointimenetelmät
Active Directoryssa on monia autentikointimenetelmiä web-sovellukseen. Näistä ylei- simmät ovat Lightweight Directory Access Protocol (LDAP) ja Active Directory Federa- tion Services (AD FS). Kumpikin tarjoaa autentikointi ratkaisun, mutta ainoastaan AD FS on valmiiksi rakennettu auktorisointi. Näiden kahden teoriaperustaa tarkastellaan ja valitaan sopivin ehdokas toteutukseen.
3.1 Active Directory Federation Services
AD FS on Microsoftin kehittämä ratkaisu kertakirjautumiselle, jossa on autentikointi ja auktorisointi ratkaisu rakennettuna. AD FS on ohjelmistokomponentti, jota
asennetaan Active Directory -palvelimeen. Tällöin palvelin toimii identiteettisiltana ja tarjoaa Active Directory -autentikoinnin niin sisäverkon- ja ulkoverkon Office 365- palveluun sekä useisiin kolmannen osapuolen palveluille. Palvelu autentikoi käyttäjän omasta toimialueesta ja luo käyttäjästä tunnisteen, jossa on väitteitä (Claims).
Kyseistä tunnistetta tullaan käyttämään palveluntarjoajissa, jotka toimivat
esimerkiksi toisessa organisaation tai pilven palveluissa. Olettaen sillä, että toisessa osapuolessa on myös palvelin, jolla on federatiivinen luottamussuhde tunnisteen luojan kanssa. Tunnisteen väitteessä on lista asetetuista säännöksistä, jolloin toinen osapuoli kykenee tunnistamaan käyttäjän ja hänen oikeutensa palveluun. Tällöin
organisaatiot eivät tarvitse jakaa omia käyttäjätietoja vaan käyttäjän identiteetti on valmiiksi varmistettu tunnisteessa. (Mixon n.d.)
Käytännössä tämä tarkoittaa sitä, että web-sovellukseen voidaan toteuttaa AD FS - palvelun tunnistetta vastaanottava palvelu, jolloin autentikointi on delegoitu AD FS - palvelulle. Web-sovelluksen auktorisointi onnistuu hyödyntämällä tunnisteen väitettä, nimittäin esimerkiksi AD FS -palvelun luomassa SAML-tunnisteessa on väitteessä käyttäjän identiteetti ja auktorisointiin tarvittavia tietoja. (Assertions and Protocols - - 2005.) Kuviossa 3 on AD FS -toimintaperiaate.
Kuvio 3. AD FS -toimintaperiaaate (What is ADFS? n.d)
Toimintaperiaate kuviosta selviä se, että koko prosessi alkaa siten, että käyttäjä haluaa päästä käyttämään palveluntarjoajan resursseja, mutta tunnisteen puutteen
vuoksi häneltä on evätty pääsy resursseihin. Tunniste ei kuitenkaan voi olla mikä tahansa palvelun luoma vaan tunnisteen täytyy olla AD FS -palvelun luoma, joka kuuluu federaatio väliseen luottamussuhteeseen. Käyttäjän tulee ensin kirjautua AD FS -palveluun saadakseen tunnisteen. Tämä AD FS -palvelin sitten tarkistaa käyttäjän identiteetin ja onnistuneen autentikoinnin seurauksena AD FS -palvelin luo
käyttäjälle tunnisteen, jota sitten käyttäjä tulee antaa palveluntarjoajille päästääkseen suojattuihin resursseihin. (Shyamsundar 2018.)
3.2 LDAP
LDAP on verkkoprotokolla, jota on kehitetty hakemaan hakemistopalvelun objekteja verkon yli. Pääasiallinen käyttötarkoitus on käyttäjätunnistus ja käyttöoikeuden tarkistus. Myös muita tietoja voidaan hakea käyttämällä LDAP-verkkoprotokollaa.
LDAP käyttää TCP-protokollaa, joka tarkoittaa sitä, että yhteydellä on yhteydenavaus ja lopetus kättelyoperaatiot hakemisto- ja asiakassovelluksen välillä. (Johner n.d).
Lähtökohtaisesti LDAP, jonka oletusportti on 389, ei muodosta hakemistopalvelun ja asiakassovelluksen välillä suojattua yhteyttä, joka tarkoittaa sitä, että tiedot
lähetetään suojaamattomana verkon yli. Yhteyden salaaminen onnistuu käyttämällä SSL-salausta, jolloin käytössä on LDAPS, jonka oletusportti on 636 (Ranellone 2020.).
LDAP-verkkoprotokollalla pystytään myös hakemaan objekteja käyttämällä GC- luetteloa, jolloin käytetään porttia 3268 tai 3269(SSL). Tällöin haku on paljon
nopeampaa, mutta menetetään tarkan haun ominaisuudet, koska GC-luettelossa on vain tietyt attribuutit objekteista.
LDAP-verkkoprotokollan toimintaperiaate toimii seuraavanlaisesti kuvion 4
mukaisesti. Asiakassovelluksen ja hakemistonpalvelun yhteyden avaaminen käyttäen LDAP-verkkoprotokollaa on melkein sama prosessi kuin TCP/IP-protokollassa.
Kuvio 4. LDAP prosessi
Yhteyttä tullaan ensin avaamaan siten, että asiakassovellus tekee yhteyden avauspyynnön hakemistopalveluun. LDAP-verkkoprotokollassa tätä operaatiota kutsutaan sidontavaiheeksi (Bind). Sidonnassa asiakassovellus määrittää myös hakemistopalvelun IP-osoitteen tai isäntänimen sekä portin. Riippuen
hakemistopalvelun konfiguraatiosta sidonta vaihe voi olla joko anonyyminen tai autentikoiva. Autentikoivassa sidonnassa käytetään joko Basic-autentikointi- tai Simple Authentication and Security Layer (SASL) -autentikointimenetelmää.
Basic-autentikoinnissa käytetään tunnistetiedoissa käyttäjän DN-attribuuttia käyttäjätunnuksena ja salasanaa varmistaakseen identiteetin. DN-attribuuttia käytetään, koska se on viittaus, missä kyseinen käyttäjäobjekti on
hakemistopalvelussa.
SASL käytättäessä käytetään myös Basic-autentikointia, mutta sen lisäksi se käyttää SASL-turvakerrosta, jossa määritellään SASL-mekanismi ja vaihtoehtoisesti myös enkoodattuja SASL-tunnisteita. SASL on tietoturvan ja Internet-protokollien todennuksen kehys. (Johner n.d.)
Sidonta vaiheen jälkeen hakemispalvelu joko kuittaa tai hylkää yhteyden riippuen siitä, että onko sidontavaiheessa annetulla käyttäjällä oikeuksia hakemistopalvelun resursseihin. Onnistuneessa sidonnassa asiakassovellus saa kuittauksen ja voi sen jälkeen lähettää hakemistopalveluun kyselyitä, jotka joko hakevat objekteja tai päivittää hakemistopalvelun tietoja. Hakemistopalvelu tekee kyselyä vastaavat toimenpiteet ja lopussa asiakassovellus tekee yhteyden lopetus pyynnön (Unbind), joka sitten johtaa siihen, että hakemistopalvelu tiputtaa yhteyden eikä vastaanota enää kyselyitä. Koko operaatio toistetaan joka kerta kun hakemistopalveluun tehdään kyselyitä käyttäen LDAP-verkkoprotokollaa. (Johner n.d.)
3.2.1 LDAP-attribuutit
LDAP-verkkoprotokollassa voidaan käyttää erilaisia attribuutteja tarkentaakseen objektien hakua. Taulukossa 1 on yleisimmät attribuutit, joita käytetään LDAP- verkkoprotokollassa (Knutson 2017.).
Taulukko 1. LDAP-attribuutit
Attribuutti Kuvaus Esimerkki
DC Domain component.
Määrittää toimialueen tason
hakemistopalvelussa. dc=example, dc=com
C Country.
Rajoittaa hakua maan perusteella.
Hakemistopalvelussa voi olla kielellinen
hierarkkinen rakenne. c=US
O Organization name.
Attribuutti käytetään resurssien
luokittelussa. o = Microsoft Corporation
OU Organizational unit.
Organisaatioyksikkö ou = Developers
DN Distinguished name.
Viittaus, missä kyseinen objekti on
hakemistopalvelussa. cn=Domain Ad-
mins,cn=users, DC=local
CN Common name.
Yksinkertaisuudessa objektin nimi, joka on ihmiselle ymmärrettävässä muodossa.
Käyttäjäobjektilla se on käyttäjän etu- ja sukunimi. Laitteille sen sijaan isäntänimi.
cn = homer simpson cn=HP_PRINTER
4 Autentikointi
Autentikointi on prosessi, jossa varmistetaan pitääkö paikkansa se väite, jota käyttäjä väittää olevansa. Väitteen paikkaansa pitävyyttä varmistetaan siten, että käyttäjä täytyy antaa yksilöllinen tunniste joko käyttäjätunnus tai sähköpostiosoite ja luottamuksellinen tunniste kuten salasana tai jokin muu tunniste, mitä ainoastaan käyttäjällä on. Näiden tunnistetietojen avulla autentikointia huolehtiva palvelu pystyy identifioimaan käyttäjän. (Knutson 2017.)
4.1 Tunnistetietoihin perustuva autentikointi
Tunnistetietoihin perustuva autentikointi on yleisin autentikointiprosessi. Tässä prosessissa käyttäjä antaa autentikointia huolehtivalle palvelulle käyttäjätunnuksen ja salasanan, jolloin järjestelmä tarkistaa löytyykö kyseinen käyttäjä tietokannasta ja vertaa objektin salasana attribuuttia annettuun salasanaan. (Knutson 2017.)
4.2 Monivaiheinen autentikointi
Monivaiheisessa autentikoinnissa on tunnistetietoihin perustuva autentikoinnin lisäksi lisätunniste, jota käyttäjän tulee antaa. Tämä tunniste voi olla koodi, jota tullaan kysymään käyttäjältä. Koodi voi olla RSA-laitteessa oleva numeroyhdistelmä tai generoitu koodi, jota lähetetään joko käyttäjän sähköpostiin tai puhelimeen.
Nykyään puhelimeen voidaan asentaa autentikaattori sovelluksen, jolloin koodia ei tarvitse syöttää järjestelmään Tällöin käyttäjä voi vahvistaa kirjautumisprosessinsa autentikaattorin avulla. (Multi-factor authentication 2019.)
4.3 Web-sovelluksen autentikointimenetelmät
Web-sovelluksella on monta autentikointimenetelmiä, mutta näistä yleisimmät ovat Basic-autentikointi ja polettiin perustuva autentikointi. web-sovelluksissa
autentikointi prosessissa tarkistetaan, että löytyykö käyttäjätunnus tietokannasta sekä verrataan, onko kohde objektilla sama salasana kuin se mitä on annettu.
4.3.1 Basic-autentikointi
Basic-autentikointi on yksinkertaisin autentikointiprosessi. Tässä menetelmässä asiakkaan tunnistetiedot kuten käyttäjätunnus ja salasana lähetetään HTTP-pyynnön authorization-otsikossa. Kuviossa 5 on Basic-autentikoinnin sekvenssikaavio.
Kuvio 5. Basic-autentikoinnin sekvenssikaavio
Basic-autentikointi on tilaton prosessi, jolloin asiakkaan tunnistetiedot lähetetään jokaisessa pyynnössä palvelimelle, joka sitten tarkistaa tiedot tietokannasta.
Tunnistetiedot eivät ole kuitenkaan lähetyksessä selkokielisenä vaan tiedot enkoodataan base64-merkkijonoksi, jolloin tietojen eheys säilyy siirrossa. Basic- autentikoinnissa tulisi käyttää salausta, jolloin tiedon siirtäminen olisi turvallista.
(Most used REST - - 2019.)
4.3.2 Polettiin perustuva autentikointi
Polettiin perustuva autentikointi on nykyaikaisempi autentikointi menetelmä, jota hyödynnetään kertakirjautumisjärjestelmässä. Tässä autentikointi menetelmässä asiakas lähettää tunnistetietonsa palvelulle, jonka jälkeen palvelu luo hänelle poletin (ks. kuvio 6).
Kuvio 6. Polettiin perustuva autentikointi
Tässä menetelmässä käyttäjä tarvitsee lähettää tunnistetietonsa palvelulle kerran.
Onnistuneessa kirjautumisessa luodaan asiakkaalle poletti, joka voi olla esimerkiksi JWT-poletti, jossa on käyttäjän identiteetti ja mahdollisia lisätietoja. Tämä poletti annetaan käyttäjälle, jolloin käyttäjän tulee antaa poletti jokaisessa pyynnössään palvelulle. Riippuen toteutustavasta polettia voidaan lähettää pyynnön mukana joko evästeessä tai HTTP authorization-otsikossa. Koska poletissa on käyttäjän identiteetti
varmistettu niin uutta tarkistusta tietokannasta ei tarvitse tehdä. Tämä vähentää tietokantaan kohdistuvaa kuormaa ja siten nopeuttaa palvelun sulavuutta. (Knutson 2017.)
5 Auktorisointi
Autentikoinnin jälkeen seuraa aina käyttäjän auktorisointi. Auktorisointi määrittelee sen, onko käyttäjällä oikeuksia resurssiin. Auktorisointi perustuu roolien jaotteluun, esimerkiksi Admin-käyttäjäroolilla on oikeus muokata järjestelmän tärkeitä
resursseja. Normaalilla käyttäjillä sen sijaan ei ole oikeutta muokata tärkeitä resursseja järjestelmässä. (Knutson 2017.)
5.1 Pääsynvalvonta
Auktorisointi määrittelee käyttäjille tai käyttäjäryhmille heidän oikeutensa resurssiin.
Pääsynvalvonta on menetelmä, jossa pääsyoikeudet resursseihin käytännössä toteutetaan. Pääsynvalvonnan yleisimmät variantit ovat roolipohjainen-, pakollinen- ja harkinnanvarainen pääsynvalvonta.
5.1.1 Roolipohjainen pääsynvalvonta
Roolipohjaisessa pääsynvalvonnassa (Role-based Access Control) rajoitetaan pääsyä resursseihin roolien avulla. Roolipohjaisessa pääsynvalvonnassa asetetaan
käyttöoikeudet valmiiksi rooleihin. Tällöin kun käyttäjälle annetaan kyseinen rooli, niin hän perii roolista käyttöoikeudet resurssiin (ks. kuvio 7).
Kuvio 7. Roolipohjainen pääsynvalvonta
Roolipohjaisella pääsynvalvonnalla pystytään lajittelemaan käyttäjille käyttöoikeudet, mitä he oikeasti tarvitsevat. Esimerkiksi kehittäjä roolilla on pääsy GIT-
versiohallintaan ja ICT-tukihenkilö roolilla on pääsy yrityksen palvelimen ja verkon hallintaan. Roolipohjaisella pääsynvalvonnalla vähennetään turhaa ylläpito työtä, nimittäin käyttäjille ei tarvitse antaa erikseen oikeuksia sekä oikeuksien poistaminen onnistuu vaivattomasti, kun poistetaan käyttäjältä annettu rooli. (William 2007.)
5.1.2 Pakollinen pääsynvalvonta
Pakollisessa pääsynvalvonnassa (Mandatory Access Control) pääsy resursseihin tulevat käyttäjän tiedon luottamuksellisuuden ja valtuuksien perusteella. Tätä käytetään korkeissa tietoturvallisuutta vaativissa järjestelmistä kuten sotilastieto- ja hallintojärjestelmissä. Tässä mallissa käyttöoikeudet määritellään järjestelmätasolla, jolloin käyttäjillä ja tiedonomistajalla ei ole oikeuttaa myöntää resurssille oikeutta.
(Lashkov 2018.)
Pakollisessa pääsynvalvonnassa kaikille resursseille ja käyttäjille asetetaan merkintöjä tai kategorioita, joiden perusteella heidän pääsynsä resurssiin tapahtuu (Lashkov 2018.). Esimerkiksi oletetaan, että resurssilla on luottamuksellinen suojaustaso
attribuutti, jolloin käyttäjän profiilissa pitää olla myös kyseinen suojaustaso attribuutti, jolla määritellään mihin suojaustasolle hänen oikeutensa riittävät resurssiin. Jos käyttäjällä on salainen suojaustaso attribuutti niin hänellä on pääsy resursseihin, jotka ovat korkeintaan salaiseen ja alempiin tasoihin eli hänellä on pääsy salaiseen, luottamukselliseen ja käyttö rajoitettuihin resursseihin.
5.1.3 Harkinnanvarainen pääsynvalvonta
Harkinnanvaraisessa pääsynvalvonnassa (Discretionary Access Control) resurssin omistaja määrittelee resurssille käyttöoikeudet ja toimintoja, mitä resurssille voidaan tehdä. Tämä pääsynvalvonta menetelmä hyödyntää pääsynvalvontalistaa (ACL), johon lisätään käyttäjät ja käyttäjäryhmät, joilla on oikeus käyttää kyseistä resurssia.
Käyttäjien ja käyttäjäryhmien lisäksi pääsynvalvontalistaan voidaan asettaa kirjoitus- ja lukuoikeudet. (Laskov 2018.)
5.2 Auktorisointi poletit
Nykyaikaisissa web-sovelluksissa käytetään auktorisoinnissa entistä enemmän poletteja niiden tuomien hyötyjen vuoksi. Poletit sisältävät väitteitä, jossa on tietoja käyttäjästä ja muuta tarvittavaa tietoa auktorisointia varten. Opinnäytetyössä tarkastellaan kahta mahdollista poletti standardia toteutukseen JSON Web Token (JWT) ja Security Assertion Markup Language (SAML).
5.2.1 JWT-poletti
JSON Web Token on avoimen standardin (RFC 7519) menetelmä, jolla hallinnoidaan käyttöoikeustietueita eri ohjelmistojen välillä. JWT-poletin informaatio on luotettava, koska taho, joka on luonut JWT-poletin, on asettanut allekirjoituksensa siihen.
Allekirjoituksen luotettavuutta varmistetaan sovitulla merkkijonolla. Tämä tarkoittaa sitä, että JWT-poletin tietoja ei voida muuttaa ja luoda noin vain. JWT-poletti
allekirjoitetaan käyttämällä joko HMAC- tai RSA-salausalgoritmia (Knutson 2017.).
JWT-poletissa on tietoja subjektista eli käyttäjästä, joilla voidaan identifioi käyttäjää.
Nämä tiedot pidetään poletin väitteessä (Claims). Käyttäjätietojen lisäksi väitteestä
on myös tieto, milloin JWT-poletti on luotu sekä sen voimassaoloaika. (Knutson 2017.) Kuviossa 8 on JWT-poletin rakenne.
Kuvio 8. JWT rakenne (Sajdak 2019)
JWT-poletti koostuu kolmesta osasta otsikosta, kuormasta ja allekirjoituksesta. Kaikki kolme osiota enkoodataan käyttämällä base64-koodausta, jolloin lopputuloksena on base64-merkkijono, jossa osiot ovat eroteltu pisteillä. Otsikossa kerrotaan JWT- poletin salausalgoritmi sekä tyyppi. Kuormassa on väitetiedot käyttäjästä ja lisätietoja kuten poletin luonti- ja voimassaoloaika. Allekirjoituksessa käytetään enkoodattua otsikko- ja kuormaa osiota sekä sovittu merkkijono (Secret). Edellä mainitut vielä salataan määritetyllä salausalgoritmilla allekirjoitus osiossa. (Knutson 2017.)
5.2.2 SAML-poletti
Security Assertion Markup Language on XML representaatio väitteistä. Kyseistä poletti menetelmää käytetään SAML-pohjaisissa kertakirjautumisjärjestelmissä, jossa todennuspalvelu luo käyttäjälle autentikoinnin jälkeen SAML-poletin. Tällä poletilla hallinnoidaan myös käyttöoikeustietueita palveluiden välillä. SAML-poletti eroaa JWT-poletista siten, että tiedot ovat lausuntoja ja niitä ei koodata base64-
merkkijonoksi. Lausuntoja on kolme, todennuslausunto (Authentication Statement),
attribuuttilausunnossa (Attribute Statement) ja auktorisointipäätöslausunto (Authori- zation Decision Statement). (Assertions and Protocols - - 2005.) Alla on esimerkki todennus- ja attribuuttilausunnosta (ks. kuvio 9).
Kuvio 9. SAML todennus- ja attribuuttilausunto (Prosper 2016, muokattu)
Todennuslausunnosta saadaan seuraavanlaiset tiedot kuten poletin luonut taho, joka https://auth.idp.com, identifioitu käyttäjä, joka on Prosper@zagadat.com ja
voimassaoloaika sekä muuta autentikointiin liittyvää tietoa.
Attribuuttilausunnossa on nimensä mukaisesti lisätietoa käyttäjästä attribuutteina.
Yleisimmät attribuutit attribuuttilausunnossa ovat rooli, sähköposti ja osasto.
(Assertions and Protocols - - 2005).
Auktorisointipäätöslausunnossa on tieto, mihin resursseihin käyttäjä on oikeutettu.
Tämän oikeuden määrittää tyypillisesti Policy Decision Point (PDP), joka varmistaa sen, että juuri tällä käyttäjällä on oikeudet pyydettyyn resurssiin. Kun PDP on
identifioinut käyttäjän ja varmistanut oikeudet, niin se allekirjoittaa väitteen, jossa on tieto, onko tällä käyttäjällä oikeudet resurssiin. (SAML Authorization Assertion n.d).
6 Kertakirjautuminen
Kertakirjautuminen on menetelmä, jolla tarjotaan käyttäjälle sujuvaa eri palveluiden käyttöä niin, ettei käyttäjän tarvitse syöttää jokaiselle palvelulle tunnistetietoja.
Kertakirjautumisessa hyödynnetään joko JWT- tai SAML-poletin ominaisuutta tunnistaakseen käyttäjän ja hänen oikeutensa palveluun. Kertakirjautumisessa palvelut tunnistavat käyttäjän poletin avulla ja sen perusteella antavat käyttäjälle pääsyn suojattuihin resursseihin.
Kertakirjautuminen kuitenkin kohtaa ongelman, jossa tiedonjako on rajoitettu tietoturvamekanismilla eri toimialueella toimivien palveluiden välillä. Tämä tietoturvamekanismi tunnetaan nimellä saman alkuperän käytäntö (Same-Origin Policy), joka määrittää selaimelle mm. käytännön, että evästeet ja paikallinen tallennustila (Local Storage) ovat ainoastaan siihen toimialueella saatavilla, missä se on luotu. Toisin sanoen toimialueella domain1.com toimiva palvelu pääsee käsiksi omiin domain1.com luotuihin evästeisiin, mutta toimialueella domain2.comilla ei ole pääsyä domain1.com evästeisiin ja päinvastoin. (Sebastian 2015.)
Kuitenkin kertakirjautumisessa tiedonjakamista eri palveluiden välillä ratkaistaan käyttämällä keskitettyä palvelua. Kuviossa 10 on kaavio, miten käytännössä kertakirjautuminen toimii.
Kuvio 10. Kertakirjautumisen todennuspalvelu ja muut palvelut (Sebastian 2015)
Ideana on siis luoda keskitetty palvelu, joka luo käyttäjästä onnistuneen
autentikoinnin seurauksena poletin ja asettaa sen evästeeseen. Keskitetty palvelu tunnetaan kertakirjautumisjärjestelmässä todennuspalveluna (Identity Provider), johon rekisteröidään palvelut sen piiriin. Aikaisemmin mainittu saman
alkuperänkäytäntö ratkaistaan kertakirjautumisessa siten, että hyödynnetään käyttäjän evästettä ja uudelleenohjausta. Käytännössä, kun palvelut saavat käyttäjältä pyynnön ja eivät löydä pyynnön evästeestä itse asettamansa evästettä niin ne uudelleenohjaavat tämän pyynnön todennuspalvelulle. Todennuspalvelu tunnistaa pyynnöstä käyttäjän evästeen avulla ja lähettää poletin palvelulle.
Saatuaan poletin todennuspalvelulta palvelu asettaa poletin käyttäjän evästeeseen juuri siihen toimialueelle, missä palvelu toimii. Evästeen asettamisen jälkeen palvelu tunnistaa käyttäjän poletin avulla, koska poletissa on tarvittavia tietoja käyttäjästä sekä siinä on todennuspalvelun tekemä allekirjoitus. Poletin allekirjoituksen avulla palvelut luottavat poletin tietoihin. Näin käyttäjän identiteetti ja käyttöoikeustietue hallitaan kertakirjautumisjärjestelmässä ja käyttäjän tarvitsee kirjautua vain kerran todennuspalveluun. (Sebastian 2015.)
7 Toteutus
Opinnäytetyön toteutuksen tavoitteena on toteuttaa tutkittu Active Directory - autentikointi ja -auktorisointi. Käytännössä toteutetaan esimerkkitoteutus, jossa web-sovellukseen tulee pystyä kirjautumaan käyttäjän omilla Active Directory - tunnuksilla. Edellä mainitun lisäksi käyttäjän auktorisointi perustuu Active Directory - käyttäjäryhmiin mihin kukin käyttäjä kuuluu.
7.1 Menetelmien valinta
Tietoperustan perusteella Active Directorylla on monta autentikointi menetelmää, mutta näistä tavoista valitaan LDAP-verkkoprotokolla autentikointitavaksi. LDAP tarjoa toteutukselle joustavuuden, koska LDAP-verkkoprotokollaa voidaan käyttää Windows-ympäristön lisäksi muissakin hakemistopalveluissa ja siinä ei tarvita ylimääräisiä konfiguraatioita palvelimeen. Lähtökohtaisesti LDAP-verkkoprotokolla toimii suoraan, kun Active Directory -palvelimeen asennetaan Active Directory Domain Services (AD DS), joka välttämätön palvelu Active Directoryssa.
Active Directory Federation Services ei valittu sen monimutkaisuuden vuoksi, nimittäin palvelu tarvitsee konfigurointia ja ylläpitoa enemmän verrattuna LDAP- verkkoprotokollaan. Lisäksi Active Directory Federation Servicellä on heikompi näkemys tuotteistuksen kannalta, koska ei tiedetä, onko asiakkaalla Active Directory Federation Services palvelinta taikka halua asentaa Active Directory Federation Services palvelinta, tämä siis rajoittaa asiakaskuntaa. LDAP-verkkoprotokolla siis vetää pidemmän korren, koska se toimii suoraan, kun palvelimessa on välttämätön AD DS palvelu. Kuitenkin Active Directory Federation Servicen tiputtaminen
tarkoittaa myös sitä, että toteutukseen tulee toteuttaa oma kertakirjautuminen.
Toteutuksessa luodaan kertakirjautumispalvelu, jolle delegoidaan autentikointi ja auktorisointi. Palvelu toimii todennuspalveluna ja huolehtii käyttäjän
autentikoinnista ja auktorisoinnista sekä se toimii identiteetti siltana samalla tavalla kuin Active Directory Federation Services. Ideana on tarjota melkein sama
toiminnallisuus kuin Active Directory Federation Services, mutta joustavammin ilman lisäkonfiguraatiota sekä vähemmän palvelimeen kohdistuvaa ylläpitoa. Lisäksi palvelu käyttää kevyitä menetelmiä kuten LDAP-verkkoprotokollaa. Lähtökohtaisesti Active Directory -palvelimessa on yleensä AD DS, jossa on valmiiksi LDAP tuki, niin tämä todennuspalvelu tulee varmasti toimimaan asiakkailla, joilla on Active Directory tai LDAP-verkkoprotokollaa tukeva palvelin.
Kertakirjautumisen toteutukseen valitaan JWT-poletti SAML-poletin sijaan.
Toteutukseen nähtiin se, että JWT-poletti sopii paremmin web-sovellukseen verrattuna SAML-polettiin. JWT-poletti on kooltaan pienempi ja sallii laajemman käytön, koska sitä voidaan käyttää myös mobiilisovelluksissa.
Toteutus tulee olemaan itse räätälöimä, jolloin sen muokattavuus omien tarpeisiin on miltei rajaton. Todennuspalvelun lisäksi toteutetaan palvelu, joka tulee
käyttämään todennuspalvelun polettia. Tämä palvelu on dokumenttipalvelu.
Dokumenttipalvelu tekee uudelleenohjaus pyyntöjä todennuspalveluun kuten kertakirjautumisjärjestelmän toimintaperiaatteen mukaan. Sen toteutusta ei käydä kuitenkaan tarkasti läpi, koska tavoitteena on tuottaa palvelu, joka huolehtii
autentikoinnista ja auktorisoinnista.
7.2 Valmistelu
Ennen varsinaista ohjelmointi toteutusta täytyy ensin asentaa ja konfiguroida Active Directory -palvelin, josta käyttäjätiedot autentikointia varten haetaan.
Opinnäytetyössä tuotetaan esimerkkitoteutus, joten mitään valmista Active Directory -palvelinta ei lähdetty konfiguroimaan. Ensin katsotaan, miten toteutus onnistuu ja sitten myöhemmin mahdollisesti voidaan liittää toteutus olemassa olevaan Active Directory -palvelimeen. Tämän vuoksi opinnäytetyössä asennettiin Active Directory - palvelin virtuaaliympäristöön ja tehtiin tarvittavat konfiguroinnit. Palvelimen
konfigurointi oli suoraviivaista ja helppoa, koska Windows Server Manager osaa hyvin opastaa ja kertoa, mitä pitää tehdä ennen kuin asentaa tietyn palvelinroolin Active Directoryyn. Kuviossa 11 on opinnäytetyön palvelimen asennetut
palvelinroolit.
Kuvio 11. Active Directory palvelimeen asennetut palvelinroolit
Palvelinrooleista on ainakin Active Directory Domain Services (AD DS) on asennettu, koska se on välttämätön palvelinrooli toteutuksen kannalta. Tämä AD DS -
palvelinroolin avulla voidaan käyttää hakemistonpalvelun objektien tietoja todentamiseen ja valtuuttamiseen perustuen objektien käyttöoikeuksiin sekä se tarjoaa samalla tuen LDAP-verkkoprotokollalle, jolloin erillistä LDAP-palvelinroolia ei tarvinnut asentaa. Domain Name Services (DNS) on nimipalvelu, joka muuttaa IP- osoitteet verkkotunnukseksi ja toisinpäin. Active Directory Certificate Services palve- linrooli tarjoaa sertifikaattien hallinnan.
Seuraava vaihe on konfiguroida Active Directoryn objekteja Active Directory Users and Computers (ADUC) -sovelluksella. Tämän sovelluksen avulla hallitaan siis hakemistopalvelun objekteja kuten käyttäjiä, käyttäjäryhmiä, laitteita ja organisaatioyksikköitä. Lisäksi palvelun avulla voidaan muokata objektien attribuutteja. Kuviossa 12 on sovelluksen käyttöliittymä.
Kuvio 12. ADUC käyttöliittymä
Kuten kuviosta 12 selviää, opinnäytetyössä tehtiin seuraavanlaiset konfiguraatiot hakemistopalveluun ADUC -sovelluksella. Luotiin siis toteutusta varten Developers- organisaatioyksikkö, johon ryhmitetään käyttäjät ja käyttäjäryhmät. Tämän
organisaatioyksikön SysAdmins-käyttäjäryhmälle on delegoitu oikeudet lisätä, muokata ja poistaa objekteja Developers-organisaatioyksikön sisältä.
Huomion varaista tässä on myös se, että käyttäjä voi kuulua moneen ryhmään, joten toteutuksessa tulee ratkaista oikeanlainen käyttöoikeus ongelma käyttäjälle
auktorisoinnissaan. Sen vuoksi tehtiin seuraavanlaiset konfiguraatiot: Homer-käyttäjä lisättiin TeamOne- ja TeamTwo-käyttäjäryhmään. Bart-käyttäjä lisättiin TeamOne- käyttäjäryhmään.
Edellä mainitun konfiguroinnin lisäksi huomioidaan toteutukseen se, että TeamOne- ja TeamTwo -käyttäjäryhmiin kuuluvilla ei ole oikeutta päästä todennuspalvelimen hallintapaneeliin. Ainoastaan SysAdmins-käyttäjäryhmään kuuluvilla on oikeus päästä
todennuspalvelimen hallintapaneeliin sekä muokkaamaan sieltä hakemistopalvelun käyttäjien ja käyttäjäryhmien oikeuksia. Konfiguraatiossa SysAdmins-ryhmään kuuluu Admin- ja SystemUser -käyttäjät. SystemUser on järjestelmäkäyttäjä, jota käytetään järjestelmän omiin toimintoihin.
Tällä konfiguraatio kokoonpanolla voidaan toteuttaa toteutuksen, jossa web- sovellukseen voidaan kirjautua Developers-organisaatioyksikön käyttäjillä ja käyttäjien auktorisointi tapahtuu sen perusteella mihin käyttäjäryhmään käyttäjä kuuluu Developers-organisaatioyksikössä.
7.3 Mikropalveluarkkitehtuuri
Tässä vaiheessa on konfiguroitu Active Directory -palvelin jo virtuaaliympäristössä, jolloin voidaan edetä itse ohjelmointi toteutukseen. Ennen ohjelmointi toteutusta käydään toteutuksen mikropalveluarkkitehtuuria (ks. kuvio 13).
Kuvio 13. Todennuspalvelun mikropalveluarkkitehtuuri
Kuten arkkitehtuurista selviää, todennuspalvelu koostuu monista mikropalveluista kuten autentikointi-, auktorisointi-, hallintapaneeli- ja yhdyskäytäväpalvelusta.
Yhdyskäytäväpalvelu huolehtii siitä, että asiakkaan rajapintakutsut ohjataan oikeille mikropalveluille. Autentikointipalvelu huolehtii käyttäjän autentikoinnista ja
keskustelee Active Directory -palvelimen kanssa LDAP-verkkoprotokollan avulla.
Auktorisointipalvelu huolehtii käyttäjän auktorisoinnista ja luo poletit käyttäjälle sekä toimii keskustelu siltana asiakassovelluksen ja autentikointipalvelun välillä.
Hallintapaneelipalvelu tarjoaa web-käyttöliittymän, jossa voidaan hallita Active Directoryn käyttäjiä ja käyttäjäryhmiä.
7.3.1 Rekisteripalvelu
Rekisteripalvelu on palvelu, joka pitää kirjaa palveluiden instansseista. Palvelun avulla saadaan hyödyllistä informaatiota mikropalveluista kuten missä IP-osoitteessa ja portissa mikropalvelut toimivat. Tämän palvelun avulla saadaan myös tietoon, jos jokin mikropalveluista on pois päältä. Opinnäytetyön esimerkkitoteutuksessa
käytetään rekisteripalvelussa Springin tarjoamaa Spring Cloud Netflixiä. Spring Cloud Netfixin käyttöönotto onnistuu vähäisellä konfiguraatiolla, nimittäin tarvittiin vain application.yml-tiedostossa kertoa seuraavanlaiset tiedot kuvion 14 mukaisesti.
Kuvio 14. Rekisteripalvelun konfiguraatio
Konfiguraatiotiedostossa kerrotaan siis Springille rekisteripalvelun nimi, osoite, isäntänimi rekisteripalvelulle ja portti. Lisäksi tässä konfiguraatiossa kerrotaan, että otetaan SSL-salaus menetelmä käyttöön.
Seuraavaksi lisätään rekisteripalvelun pääluokkaan Spring Cloud Netflixista
@EnableEurekaServer-annotaatio kuvion 15 mukaisesti.
Kuvio 15. Rekisteripalvelun @EnableEurekaServer-annotaatio
Tämä kertoo Springille, että kyseinen palvelu on rekisteripalvelu, johon muut
mikropalvelut rekisteröityvät. @EnableEurekaServer-annotaatio asentaa oletuksena kyseiseen mikropalveluun web-pohjaisen käyttöliittymän, jossa voidaan tarkastella kaikki rekisteripalveluun rekisteröidyt mikropalvelut ja niiden tilat.
Tässä vaiheessa on rekisteripalvelu asennettu ja konfiguroitu, jolloin voidaan kertoa mikropalveluille, miten ne rekisteröivät itsensä rekisteripalveluun. Tämä onnistuu, kun lisätään rekisteröitävän mikropalvelun omat ja rekisteröintipalvelun tiedot application.yml-konfiguraatiotiedostoon kuvion 16 mukaisesti.
Kuvio 16. Mikropalvelun konfiguraatio
Konfiguraatiotiedostossa on mikropalvelun nimi, osoite, portti sekä rekisteripalvelun osoite, johon kyseisen mikropalvelun tulee rekisteröityä. Kuten rekisteripalvelun konfiguraatiossa niin tämä mikropalvelu käyttää myös SSL-salausta.
Tässä vaiheessa on konfiguraatiotiedostossa tarvittavat tiedot, jolloin voidaan lisätä
@EnableDiscoveryClient-annotaatiota kuvion 17 mukaisesti.
Kuvio 17. Mikropalvelun rekisteröinti annotaatiolla
Tämä kertoo Springille, että kyseinen mikropalvelu rekisteröityy rekisteripalveluun käynnistyksen yhteydessä ja tulee näkymään rekisteripalvelun web-pohjaisessa käyttöliittymässä.
7.3.2 Yhdyskäytäväpalvelu
Yhdyskäytäväpalvelun tarkoitus on ohjata asiakassovellukselta tulevat pyynnöt mikropalvelulle. Esimerkkitoteutuksessa yhdyskäytäväpalvelu saa periaatteessa tietoon rekisteröityjen mikropalveluiden osoitteet ja portit rekisteripalvelun avulla.
Tämä mikropalvelu siis kysyy rekisteripalvelulta rekisteröityjen mikropalveluiden osoitteet ja portit, jolloin jos jokin mikropalvelun osoite muuttuu niin sitä, tietoa ei tarvitse muuttaa yhdyskäytäväpalveluun vaan kaikki hoituu rekisteripalvelun kautta.
Opinnäytetyössä yhdyskäytäväpalvelu käyttää Springin tarjoamaa Spring Cloud Gatewayta, jolle riittää, että määritellään palveluiden nimet konfiguraatiotiedostoon kuvion 18 mukaisesti.
Kuvio 18. Yhdyskäytäväpalvelun konfiguraatio
Konfiguraatiotiedostossa asetetaan yhdyskäytäväpalvelun konfiguraatio
mikropalvelu konfiguraation lisäksi. Toisin sanoen mikropalvelulle määritellään, mihin tulevia kutsuja ohjataan. Esimerkiksi oheinen konfiguraatiotiedosto kertoo yhdyskäytäväpalvelulle, että jos URL-pyynnössä on /data/ niin kyseinen pyyntö ohjataan auktorisointipalvelulle.
Tässä vaiheessa on konfiguraatiotiedostossa tarvittavat asetukset, jolloin lisätään yhdyskäytäväpalvelun pääluokkaan @EnableEurekaClient-annotaatio kuvion 19 mukaisesti.
Kuvio 19. Yhdyskäytäväpalvelun @EnableEurekaClient-annotaatio
Annotaatio kertoo Springille, että yhdyskäytäväpalvelu rekisteröi itsensä rekisteripalveluun. Tämän lisäksi annotaatio mahdollistaa sen, että
yhdyskäytäväpalvelu kykenee tiedustelemaan rekisteröidyt mikropalvelut. Itsensä rekisteröinnin myötä yhdyskäytäväpalvelun tila näkyy rekisteripalvelun web- pohjaisessa käyttöliittymässä.
Tässä vaiheessa on yhdyskäytäväpalvelu toteutettu, jolloin asiakassovellus voi lähettää rajapintapyynnöt yhdyskäytäväpalveluun, joka toimii osoitteessa https://idp.sso.com:8090/.
7.4 Autentikointi
Tässä vaiheessa on mikropalvelupohja toteutukset valmiina, jolloin päästään toteuttamaan tutkimuksen päätavoitetta eli miten web-sovellukseen voidaan kirjautua Active Directory -tunnuksilla. Kuten aiemmin mainittu LDAP-
verkkoprotokollaa tullaan tarvitsemaan tässä luvussa, joten toteutetaan palvelu, joka vastaanottaa annetut tunnistetiedot. Tunnistetietojen saatuaan palvelu tekee
kyselyn Active Directoryyn varmistaakseen käyttäjän identiteetin.
Ideana on siis luoda autentikointipalvelu, joka toimii välitys siltana
auktorisointipalvelun ja Active Directoryn välillä. Autentikointipalvelu kommunikoi Active Directoryn kanssa LDAP-verkkoprotokollalla. Sen lisäksi autentikointipalvelu huolehtii myös Active Directoryn objektien hakemisesta ja muokkaamisesta.
7.4.1 Autentikointipalvelu
Autentikointipalvelu käyttää pohjanaan Spring Security -sovelluskehystä ja Spring LDAP -moduulia. Palvelun konfigurointitiedostoon lisättiin seuraavanlaiset tiedot Active Directory -palvelimesta kuvion 20 mukaisesti.
Kuvio 20. Active Directory palvelimen tiedot konfiguraatiotiedostossa
Konfiguraatiotiedostossa on kirjattu Active Directoryn toimialueen taso, isäntänimi portti ja kommunikointitapa. LdapURL on yhdistetty merkkijono, joka koostuu kommunikointitavasta, isäntänimestä ja portista. Tämä merkkijono on selväkielisenä
ldaps://WIN.demo.local:636. Nämä tiedot ovat tärkeitä tietoja LDAP-moduulille, joka tekee sidonnan Active Directoryyn.
Seuraavaksi kerrotaan Spring Security -sovelluskehykselle, että käytetään autentikoinnissa Spring LDAP -moduulia. Tämä onnistuu perimällä Spring WebSecurityConfigurerAdapter -luokkaa, johon tehdään omia metodeja. Omat metodit astuvat voimaan, kun käytetään @overrride-annotaatiota, joka korvaa perittävän luokan oletusmetodi perivään luokkaan. Kuviossa 21 on
WebSecurityConfig-luokan konfiguraatio.
Kuvio 21. WebSecurityConfig-luokan konfiguraatio
Luokasta WebSecurityConfigurerAdapter löytyy configure-niminen metodi, johon tehtiin seuraavanlaiset konfiguroinnit:
1. CSRF pois päältä. Autentikointipalvelu ei huolehdi polettien jaosta vaan se on auktorisointipalvelun tehtävä.
2. AuthorizeRequest määrittelee pääsy rajoituksen eli anyRequest.authenticated määrittää, että kaikissa pyynnöissä käyttäjän tulee olla autentikoitu, mutta requestMatcher-funktiolla voidaan tehdä poikkeus esimerkiksi login-
päätepisteeseen, jossa käyttäjä ei tarvitse olla autentikoitu. Opinnäytetyössä käytetään apuna customMatcheriä tunnistamaan pyynnön lähettäjää.
3. HttpBasic kertoo, että autentikointi tapahtuu Basic-autentikointi menetelmällä.
4. Viimeisessä SessionManagement kohdassa kerrotaan Spring Security -
sovelluskehykselle, ettei luo istuntoa, kun käyttäjä on onnistuneesti autentikoitu.
Seuraavaksi liitetään Spring LDAP -moduuli WebSecurityConfig-luokkaan @Bean- annotaatiolla kuvion 22 mukaisesti.
Kuvio 22. Spring LDAP-moodulin käyttö
Spring LDAP -moduulissa löytyy ActiveDirectoryLdapAuthenticationProvider-luokka, joka ottaa toimialueen tason ja LDAP-verkkoprotokollan URLän parametrina. LDAP- verkkoprotokollan URL on opinnäytetyössä ldaps://WIN.demo.local:636.
Ensimmäisessä osiossa kerrotaan kommunikaatiotapa, opinnäytetyössä se on ldaps, joka tarkoittaa, että käytetään SSL-salausta. Toisessa Active Directoryn osoite isäntänimenä WIN.demo.local. Viimeisessä osiossa kerrotaan porttinumero 636, johon yhdistetään. Nämä tiedot ovat opinnäytetyössä autentikointipalvelun
konfiguraatiotiedostossa, jotta niitä voidaan tulevaisuudessa muuttaa vaivattomasti.
Spring LDAP -moduulin käyttö on kätevä, koska kirjautumiseen ei tarvitse antaa DN- attribuuttia. Moduulille riittää se, että annetaan käyttäjätunnus ja salasana. Huomioi se, että LDAP teoriassa on mainittu, että sidontaan tarvitaan käyttäjän DN-attribuutti ja salasana. Tämä tarkoittaa sitä, että Spring LDAP -moduuli tekee ensin DN-
selvityksen. Moduulin dokumentissa on kerrottu, että moduuli luo käyttäjätunnuksen
perusteella UPN-attribuutin (ActiveDirectoryLdapAuthenticationProvider n.d.). UPN- attribuutin avulla lähdetään etsimään käyttäjän DN-attribuuttia siten, että Spring LDAP -moduuli tekee sidonnan Active Directoryyn anonyymisesti ja hakee UPN- attribuutin perusteella käyttäjäobjektin DN-attribuutin ja vasta sitten tekee sidonnan löydetyllä DN-attribuutilla ja annetulla salasanalla.
Tässä vaiheessa autentikointipalveluun voidaan autentikoitua REST-rajapinnan kautta, jolloin autentikointipalvelu palauttaa onnistuneessa kirjautumisessa Active Directory -käyttäjäobjektin vastauksessaan. Tällä hetkellä ei ole käyttöliittymää, joten Active Directory kirjautuminen voidaan testata Postman-sovelluksella (ks. kuvio 23).
Kuvio 23. Active Directoryn kirjautuminen Postman-sovelluksella
Postmanille saadussa vastauksessa autentikointipalvelu palautti käyttäjän Homerin tiedot. Tiedosta selviää käyttäjänimi ja Authorities-lista sekä DN-attribuutti.
Authorities-listassa on käyttäjäryhmät mihin käyttäjä kuuluu Active Directoryssa.
Autentikoinnin lisäksi autentikointipalvelu on vastuussa myös objektien hakemisesta Active Directorysta, joten luodaan päätepiste, johon auktorisointipalvelu tekee pyynnön, kun se tarvitsee enemmän tietoa objektista. Luodaan getAuthorities- päätepiste kuvion 24 mukaisesti.
Kuvio 24. Päätepiste käyttäjän käyttäjäryhmien hakemiseen
Kyseinen päätepiste antaa getLdapEntities-geneeriselle funktiolle LDAP-hakuehdon, johon tulee käyttäjän DN-attribuutti. Hakuehdossa kerrotaan LDAP-
verkkoprotokollalle, että haetaan käyttäjäryhmät, jossa member-attribuutissa on annettu DN-attribuutti.
Edellä mainittu funktio käyttää UnBoundID-kirjastoa, jolla voidaan tehdä LDAP- kyselyitä Active Directoryyn. UnBoundID-kirjastolla on funktiot, joissa on
nimenomaan LDAP-verkkoprotokollasta vastaavat prosessit, jotka ovat mainittu teoriaosuudessa. Kuviossa 25 on UnBoundID-kirjaston käyttö.
Kuvio 25. UnBoundID-kirjaston käyttö.
1. Ensimmäiseksi kerrotaan, että halutaan avata yhteys ja annetaan palvelimen isäntänimi ja portti.
2. Seuraavaksi sidotaan yhteys SystemUser-käyttäjällä. Opinnäytetyössä ei ole tallennettu käyttäjän salasanaa missään eikä sitä tulisikaan missään nimessä olla tallennettu muualla kuin hakemistopalvelussa. Täten sidonta on mahdotonta tehdä kyseisellä käyttäjällä. Tämän vuoksi on lisätty SystemUser järjestelmään.
SystemUser-käyttäjää käytetään tässä sidonnassa ja kyseinen käyttäjä kuuluu
SysAdmins-käyttäjäryhmään, jolla on pääoikeudet Developers-organisaatioyksikössä.
3. Sidonnan jälkeen lisätään hakuehto ja kerrotaan, että halutaan vastauksessa Active Directory -objektit, josta on suodatettu kaikki muut attribuutit paitsi
cn,memberOf,member ja dn.
4. Hakuehdon lisättyä tehdään varsinainen haku.
5. Vastauksena tulee lista, jossa on hakuehtoa vastaavat Active Directory -objektit.
6. Tämän jälkeen suljetaan yhteys.
Seuraavaksi testataan päätepiste Postman-sovelluksella (ks. kuvio 26).
Päätepisteeseen lähetetään POST-pyyntö, jossa on käyttäjän DN-attribuutti.
Kuvio 26. Käyttäjäryhmän hakeminen päätepisteestä DN-attribuutilla
Päätepiste palauttaa Homer-käyttäjän käyttäjäryhmät listana. Tätä toiminnallisuutta hyödynnetään myöhemmin luvussa 7.5.2.
7.5 Auktorisointi
Auktorisointipalvelun toteutuksessa tullaan ratkaisemaan seuraavanlaisia ongelmia kuten se, että miten web-sovelluksen resurssien käyttöoikeudet tulevat käyttäjälle.
Käyttäjillä on tosiaan Active Directory -käyttäjäryhmiltä oikeudet, mutta ne oikeudet ovat spesifisiä Active Directoryn toimintoihin. Sen vuoksi näitä tietoja ei voida hyödyntää web-sovelluksessa. Web-sovelluksessa olisi kannattavaa luoda oma pääsynvalvonta mekanismi, nimittäin jos halutaan määrittää resurssille suojaustaso luokitusta niin tämä suojaustaso attribuutti on liian työlästä lisätä jokaiselle
käyttäjäryhmälle Active Directoryssä.
Toinen ongelma on se, että miten pääsynvalvonnalle saadaan käyttöoikeudet ajan tasalle. Esimerkiksi jos käyttäjää lisätään toiseen Active Directory -käyttäjäryhmään niin tämä muutos ei tule heti voimaan web-sovelluksessa, koska poletti pohjaisessa
autentikoinnissa poletti luodaan ja allekirjoitetaan autentikoinnin jälkeen. Tämä tarkoittaa sitä, että käyttäjän tulee kirjautua uudelleen järjestelmään, jolloin hänelle luodaan uusi poletti, jossa on päivitetyt käyttöoikeudet. Edellä mainittu toimii tavallaan, mutta käyttökokemus kärsii sen vuoksi. Tämän vuoksi
auktorisointipalvelun on vastuussa myös poletin käyttöoikeustietojen pitäminen ajan tasalla.
7.5.1 Auktorisointipalvelu
Auktorisointipalvelu toimii asiakassovelluksen ja autentikointipalvelun välissä, toisin sanoen asiakassovellus, joka haluaa käyttää toteutuksen autentikointi- ja
auktorisointia palvelua, ottaa tämä yhteyden yhdyskäytäväpalveluun, joka ohjaa pyynnön auktorisointipalveluun prosessointia varten.
Kirjautumisprosessissa auktorisointipalvelu lähettää saadut käyttäjän tunnistetiedot autentikointipalvelulle sen oman kirjautumisprosessia varten. Onnistuneen
autentikoinnin seurauksena autentikointipalvelu palauttaa auktorisointipalvelulle käyttäjäobjektin, jossa on tietoja käyttäjästä kuten käyttäjänimi, DN- ja Authorities- attribuutit.
Käyttäjäobjektissa on siis tarvittavat tiedot auktorisointipalvelulle kyseisestä käyttäjästä, jolloin se osaa sen perusteella luoda käyttäjälle poletin, jossa on käyttäjän käyttöoikeudet. Tämä poletti annetaan asiakassovellukselle ja
asiakassovellus tulee antaa kyseisen poletin palvelulle, kun hän asioi palvelun kanssa.
Tähän lisätietona, että yritys tekee korkeille tietoturvallisuutta vaativille asiakkaille projekteja, jolloin olisi hyvä soveltaa vaativa pääsynvalvonta. Käyttäjälle ei ole kannattavaa lisätä suojaustaso attribuuttia erikseen kuten perinteisessä pakollisessa pääsynvalvonnassa, koska tämä tuo lisää ylläpitotyötä. Päädyttiin kuitenkin
soveltamaan roolipohjaisen pääsynvalvontaa siten, että siinä on sovellettu pakollisesta pääsynvalvonnasta olevaa määritelmää, jossa verrataan rooleissa ja resursseissa olevia määritelmiä.
Täten toteutetaan auktorisointipalvelu, joka antaa rooleja käyttäjälle perustuen siihen, mihin käyttäjä kuuluu Active Directory -käyttäjäryhmässä. Rooleille asetetaan suojaustaso attribuutti profiiliin, jolloin muissa projektien palveluiden resursseilla pitää olla tämä suojaustaso attribuutti määritelmä. Kun määritelmät täsmäävät niin käyttäjällä on oikeus resurssiin.
Ennen auktorisointipalvelun toteutusta, luodaan ensin roolitietokanta, jossa rooleihin on valmiiksi asetettu suojaustaso attribuutti ja mahdollisuus lisätä muutakin tietoa.
Kuviossa 27 on esimerkki TeamTwo-roolista roolitietokannassa.
Kuvio 27. Roolin oikeudet
Kyseistä roolista selviää, että hänellä on pääsy resurssiin, joiden suojaustaso on 4–5 väliltä. Tällä roolilla on siis pääsy korkeintaan luottamuksellisiin luokiteltuihin resursseihin ja sillä on ainoastaan lukuoikeus.
Tässä vaiheessa on rooleissa asetetut käyttöoikeustiedot valmiina, jolloin jää se prosessi, jossa annetaan käyttäjälle hänelle kuuluvat roolit pääsynvalvontaa varten.
Käytännössä toteutukseen tehtiin se, että roolit tulevat käyttäjälle Authorities-
attribuutin perusteella. Tämä tarkoittaa sitä, että Active Directory -käyttäjäryhmille ja roolitietokannan rooleille on annetta vastaavanlaiset nimet. Tällöin käyttäjälle tuleva
rooli tulee Active Directory -käyttäjäryhmän nimen perusteella. Kuitenkin käyttäjä voi kuulua moneen käyttäjäryhmään niin hänelle tulee tietysti monta roolia. Rooleilla saattaa olla samoja käyttöoikeustietoja. Tämä asia on huomioitua ja ratkaistu siten, että toteutuksessa rooleista tehdään yksi yhdistetty päärooli, johon valitaan
”korkeimmat” arvot.
Pääroolin luonnin jälkeen luodaan poletti, joka on opinnäytetyössä JWT. JWT- polettiin asetetaan päärooli väitteeseen, jonka avulla palvelut pystyvät saamaan tietoon käyttäjän käyttöoikeudet. Kuviossa 28 on auktorisointipalvelun
allekirjoittama JWT-poletin väite purettuna JSON-muodossa.
Kuvio 28. JWT-poletin väite JSON-muodossa
Väitteestä selviää yhdistetyn roolin lisäksi käyttäjän nimi sub-attribuutissa sekä JWT- poletin luonti- ja voimassaoloaika millisekunteina, joka on tässä tapauksessa 30 minuuttia.
JWT-poletin luomisen jälkeen rekisteröidään JWT-poletti Redis-nimiseen avainarvo- tietokantaan, jolloin pidetään istunto JWT-poleteista. Istunnossa on JWT-poletin arvon lisäksi kyseisen käyttäjän DN-attribuutti, jota tullaan käyttämään JWT-poletin uusimisessa. Istunnon ideana on hallita käyttäjiä kertakirjautumisjärjestelmässä.
Aiheesta käydään tarkemmin luvussa 7.6.
7.5.2 Polettien hallinta
Seuraava vaihe on luoda mekanismi, jolla auktorisointipalvelu ajantasaistaa poletin käyttöoikeustietoja. Kuten aiemmin mainittu muutos Active Directoryssa ei astu heti voimaan web-sovelluksessa, koska poletti on jo luotu, jolloin siinä on edelleen vanhaa tietoa. Jotta tietoja voitaisiin päivittää, niin siihen vaaditaan käyttäjän uudelleenkirjautumista, jossa käytettävyys kärsii.
Ongelma kuitenkin ratkeaa soveltamalla OAuthista pääsy- (Access token) ja
päivityspoletti (Refresh token) menetelmää. Kuviossa 29 on pääsy- ja päivityspoletin toimintaperiaate.
Kuvio 29. Pääsy- ja päivityspoletin toimintaperiaate
Toimintaperiaatteesta selviää, että polettia luova auktorisointipalvelu tulee antaa käyttäjälle onnistuneen tunnistautumisen jälkeen pääsy- ja päivityspoletteja.
Pääsypoletilla käyttäjä pääsee suojattuihin resursseihin, kun taas päivityspoletilla päivitetään pääsypolettia. Opinnäytetyössä pääsypoletti tulee olemaan edellisessä luvussa luotu JWT-poletti, jolla on lyhyt voimassaoloaika ja sisältää pääsynvalvontaa varten käyttöoikeustietoja. Kun pääsypoletista loppuu voimassaoloaika, niin
asiakassovellus pitää lähettää auktorisointipalvelulle päivityspoletin, jolloin uusitaan pääsypoletti sillä ehdolla, että päivityspoletin voimassaoloaika pitää olla vielä validi.
Tämän toimintaperiaatteen mukaisesti opinnäytetyössä luodaan pääsypoletin lisäksi päivityspoletti käyttäjälle, jossa ei ole väitteessä roolia. Nämä kaksi polettia
asetetaan evästeisiin. Tämän lisäksi annetaan vielä päivityspoletin evästeelle refreshtoken-polku, jolloin päivityspolettia sisältävä eväste on ainoastaan
käytettävissä refreshtoken-polussa. Kuviossa 30 on käyttäjän evästeisiin asetetut poletit.
Kuvio 30. Pääsy- ja päivityspoletit evästeissä
Mainitut poletit ovat asetettu evästeisiin ja näkyvät käyttäjälle, kun hän menee selaimen storage-välilehteen. Storage-välilehdestä nähdään token-eväste, jossa on pääsypoletti ja refreshToken-evästeessä on päivityspoletti. refreshToken-
evästeeseen on asetettu polku, joka tarkoittaa sitä, että se on ainoastaan käytettävissä tuolla polulla.
Polettien asettaminen evästeisiin hyödynnetään selaimessa olevaa ominaisuutta, joka lähettää HTTP-pyynnön mukana automaattisesti evästeet. Tämän avulla palvelut saavat haltuunsa evästeisiin asetetut poletit pääsynvalvontaa varten. Pyynnön
evästeistä etsitään pääsypolettia sisältävä eväste ja sen avulla palvelut pystyvät tunnistamaan pyyntöä lähettävän käyttäjän sekä osaavat tarjota resursseja perustuen käyttäjän käyttöoikeuksiin, jotka löytyvät poletin väitteestä.
Päivityspoletti toimii kuitenkin hieman eri tavalla. Selain lähettää pyynnön mukana kyseisen evästeen, mutta kyseistä evästettä ei voida käyttää muualla kuin
refreshtoken-polulla. Opinnäytetyössä on lisätty automaattinen toiminto, jossa käyttöliittymä tekee automaattisesti auktorisointipalvelun refreshtoken-
päätepisteeseen pyynnön yhdyskäytävän palvelun kautta, kun pääsypoletilta on voimassaoloaika päättynyt.
Tämä päätepiste sitten tarkistaa, onko päivityspoletti vielä voimassa, jos ei ole niin kummatkin poletit mitätöidään evästeistä ja poistetaan kyseinen poletti istunto istuntotietokannasta. Jos päivityspoletin voimassaoloaika on vielä voimassa niin, pääsypoletilla haetaan käyttäjän DN-attribuutti istuntotietokannasta. DN-attribuutin haettua tehdään pyyntö autentikointipalvelun getAuthorities-päätepisteeseen.
Pyynnön mukana liitetään käyttäjän DN-attribuutti, jolloin autentikointipalvelu pystyy hakemaan uudelleen käyttäjän käyttäjäryhmät Active Directorysta ja
palauttaa uuden käyttäjäobjektin auktorisointipalveluun. Auktorisointipalvelu tekee prosessin, jossa se hakee käyttäjäryhmiä vastaavat roolit roolitietokannasta, luo uuden pääroolin ja pääsypoletin, päivittää pääsypoletti istunnon istuntotietokantaan ja asettaa uuden pääsypoletin käyttäjän evästeeseen. Tämän menetelmän avulla pääsypoletissa olevat käyttöoikeustiedot pysyvät ajan tasalla.
