Hirviö Tekninen spesifikaatio

Hirviö Tekninen spesifikaatio Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 15. maaliskuuta 2005 Tiivistelmä Tekninen spesifikaatio määrittelee Hirviö-järjestelmän tekniset ominaisuudet kuten kokonaisarkkitehtuurin, palvelinsovelluksen arkkitehtuurin ja tietokantarakenteen. 1

Sisältö 1 Johdanto 4 2 Termit ja määritelmät 4 2.1 Käsitteet...................................... 4 2.2 Lyhenteet...................................... 4 3 Palvelinarkkitehtuuri 4 3.1 WWW-palvelin................................... 5 3.2 Tietokantapalvelin................................. 5 3.3 Selaimet....................................... 5 3.4 Autentikointipalvelimet.............................. 5 3.5 Vaihtoehtoiset ratkaisut.............................. 6 4 Järjestelmän arkkitehtuuri 6 4.1 Järjestelmän framework.............................. 7 4.1.1 Tapahtumat................................. 7 4.1.2 Esimerkki tapahtuman laukaisusta.................... 7 5 Sovelluslogiikkamoduli 7 5.1 Tärkeimmät luokat................................. 8 5.1.1 HirvioApplication............................. 8 5.2 Esimerkki tapahtumankäsittelijän toteuttamisesta............... 8 6 Käyttöliittymämoduli 8 6.1 Tärkeimmät luokat................................. 8 6.1.1 View..................................... 8 6.1.2 Element................................... 8 6.1.3 ValidatingElement............................. 8 6.1.4 FormElement................................ 9 6.2 Esimerkki käyttöliittymäkomponenttien rakentamisesta............ 9 7 Tietokantamoduli 10 7.1 Tärkeimmät luokat................................. 10 7.1.1 DataManager................................ 10 7.1.2 DatabaseConnection............................ 10 8 AAA-moduli 10 8.1 Todennus...................................... 11 8.2 Audit Trail..................................... 11 8.3 Sisään- ja uloskirjautuminen............................ 11 8.4 Tärkeimmät luokat................................. 12 8.4.1 Authenticator................................ 12 8.4.2 AuthenticationMethod-rajapinnan toteuttavat luokat.......... 12 2

8.4.3 Logger.................................... 13 9 Tietokantarakenne 13 9.1 Users......................................... 13 9.2 Students....................................... 14 9.3 Notes........................................ 14 9.4 WorkgroupAuthorizations............................. 15 9.5 Thesis........................................ 15 9.6 Log.......................................... 15 9.7 Files......................................... 15 9.8 Workgroups..................................... 16 9.9 ER-kaavio...................................... 16 9.10 Hylätyt ratkaisut.................................. 16 10 Järjestelmän siirrettävyys eri alustoille 16 11 Käyttöliittymän suunnitteluperiaatteet 17 12 Tietoturva 17 12.1 Käyttäjien tunnistus ja todennus......................... 17 12.1.1 Järjestelmän oma tietokanta....................... 17 12.1.2 LDAP.................................... 18 12.1.3 ATK-keskuksen Shibboleth........................ 18 12.2 Oikeustasot..................................... 18 12.3 Tapahtumien kirjaus eli Audit Trail....................... 18 12.4 Sessionhallinta................................... 18 12.5 Syötteiden tarkistaminen............................. 19 12.6 Muita tietoturvahuomioita............................. 19 3

Versio Päivämäärä Tekijä Versio 0.9 19.11.2004 Sarjakoski Ensimmäinen versio projektiryhmän sisäiseen käyttöön iteraatiolla I1 1.0 30.11.2004 Sarjakoski Iteraation I1 lopussa palautettu versio 1.1 8.2.2005 Heikkinen, Toivanen Iteraation I2 lopussa palautettu versio 1.2 15.3.2005 Sarjakoski Iteraation FD lopulla palautettu uudistetut UML-kaaviot sisältävä ajantasaistettu versio 1 Johdanto Tämä dokumentti on Hirviö-ryhmän T-76.115 Tietojenkäsittelyopin ohjelmatyö -kurssilla toteutetun Hirviö-järjestelmän tekninen spesifikaatio. Dokumentti määrittelee Hirviö-järjestelmän tekniset ominaisuudet. Siinä esitellään järjestelmän kokonaisarkkitehtuuri, palvelinsovelluksen arkkitehtuuri, palvelinsovelluksen jako moduleihin sekä niiden sisäinen luokkarakenne pääpiirteissään. Lisäksi dokumentti esittelee tietokantarakenteen ja muita järjestelmän teknisiä ominaisuuksia. 2 Termit ja määritelmät 2.1 Käsitteet Näkymä Järjestelmän käyttäjälle näkymä ulkoasu ja sisältö jollakin hetkellä. Käytännössä sama asia kuin WWW-sivu selaimessa jollakin hetkellä. 2.2 Lyhenteet AAA Authentication, Authorization and Accounting HTTP HyperText Transfer Protocol LDAP Lightweight Directory Access Protocol MVC Model View Controller SSL Secure Socket Layer XHTML Extensible HyperText Markup Language 3 Palvelinarkkitehtuuri Järjestelmällä on useita käyttäjiä, jotka käsittelevät samanaikaisesti yhteisiä tietoja. Tästä johtuen järjestelmä on client-server -perustainen. Se koostuu useasta WWW-selaimesta sekä yhdestä WWW- ja yhdestä tietokantapalvelimesta. Tietokantapalvelin sisältää kaiken järjestelmän datan. Lisäksi järjestelmään on varattu mahdoillisuus käyttää myöhemmin ulkoisia autentikointipalvelimia. Järjestelmän XHTML-pohjaista käyttöliittymää käytetään WWW-selaimella ja sen sovelluslogiikka sijaitsee WWW-palvelimella. WWW-selaimen ja -palvelimen keskinäinen vuorovaikutus tapahtuu SSL-tunneloidulla HTTP-protokollalla Internetissä. WWW-palvelin hakee tarvitsemansa datan tai tekee tarvittavat lisäykset tai muutokset tietokantaan ottamalla yhteyden tietokantapalvelimeen. Järjestelmän palvelinarkkitehtuuri esitellään kuvassa 1. 4

www-palvelin Tietokantapalvelin Internet HTTPS HTTPS Käyttäjä #1 Käyttäjä #2 Kuva 1: Järjestelmän client-server -perustainen arkkitehtuuri 3.1 WWW-palvelin WWW-palvelimeksi käy mikä tahansa PHP5:tä tukeva UNIX-pohjainen palvelin. 3.2 Tietokantapalvelin Tiedonhallintajärjestelmänä käytetään PostgreSQL-relaatiotietokantaa. Kyselyt siihen tehdään SQL-kyselykielellä. 3.3 Selaimet Selaimen tehtävänä on näyttää WWW-palvelimen palauttamat XHTML-dokumentit sekä pyytää käyttäjän valitsemia uusia dokumentteja. 3.4 Autentikointipalvelimet Järjestelmässä on varauduttu ulkoisten LDAP- ja Sibboleth-autentikointipalveluiden käyttöön toteuttamalla näille rajapinnat. Toistaiseksi ulkoisia autentikointipalvelimia ei ole. 5

3.5 Vaihtoehtoiset ratkaisut Client-server-toteutukselle ei ole sellaisia vakavasti otettavia vaihtoehtoja, joiden käyttö ei aiheuttaisi riskejä toteutuksen osalta. Selainpohjaiselle käyttöliittymälle vaihtoehtona voisi olla esimerkiksi Javalla toteutettu asiakasohjelmisto. Tämä ratkaisu kuitenkin hylättiin, koska erillinen asiakasohjelmisto vaatisi sovelluksen asentamista ja toisaalta selaimessa on jo paljon aputoimintoja (esimerkiksi tulostaminen), jotka olisi täytynyt toteuttaa erillisessä asiakasohjelmistossa itse. 4 Järjestelmän arkkitehtuuri Tässä dokumentissa käsitellään vain Hirviön-järjestelmän palvelinohjelmistoa, koska asiakasohjelmistona toimii mikä tahansa vaatimukset täyttävä kolmannen osapuolen valmistama selain. Järjestelmän korkean tason modulijaottelu on esitelty kuvassa 2. Järjestelmän perusarkkitehtuuri toteuttaa MVC-suunnittelumallin, missä tietokanta ja DataManagement-moduli vastaavat Model-osaa, GUI-moduli View-osaa ja sovelluslogiikkamoduli Controller-osaa. Lisäksi järjestelmään kuuluu autentikointia ja Audit Trail -lokia hoitava AAA-moduli. Kuva 2: Järjestelmän modulit 6

4.1 Järjestelmän framework Yleisin tapa toteuttaa selainpohjaisia sovelluksia PHP:llä on tehdä tilaton palvelinsovellus. Tämä toteutetaan muokkaamalla joukkoa staattisia HTML-sivuja dynaamisiksi skriptaamalla haluttu toiminnallisuus HTML-koodin joukkoon. Tälläinen toteutustapa on virhealtis ja sen ylläpidettävyys on huono. Näiden välttämiseksi järjestelmälle toteutetaan alusta, joka tarjoaa seuraavat ominaisuudet: Tilallinen sovellus. Jos sovellus muistaa tilansa, on mahdollista tehdä joustavampia toteutuksia kuin tilattomalla mallilla, jonka täytyy joka kerta läpikäydä kaikki edeltävät tilat päästäkseen haluttuun tilaan. Tapahtumapohjainen käyttöliittymä. Tapahtumien aiheuttamiseen ja niiden käsittelyyn perustuva käyttöliittymä saadaan helposti eriytettyä itse sovelluslogiikasta. Tämä parantaa ylläpidettävyyttä. PHP ei sellaisenaan tarjoa tapahtumapohjaista käyttöliittymäkirjastoa. Järjestelmälle toteutetaan framework, joka välittää tietoa tapahtumista MVC-mallin View-osasta sen Controllerosaan. Framework tarjoaa EventTrigger luokan, joka tarjoaa HTTP POST- ja GET-datan välityksellä aiheutettuja tapahtumia. Käyttöliittymäkehittäjät voivat tämän luokan perimällä toteuttaa esimerkiksi tapahtuman aiheuttavan submit-painikkeen tai linkin. EventTriggeroliolle kerrotaan tapahtuman käsittelijän nimi. Tapahtuman käsittelijä löydetään PHP:n reflektiotuen avulla. 4.1.1 Tapahtumat Yhdellä hetkellä yhdelle käyttäjälle on tarjolla rajallinen määrä toimintoja. Framework välittää sovellukselle ainoastaan sallittuja toimintoja vastaavat tapahtumat. Sallitut tapahtumat määräytyvät käyttöliittymästä siten, että kaikkia käyttöliittymässä olevia järjestelmään itseensä viittaavia hyperlinkkejä ja XHTML-lomakkeiden painikkeita vastaa jokin tapahtuma. 4.1.2 Esimerkki tapahtuman laukaisusta Hirviön opettajakäyttöliittymän valikossa on toiminto aktiivisen työryhmän vaihtamiseen. Toiminto on toteutettu linkillä, joka laukaisee tapahtuman ChangeWorkgroup linkkiä painettaessa. 5 Sovelluslogiikkamoduli Sovelluslogiikkamoduli on järjestelmän ydin ja sisältää varsinaiset toiminnot. Se toteuttaa MVC-mallin Controller-osan. Sovelluslogiikkamodulissa jokaiselle odotetulle tapahtumalle rakennetaan tapahtumankäsittelijä, jossa määritellään tapahtumaa vastaava toiminto. Toiminnon suoritettuaan se päivittää näkymää ja luo sitä vastaavan XHTML-dokumentin WWWselaimelle lähetettäväksi. Moduleista sovelluslogiikkamoduli kehittyi ja laajentui voimakkaimmin projektin aikana, sovelluslogiikkomodulissa erityisesti luokka HirvioApplication. 7

5.1 Tärkeimmät luokat 5.1.1 HirvioApplication HirvioApplication sisältää kaikki järjestelmän tapahtumankäsittelijät, kunkin omana metodinaan. Tapahtumankäsittelijät on nimetty kaavan on<tapahtumannimi> mukaan. Tällöin niitä osataan kutsua frameworkista tapahtuman ilmetessä. 5.2 Esimerkki tapahtumankäsittelijän toteuttamisesta Hirviön opettajakäyttöliittymän valikossa on toiminto aktiivisen työryhmän vaihtamiseen. Toiminnon käyttäminen saa aikaan tapahtuman ChangeWorkgroup. Tälle tapahtumankäsittelijäksi on toteutettu HirvioApplication-luokkaan metodi onchangeworkgroup(), joka vaihtaa käyttäjän aktiivisen työryhmän uuden valinnan mukaiseksi sekä päivittää näkymän. 6 Käyttöliittymämoduli Käyttöliittymämodulilla luodaan järjestelmän käyttöliittymä. Moduli toteuttaa MVC-mallin View-osan. Käyttöliittymämoduli on lopullisessa järjestelmässä erittäin laaja. Sen rakenne selviää myöhemmin toimitettavasta automaattisesti generoidusta PHPDoc-dokumentaatiosta. Projektiryhmä ei näe täydellisen rakenteen selvittämistä tässä dokumentissa tarpeelliseksi vaan antaa sen sijaan yhden esimerkin käyttöliittymäkomponenttien hyödyntämisestä. 6.1 Tärkeimmät luokat 6.1.1 View View on abstrakti luokka, jonka realisaatioiden avulla voidaan luoda näkymiä. Vie määrittelee pohjan XHTML-dokumenttien muodostamiseen ja tulostamiseen. Hirviölle on luotu Viewistä oma realisaatio, BasicView, joka määrittelee juuri Hirviölle sopivan näkymän rakenteen. Toisin sanottuna BasicView määrittelee, millaisista elementeistä kaikki Hirviön WWWsivut koostuvat. BasicView-luokka sisältää elementtejä, kuten esimerkiksi valikoita tai lomakkeita. Elementit ovat abstraktin Element-luokan ilmentymiä. Uusia näkymiä voidaan luoda muuttamalla tai vaihtamalla View-instanssin sisältämiä elementtejä. Kaikki järjestelmän XHTML-koodi sijaitsee View-luokissa ja niiden sisältämissä elementeissä, ja täten sovelluslogiikkamodulilta abstraktoituna. 6.1.2 Element Element on abstrakti luokka, joka mallintaa jotakin XHTML-elementtiä. ViewElement-luokan tärkein toiminnallisuus on XHTML:n palauttaminen ja mahdollisten lomake-elementtien sisältäminen 6.1.3 ValidatingElement ValidatingElement on Elementin aliluokka, ja se laajentaa Elementin ominaisuuksia validoitumisominaisuudella. ValidatingElement-luokkia voidaan hyödyntää erityisesti lomakkeiden käsittelyssä siten, että lomakkeestä ei yritetä lähettää tietoja muualle ennen kuin lomake kokonaisuutena validoituu. 8

6.1.4 FormElement Kutakin XHTML:n lomake-elementtiä varten rakennetaan oma luokkansa. Luokalla on tieto hyväksyttävän syötteen muodosta ja käyttäjän elementtiin antamasta syötteestä. Luokka osaa validoida käyttäjän syötteen annettuja ehtoja vasten. FormElement on abstrakti luokka, jonka realisaatioita kaikki lomake-elementit ovat. 6.2 Esimerkki käyttöliittymäkomponenttien rakentamisesta Ensimmäisellä implementaatiokierroksella toteutettiin kaksi näkymää. Sisäänkirjautumisnäkymä pitää sisällään yhden validoituvan sisäänkirjautumislomakkeen, kuva 3. Muistiinpanon lisäysnäkymä on monimutkaisempi, kuva 4. Se pitää sisällään valikon ja sisällyttäjäelementin. Sisällyttäjäelementtiin taas on koottu opiskelijasta tietoa näyttävä elementti, validoituva muistiinpanonsyöttämiselementti sekä muistiinpanoja sisältävä elementti. Muistiinpanon syöttäminen on käyttöoikeusryhmä opettajalle kuuluva toiminto. Sekä sisäänkirjautumislomake että muistiinpanonsyöttämiselementti on vuorostaan rakennettu FormElement-luokkien avulla. Kuva 3: Sisäänkirjautumisnäkymän rakenne Kuva 4: Opettajan muistiinpanonäkymän rakenne 9

7 Tietokantamoduli Tietokantamoduli yhdessä tietokannan kanssa toteuttaa MVC-mallin Model-osan. Modulin rakenne on esitelty kuvassa 5. Järjestelmä käyttää tietokantamodulia kaikkeen vuorovaikutukseen tietokannan kanssa. Kaikki tietokantadataan tehtävät kyselyt, lisäykset, poistot tai muutokset tehdään tämän modulin avulla. Lisäykset, poistot ja muutokset tallennetaan Audit Trail -lokiin. Kuva 5: Tietokantamodulin rakenne 7.1 Tärkeimmät luokat 7.1.1 DataManager DataManager abstraktoi tietokannan käsittelyn sovelluslogiikkamodulilta. DataManager käyttää DatabaseConnection-luokkia tietokannan kanssa kommunikoimiseen. 7.1.2 DatabaseConnection DatabaseConnection on rajapinta tietokankyselyiden tekemiseen. Rajapinnan käyttäminen mahdollistaa tietyissä rajoissa järjestelmän käyttämän tiedonhallintajärjestelmän vaihtamisen. Järjestelmä käyttää PostgreSQL:ää tiedonhallintajärjestelmänä, ja sille toteutetaan tässä vaiheessa yksi DatabaseConnection-luokka, PostgreSqlConnection. Luokka käyttää PearDBpakettia siirrettävyyden parantamiseksi. PostgreSQLConnection toteuttaa DatabaseConnectionrajapintaa eikä lisää muita toiminnallisuuksia. DatabaseConnection määrittelee metodeita kantayhteyksien hallintaan ja tietokantakyselyiden tekemiseen. 8 AAA-moduli AAA-modulin tehtäviin kuuluu käyttäjien todentaminen, käyttäjien oikeuksien hakeminen ja Audit Trail -lokin pitäminen. Modulin rakenne on esitelty kuvassa 6. 10

Kuva 6: AAA-modulin rakenne 8.1 Todennus Todennus eli autentikointi on toteutettu siten, että moduli voi käyttää useampia todennusmenetelmiä, joista yksi on järjestelmän sisäinen tietokantaa käyttävä todennusmenetelmä. Kaikki todennusmenetelmät toteuttavat AuthenticationMethod rajapinnan. Todennustoiminnot toteuttavat vaatimusmäärittelyn vaatimukset F12, F13, F14 ja N3. 8.2 Audit Trail Audit Trail on loki järjestelmässä tapahtuvista datan muutoksista sekä sisään- ja uloskirjautumisista. Datan muutoksia ovat tietokantaan tehtävät lisäykset, poistot ja muutokset Moduli tallentaa lokin tietokantaan tapahtuman ajanhetken, käyttäjätunnuksen, sessioid:n, käytetyn IP-osoitteen, tapahtuman tyypin sekä mahdollisia lisätietoja. Audit Trail toteuttaa vaatimusmäärittelyn vaatimuksen F11. 8.3 Sisään- ja uloskirjautuminen Modulia käytetään erityisesti käyttäjien sisäänkirjautumisissa. Moduli todentaa sisäänkirjautuvat käyttäjät ja hakee tiedon heidän oikeuksistaan. Kunkin käyttäjän tietoihin on tallennettu tieto siitä, mitä menetelmää todentamiseen käytetään. Moduli hakee tämän tiedon käyt- 11

täjätietokannasta ennen varsinaista todentamista. Jos todennus onnistuu, moduli luo käyttäjää esittävän User-olion johon on koottu tärkeimmät tiedot käyttäjästä. AAA-modulin kirjautumisprosessi on toteutettu vaatimusmäärittelyn käyttötapauksen U9 mukaisesti ja tapahtuu seuraavasti: Käyttäjän sisäänkirjautumislomakkeeseen kirjoittaman käyttäjätunnuksen (hirvio id) perusteella haetaan käyttäjätietokannasta käyttäjän tunnistusmenetelmä sekä tunnistuksessa käytettävä tunnus, joka voi olla eri kuin käyttäjätunnus. Jos käyttäjätunnusta ei löydy kannasta, kirjataan virhe Audit Trailiin ja palautetaan virhe. Katsotaan onko kyseiselle todennusmenetelmälle toteutusta, ja jos on, luodaan menetelmän toteuttavasta luokasta instanssi. Jos kannassa oleva todennusmetodi on tuntematon tai sillä ei ole toteutusta, kirjataan virhe Audit Trailiin ja palautetaan virhe. Todennusluokan authenticate-metodi suorittaa varsinaisen todennuksen. Metodille annetaan parametreinä käyttäjän autentikointitunnus sekä salasana. Sisäistä tietokantaa todennusmenetelmänä käytettäessä authenticate-metodi luo kantakyselyn joka hakee käyttäjää tunnuksen ja salasanan md5-tiivisteen perusteella. Jos käyttäjä löytyy näillä ehdoilla, on käyttäjä todennettu. Jos käyttäjää ei löydy tunnuksen ja tiivisteen perusteella, kirjataan epäonnistunut todennus Audit Trailiin ja palautetaan virhe. Viimeisenä tehtävänä on hakea tietokannasta käyttäjää koskevat tiedot ja rakentaa niistä User-olio joka palautetaan todennuskutsun tekijälle. Ennen palautusta onnistunut todennus kirjataan Audit Trailiin. Kaikista kirjautumisyrityksistä menee siis tieto Audit Trailiin riippumatta kirjautumisen lopputuloksesta. Audit Trail sisältää tiedon mahdollisen epäonnistumisen syystä, mutta käyttäjälle syytä ei tietoturvasyistä kerrota. 8.4 Tärkeimmät luokat 8.4.1 Authenticator Authenticator-luokka huolehtii AAA:n todennus- ja valtuutustoiminnoista. Authenticator todentaa käyttäjät Hirviö-ID:n, todennus-id:n ja todennussalasanan avulla sekä hakee tiedon käyttäjien oikeuksista. Varsinainen todennus hoidetaan AuthenticationMethod-rajapinnan toteuttavan todennusluokan authenticate-metodin avulla. Autentikoinnin jälkeen luodaan User-olio joka sisältää tiedot käyttäjästä ja tämän oikeuksista. 8.4.2 AuthenticationMethod-rajapinnan toteuttavat luokat Varsinaisen todennuksen suorittavaa kutakin todennusmenetelmää varten oleva AuthenticationMethodrajapinnan täyttävät luokat. Rajapinnan mukaan nämä luokat tarjoavat ulospäin authenticatemetodin jolla todennus suoritetaan. Järjestelmään on suunniteltu kolme erilaista todennusluokkaa: DatabaseAuthenticationMethod Suorittaa todennuksen järjestelmän oman käyttäjätietokannan perusteella. LdapAuthenticationMethod Todentaa käyttäjän LDAP-palvelimen avulla. SibbolethAuthenticationMethod Todentaa käyttäjän TKK:n ATK-keskuksen Sibbolethjärjestelmän avulla. Näistä DatabaseAuthenticationMethod on toteutettu tämän projektin puitteissa. Muiden myöhempää toteutusta varten on varattu rajapinta. 12

8.4.3 Logger Logger huolehtii AAA:n Accounting-osuudesta. Tietoa tallennetaan Audit Trailiin Loggerluokan metodien kautta. Luokka sisältää erikseen omat metodit muutamille tapahtumille sekä yleiset kirjausmetodit muille tapahtumille. 9 Tietokantarakenne Tietokanta koostuu yksilöjoukoista Users, Students, Notes, Files, Thesis, Workgroups ja Log. Users kuvaa järjestelmän käyttäjiä yleensä. Sillä on aliluokka Students, joka kuvaa johonkin järjestelmään syötetyn opiskelijan tietoja. Myöhemmässä vaiheessa tietokantaan lisätään myös yksilöjoukkoja, jotka vastaavat muita oikeustasoryhmiä. Järjestelmän opettajat voivat kuulua työryhmiin. Tietokannassa opettajalle voidaan antaa oikeus johonkin työryhmään kokonaisuudessaan tai yhden työryhmän sisällä yhteen opiskelijaan. Opettajalla voi olla tällaisia oikeuksia miten paljon hyvänsä. Järjestelmää käytetään muistiinpanojen tekemiseen. Kukin muistiinpano liittyy yhteen opiskelijaan ja yhteen työryhmään. Järjestelmään tallennettavat tiedostot liittyvät myös opiskelijaan ja yhteen työryhmään. Lisäksi järjestelmä pitää lokia tapahtumista. Järjestelmä pitää tietoja lisenssiaattitöistä ja väitöskirjoista thesis-taulussa. Loki kuvataan yhdellä tietokantataululla. Tietokantarakenne on esitetty ER-kaaviona kuvassa 7. 9.1 Users Users-taulu sisältää perustietoa kustakin järjestelmän käyttäjästä. Perustietoja taulusta on lueteltu seuraavassa listassa. Hirviö-ID (hirvio id TEXT) Käyttäjätunnus Hirviö-järjestelmään. Nimi (firstname TEXT, lastname TEXT) Autentikointimenetelmä (authmethod TEXT) Käyttäjää voidaan tunnistaa myös ulkoisen autentikointipalvelun kautta. Kenttä sisältää tiedon siitä, mitä menetelmää käyttäen käyttäjä tunnistetaan. Autentikointi-ID (username auth TEXT) Käyttäessä ulkoista autentikointia, käyttäjän tunnus k.o. järjestelmässä tallennetaan tähän kenttään. Salasana (internal password hash TEXT) Salasanan tiiviste. Tätä salasanaa käytetään käyttäjän tunnistautuessa järjestelmän omaa autentikointia käyttäen. Käyttäjätyyppi (usertype TEXT) Opettajatyyppi (teachertype TEXT) Aktiivinen työryhmä (active INT) Käyttäjän oletustyöryhmä Kieli (language INT) Käyttäjän kieliasetus. Käyttöliittymä voidaan toteuttaa usealla kielellä. Puhelinnumero (phonenumber TEXT) Sähköpostiosoite (email TEXT) 13

9.2 Students Vaatimusmäärittelyn kohta F3a. Students-taulu sisältää ne tietokentät, joita käytetään vain käyttäjän ollessa tyyppiä opiskelija. Näihin kuuluu opiskelijan statusta näyttävät muuttujat, ja tarkemmat yhteystiedot. Perusopiskelijastatus (undergraduate status TEXT) Tieto siitä, onko opiskelija perusopiskelija, pääaineopiskelija, suorittaa diplomityötä tms. Jatko-opiskelijastatus (postgraduate status TEXT) Tieto siitä, missä vaiheessa jatkoopintoja opiskelija on. Hirviö-id (hirvio id TEXT PRIMARY KEY) Käyttäjätunnus Hirviö-järjestelmään. Osasto (deparment TEXT) Opiskelijan osasto Pääaine (major TEXT) Opiskelijan pääaine Sivuaine (minor TEXT) Opiskelijan sivuaine Vuosikurssi (year TEXT) Opiskelijan vuosikurssi Muut tiedot (other info TEXT) Vapaamuotoinen teksti Lisenssiaattityön status (lic thesis status TEXT) Väitöskirjan status (doc thesis status TEXT) Diplomityön aihe hyväksytty (mt accepted topic INT) Diplomityö hyväksytty (mt accepted thesis INT) 9.3 Notes Vaatimusmäärittelyn kohta F1. Notes-taulu sisältää kaikki järjestelmään syötetyt muistiinpanot. Kaikki ajat tallennetaan kenttään tyyppiä INT, sillä ajat tallennetaan UNIX-aikaleimana (ks. kohta Hylätyt ratkaisut). Id (id INT PRIMARY KEY) Muistiinpanoa yksilöivä tunnus Sisältö (contents TEXT) Muistiinpanon teksti Status (status TEXT) Muistiinpanon status, eli aktiivinen, arkistoitu jne. Opiskelijan tunnus (student hirvio id TEXT) Muistiinpanot liittyvät aina tiettyyn opiskelijaan, ja tämän tunnus tallennetaan kenttään. Työryhmä (workgroup id INT) Muistiinpano liittyy tiettyyn työryhmään. Muistiinpanon luoja (creator hirvio id TEXT) Muistiinpanon luoneen henkilön Hirviö-id. Muokkaaja (modifier hirvio id TEXT) Muistiinpanoa viimeksi muokanneen henkilön Hirviöid. Eräpäivä (due date INT) Muistiinpanon eräpäivä. Luontiaika (creation time INT) Muokkausaika (modification time INT) 14

9.4 WorkgroupAuthorizations Taulu sisältää tiedon opettajien työryhmistä. Opettajan Hirviö-id (teacher hirvio id TEXT) Työryhmä-id (workgroup id INT) Opiskelijan Hirviö-id (student hirvio id TEXT) 9.5 Thesis Vaatimusmäärittelyn kohta F5. Taulu sisältää tiedot opiskelijakohtaisesti lopputyöstä (ts. diplomityö tai muu). Lopputyöaihe (thesis topic TEXT) Osastoneuvoston hyväksymispäivämäärä aiheelle (dc accepted topic INT) Osastoneuvoston hyväksymispäivämäärä lopputyölle (dc accepted thesis INT) Lopputyön status (thesis status INT) Lopputyön valvoja (supervisor hirvio id INT) Lopputyön ohjaaja (director hirvio id INT) Opiskelijan Hirviö-id (student hirvio id TEXT REFERENCES Students (hirvio id) PRI- MARY KEY) viittaa Students tauluun (ON DELETE RESTRICT) 9.6 Log Järjestelmän loki. Aika (time INT PRIMARY KEY) Tapahtuman kellonaika Hirviö-id (hirvio id TEXT) Käyttäjän hirviö-id IP-osoite (ip address TEXT) Session tunniste (session id TEXT) Tapahtuma (event TEXT) Tapahtuman tyypi, esim. (add note, login failed). Kuvaus (info TEXT) Tarkempi kuvaus tapahtumasta. 9.7 Files Vaatimusmäärittelyn kohta F4. Opiskelijoihin ja työryhmiin liittyvät tiedostot. Tiedoston nimi (filename VARCHAR(1024) PRIMARY KEY) Tiedoston nimi Hirviö-id (student hirvio id TEXT REFERENCES Students (hirvio id)) Opiskelijan hirviöid Työryhmä-id (workgroup id INT) 15

9.8 Workgroups Workgroups sisältää työryhmien nimet ja id:t. Tunniste (id INT PRIMARY KEY) Työryhmää yksilöivä tunniste Nimi (name TEXT) Työryhmän nimi 9.9 ER-kaavio Kuvassa 7 esitetyssä kaaviossa kuvataan järjestelmän tietokanta. Kuva 7: Tietokanta-arkkitehtuuri 9.10 Hylätyt ratkaisut Kaikki päivämäärät tallennetaan tietokantaan UNIX-timestampina integer-kenttään. PostgreSQL tukee myös erityistä päivämääräkenttää, mutta palauttaa kaikki päivämäärät pelkkänä stringinä, jonka rakenne riippuu konfiguraatiotiedoston asetuksista 1. PHP 5.0.0-5.0.2:n strtotime()-funktiossa on lisäksi bugeja 2 jotka voivat aiheuttaa virheitä kun stringiä tulkitaan. UNIX timestamp sen sijaan on yksiselitteinen ja PHP saa sen helposti muutettua haluttuun muotoon. 10 Järjestelmän siirrettävyys eri alustoille Järjestelmä toteutetaan käyttäen PHP5-kieltä ja sen kirjastoja. Järjestelmän voi tästä johtuen siirtää sellaisenaan käytettäväksi useimmille Unix-pohjaisille käyttöjärjestelmille. 1 http://www.postgresql.org/docs/7.4/static/datatype-datetime.html, kohta 8.5.2: Date/Time Output 2 http://fi.php.net/manual/en/function.strtotime.php 16

11 Käyttöliittymän suunnitteluperiaatteet Hirviön tapauksessa mahdollisuudet varsinaiseen hallittuun käytettävyystestaukseen ovat varsin rajoittuneet. Asiakas on liian kiireinen osallistuakseen merkittävässä määrin testaukseen, joskin mielipiteitä käyttöliittymästä varmasti saadaan. Terveen järjen ohjaamana suurimmilta virheiltä pitäisi välttyä, mutta lisäksi on syytä määritellä tiettyjä parametreja ohjaamaan suunnittelua. Minkä tahansa suoraan loppukäyttäjälle tarkoitetun järjestelmän sujuvaan ja intuitiiviseen toimintaan on syytä kiinnittää huomiota. Muuten käy helposti niin, että järjestelmää käytetään vain pakosta ja silloinkin pitkin hampain. Hirviön tapauksessa sujuva käyttö oli vaatimuksena alusta lähtien. Tärkeimmän käyttäjäryhmän, professorien, on kyettävä käyttämään järjestelmää vastaanotollaan. Järjestelmän ydintoiminnalisuus ei voi olla kovin monen valikon ja näytön takana, jos professorin on tarkoitus käyttää sitä opiskelijan kanssa keskustellessaan. Esimerkiksi opiskelijan tietojen haun täytyy onnistua korkeintaan parin ruudun välityksellä ja uusi muistiinpano täytyy päästä lisäämisen opiskelijaruudulta mielellään yhdellä painalluksella. Ylläpitotyyppiset toimannat voivat olla käyttöliittymässä syvemmälläkin, mutta kaiken ydintoiminnallisuuden pitäisi olla korkeintaan kolmen näytön päässä, missä tahansa käyttöliittymän osassa sitten ollaankaan. Käyttöliittymän tehokkuus ei kuitenkaan saa rikkoa yhtenäistä ilmettä tai toimintaperiaatteita. Järjestelmän täytyy tietenkin myös toimia riittävän nopeasti. Vähillä klikkauksilla navigoitavan käyttöliittymän edut katoavat, jos jokaista uutta näyttöä joutuu odottelemaan sekuntikaupalla. Hidas reagointi annettuihin komentoihin heikentää käytettävyyttä ja erityisesti käyttömukavuutta toki muutenkin. Odotettavissa olevilla käyttäjämäärillä riittävän nopean toiminnan ei kuitenkaan pitäisi olla ongelma. Terveellä järjellä on ikävä taipumus unohtua kiireen lisääntyessä. Virheiden etsimisessä auttaa heuristinen arviointi asettamalla selvät periaatteet, joiden perusteella järjestelmää voidaan analysoida. Varsinaisen arvioinnin voi tehdä milloin vain tarvitsematta sopia aikataulusta testaajien kanssa. Heuristisesta arvioinnista ja sen käytöstä projektissa on kerrottu enemmän aiheeseen liittyvässä SEPA-päiväkirjassa. 12 Tietoturva Vaikkei järjestelmään tallennetakaan mitään liikesalaisuuksiin verrattavia tietoja, sisältää se runsaasti erilaisia opiskelijoiden henkilökohtaisia yksityisyydensuojan piirissä olevia tietoja. Tietoturvanäkökohtiin on siis kiinnitettävä erityistä huomiota. Järjestelmän tärkeimmät tietoturvaominaisuudet ovat käyttäjien tunnistaminen ja todentaminen, oikeustasot ja niiden hallinta, sekä tapahtumien kirjaus. 12.1 Käyttäjien tunnistus ja todennus Käyttäjien ensisijaisena tunnisteena toimii hirvio id -niminen vapaavalintainen merkkijono. Tarkoituksena olisi, että opiskelijoiden tunniste on opiskelijanumero ja henkilökunta käyttäisi TML:n käyttäjätunnusta. Käyttäjän todentamiseen eli käyttäjätunnuksen käyttäjän varmistamiseen järjestelmässä on kolme salasanapohjaista menetelmää: Järjestelmän oma tietokanta, LDAP sekä TKK:n ATK-keskuksen Shibboleth-järjestelmä. Näitä kahta jälkimmäistä ei kuitenkaan oteta käyttöön tämän projektin puitteissa. AAA-moduli on suunniteltu siten, että menetelmiä on helppo lisätä. Näillä ominaisuuksilla toteutetaan vaatimusmäärittelyn vaatimukset F12, F13, F14 ja N3. 12.1.1 Järjestelmän oma tietokanta Toteutukseltaan yksinkertaisin todennusmenetelmä on vaatimuksessa F12 esitetty järjestelmän oman tietokannnan käyttäminen. Siinä tietokantaan muiden käyttäjätietojen yhteyteen tal- 17

lennetaan salasanan md5-tiiviste. Todennus tapahtuu tekemällä käyttäjätauluun kysely, jonka rajoitteina ovat käyttäjätunnus ja salasanatiiviste. Jos kysely tuottaa tuloksen, on käyttäjätunnussalasana-pari hyväksytty. 12.1.2 LDAP PHP:ssä on tuki LDAP:lle. LDAP-todennusta ei oteta käyttöön tämän projektin puitteissa, mutta sille on tehty valmiiksi toteutusrunko. 12.1.3 ATK-keskuksen Shibboleth TKK:n ATK-keskus on kehittämässä opiskelijoiden todentamiseen tarkoitettua Shibbolethnimistä järjestelmää, joka sopisi Hirviön käyttöön erittäin hyvin, koska se kattaa kaikki TKK:n opiskelijat ja hyödyntää jo olemassa olevia salasanoja. Järjestelmä on kuitenkin vielä testausvaiheessa eikä sitä pystytä ottamaan käyttöön projektin puitteissa. Myös sille on kuitenkin olemassa toteutusrunko. 12.2 Oikeustasot Oikeustasoilla kontrolloidaan käyttäjien pääsyä järjestelmään tallennettuun tietoon sekä tietojen muuttamista. Kuvaus käytettävistä käyttäjätasoista sekä niiden oikeuksista löytyy vaatimusmäärittelydokumentista. 12.3 Tapahtumien kirjaus eli Audit Trail Audit Trail on nimitys toiminnolle, joka kirjaa järjestelmässä ylös kaikki merkittävät tapahtumat. Audit Trailin tarkoitus on auttaa mahdollisten tietomurtojen sekä muiden ongelmatapausten selvittämistä. Audit Trailiin tehdään kirjaus seuraavissa tapauksissa: Käyttäjä kirjautui sisään järjestelmään Käyttäjä yritti kirjautua järjestelmään, mutta kirjautuminen epäonnistui Käyttäjä kirjautui ulos järjestelmästä Käyttäjä lisäsi järjestelmään uuden muistiinpanon Käyttäjä muutti järjestelmässä olevaa muistiinpanoa Käyttäjä muutti opiskelijan tietoja tai lisäsi uuden opiskelijan Käyttäjä muutti omia profiilitietojaan Kaikki ylläpitokäyttöliittymän kautta tehdyt muutokset Audit Trail toteuttaa vaatimusmäärittelyn vaatimuksen F11. 12.4 Sessionhallinta Sessionhallinta on tärkeä osa tietoturvaa, koska session kaappaaminen antaa pahimmassa tapauksessa vapaat kädet järjestelmän tietojen tutkimiseen ja muuttamiseen. Sessio tuhotaan aina uloskirjautumisen ja session vanhentumisen yhteydessä. Kun sessio luodaan, palvelin lähettää asiakkaalle yksilöllisen HTTP-evästeen, jonka perusteella sessio tunnistetaan myöhemmin. Järjestelmän tasolla pidetään kirjaa siten, että kutakin sessiota voi käyttää vain siitä IP-osoitteesta, josta sessio aloitettiin. Lisäksi kaikki HTTPliikenne tunneloidaan SSL:n läpi, mikä tekee evästeiden kaappaamisesta vaikeaa. Tämä kaikki estää varsin hyvin session kaappaamisen. 18

12.5 Syötteiden tarkistaminen Kaikki käyttäjältä tuleva syöte tarkistetaan ja siitä poistetaan tai tehdään vaarattomaksi (eskeipataan) kaikki merkit ja merkkijonot jotka järjestelmä voi tulkita muuksi kuin puhtaaksi tekstiksi. Näitä ovat: lainausmerkit Erityisen vaarallinen on yksinkertainen lainausmerkki, joka rikkoo läpi päästessään SQL-kyselyn ja pahimmassa tapauksessa mahdollistaa omien kyselyiden tekemisen kantaan. Tämä estetään, joko suodattamalla lainausmerkit syötteistä pois tai tekemällä ne vaarattomiksi lisäämällä niiden eteen kenoviiva (eli eskeippaamalla ne). SQL-komennot Vihamielisten SQL-komentojen pääsy kantaan muualla kuin vaarattomana tekstikentän sisällä on estetty, mikäli lainausmerkkien tarkistus toimii. HTML-tagit HTML-tagien pääsy syötteisiin ei aiheuta niin suurta tietoturvariskiä, kuin vihamieliset SQL-komennot, mutta niillä voi esimerkiksi sotkea käyttöliittymän tai aiheuttaa kiusaa muulla tavalla. Tämän estämiseksi tagit suodatetaan pois esimerkiksi muistiinpanoteksteistä. 12.6 Muita tietoturvahuomioita Salasanojen käsittely ohjelman sisällä Salasanojen ja muiden vastaavien käsittely ohjelman sisällä pitää olla niin vähäistä kuin mahdollista. Esimerkiksi todennuksessa kysytään kannasta, onko käyttäjän antama salasana oikea sen sijaan, että otettaisiin oikea salasana ulos kannasta ja vertailtaisiin sitä käyttäjän antaman kanssa. Tämä menettely hankaloittaa jossain määrin salasanojen urkkimista. Ohjelmistoversiot Järjestelmässä tarvittavista ulkopuolisista ohjelmistoista (Apache, PHP, PostgreSQL) on käytössä versiot, joissa ei ole pahoja tunnettuja tietoturva-aukkoja. Muut palvelinkoneessa pyörivät ohjelmat Mikäli järjestelmää ajavassa palvelinkoneessa ajetaan myös muita ohjelmistoja, pitää varmistaa, ettei niitä pysty käyttämään hyväksi järjestelmään murtauduttaessa. Palvelinkoneen paikalliset tunnukset Järjestelmää ajavassa palvelinkoneessa on minimimäärä paikallisia käyttäjätunnuksia, koska niiden avulla on mahdollista päästä käsiksi tietokantaan. Palvelinkoneen fyysinen turvallisuus Palvelinkoneen pitää sijaita fyysisesti paikassa, johon asiattomat henkilöt eivät pääse. (esimerkiksi palvelinhuoneessa) 19