Hirviö Tekninen spesifikaatio

Hirviö Tekninen spesifikaatio Jani Heikkinen Anssi Kalliolahti Jukka Larja Kim Nylund Liia Sarjakoski Samuli Sorvakko Timo Toivanen 30. marraskuuta 2004 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................................... 4 3.2 Tietokantapalvelin................................. 4 3.3 Selaimet....................................... 4 3.4 Vaihtoehtoiset ratkaisut.............................. 5 4 Järjestelmän arkkitehtuuri 5 4.1 Järjestelmän framework.............................. 5 4.1.1 Tapahtumat................................. 6 5 Sovelluslogiikkamoduli 7 5.1 Tärkeimmät luokat................................. 7 5.1.1 HirvioApplication............................. 7 6 Käyttöliittymämoduli 7 6.1 Tärkeimmät luokat................................. 7 6.1.1 View..................................... 7 6.1.2 Element................................... 7 6.1.3 ValidatingElement............................. 7 6.1.4 FormElement................................ 8 6.2 Toteuteutuksen arkkitehtuuri implementaatiokierroksella 1........... 8 7 Tietokantamoduli 8 7.1 Tärkeimmät luokat................................. 9 7.1.1 DataManager................................ 9 7.1.2 DatabaseConnection............................ 9 8 AAA-moduli 10 8.1 Todennus...................................... 10 8.2 Audit Trail..................................... 10 8.3 Sisään- ja uloskirjautuminen............................ 10 8.4 Tärkeimmät luokat................................. 11 8.4.1 Authenticator................................ 11 8.4.2 AuthenticationMethod-rajapinnan toteuttavat luokat.......... 11 8.4.3 Logger.................................... 11 8.5 Rajapinnat..................................... 12 8.5.1 Authenticator.authenticate()....................... 12 2

8.5.2 AuthenticationMethod.authenticate().................. 12 8.5.3 Logger.addLogin()............................. 12 8.5.4 Logger.addLogout()............................ 12 8.5.5 Logger.addFailedLogin().......................... 12 8.5.6 Logger.addEvent()............................. 12 8.5.7 Logger.addEventWithId()......................... 12 8.6 Ensimmäisellä iteraatiokierroksella toteutettavat ominaisuudet........ 12 9 Tietokantarakenne 13 9.1 Users......................................... 13 9.2 Students....................................... 13 9.3 Notes........................................ 14 9.4 WorkgroupAuthorizations............................. 14 9.5 Log.......................................... 14 9.6 Workgroups..................................... 14 9.7 ER-kaavio...................................... 15 9.8 Hylätyt ratkaisut.................................. 15 10 Järjestelmän siirrettävyys eri alustoille 15 11 Käyttöliittymän suunnitteluperiaatteet 15 12 Tietoturva 16 12.1 Käyttäjien tunnistus ja todennus......................... 16 12.1.1 Järjestelmän oma tietokanta....................... 16 12.1.2 TML-laboratorin LDAP.......................... 16 12.1.3 ATK-keskuksen Sibboleth......................... 17 12.2 Oikeustasot..................................... 17 12.3 Tapahtumien kirjaus eli Audit Trail....................... 17 12.4 Sessionhallinta................................... 17 12.5 Syötteiden tarkistaminen............................. 17 12.6 Muita tietoturvahuomioita............................. 18 3

1 Johdanto Tämä dokumentti määrittelee Hirviö-järjestelmän tekniset ominaisuudet. Dokumentissa esitellään järjestelmän palvelinsovelluksen kokonaisarkkitehtuuri, 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. 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. 3.1 WWW-palvelin WWW-palvelimeksi käy mikä tahansa PHP:tä tukeva UNIX-pohjainen palvelin. 3.2 Tietokantapalvelin Tiedonhallintajärjestelmänä käytetään PostgreSQL-relaatiotietokantaa. Kyselyt siihen tehdään SQL-kyselykielellä. Tietokantapalvelin voi sijaita fyysisesti samassa laitteessa kuin WWWpalvelin. 3.3 Selaimet Selaimen tehtävänä on näyttää WWW-palvelimen palauttamat XHTML-dokumentit sekä pyytää käyttäjän valitsemia uusia dokumentteja. 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.4 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 Dokumentissa käsitellään vain Hirviö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. 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 skriptaamal- 5

Kuva 2: Järjestelmän modulit la 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-napin tai linkin. EventTrigger-oliolle 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. 6

5 Sovelluslogiikkamoduli Sovelluslogiikkamoduli on järjestelmän ydin ja sisältää varsinaiset toiminnot. Se toteuttaa MVC-mallin Controller-osan. Järjestelmän toiminnallisuus sijaitsee oikeustasoryhmien mukaisissa luokissa tässä modulissa. 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 WWW-selaimelle lähetettäväksi. Moduleista sovelluslogiikkamoduli tulee kehittymään ja laajentumaan voimakkaimmin projektin aikana. 5.1 Tärkeimmät luokat 5.1.1 HirvioApplication HirvioApplication on luokka, josta periytetään erilliset HirvioApplication-luokat eri oikeustasoryhmille. Näissä erillisissä luokissa sijaitsevat kullekin oikeustasoryhmälle kuuluvat toiminnot. 6 Käyttöliittymämoduli Käyttöliittymämodulilla luodaan järjestelmän käyttöliittymä. Moduli toteuttaa MVC-mallin View-osan. 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. 7

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 Toteuteutuksen arkkitehtuuri implementaatiokierroksella 1 Ensimmäisellä implementaatiokierroksella toteutetaan 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. Muistiin panon syöttäminen on käyttöoikeusryhmä opettajalle kuuluva toiminto. Kuva 3: Sisäänkirjautumisnäkymän rakenne Kuva 4: Opettajan muistiinpanonäkymän rakenne 7 Tietokantamoduli Tietokantamoduli yhdessä tietokannan kanssa toteuttaa MVC-mallin Model-osan. Modulin rakenne on esitelty kuvassa 5. 8

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. Implementaatiokierroksella 1 DataManager-luokalle toteutetaan toiminnallisuutta opiskelijoiden ja muistiinpanojen hallintaan. 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än on tarkoitus käyttää PostgreSQL:ää tiedonhallintajärjestelmänä, ja sille toteutetaan tässä vaiheessa yksi DatabaseConnection-luokka, PostgreSqlConnection. Luokka käyttää PearDB-pakettia siirrettävyyden parantamiseksi. PostgreSQLConnection toteuttaa DatabaseConnection-rajapintaa eikä lisää muita toiminnallisuuksia. DatabaseConnection määrittelee metodeita kantayhteyksien hallintaan ja tietokantakyselyiden tekemiseen. 9

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. 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. 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. 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äyttä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 kirjautumusprosessi tapahtuu seuraavasti: 10

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, 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 false. 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 Nämä luokat tekevät varsinaisen todennuksen. 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 TML-laboratorion LDAP-palvelimen avulla. SibbolethAuthenticationMethod Todentaa käyttäjän TKK:n ATK-keskuksen Sibbolethjärjestelmän avulla. 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. 11

8.5 Rajapinnat 8.5.1 Authenticator.authenticate() Authenticate() on julkinen metodi käyttäjien tunnistamiseen, todentamiseen ja oikeuksien hakemiseen. Metodi ottaa parametreinaan Hirviö-ID:n (kirjautumistunnus), kirjautumissalasanan, IP-osoitteen sekä sessioid:n. Todentamisen onnistuessa metodi palauttaa Userolion, joka pitää sisällään tiedon käyttäjän oikeuksista sekä asetuksista. Todentamisen epäonnistuessa palautetaan epäonnistumisen syystä riippumatta false. Epäonnistumisen syy jää kuitenkin Audit Trailiin. 8.5.2 AuthenticationMethod.authenticate() AuthenticationMethod-rajapinnan määrittelemä metodi, joka suorittaa todennuksen. Ottaa parametrina todennuksessa käytettävän tunnuksen sekä salasanan. 8.5.3 Logger.addLogin() Tekee Audit Trail -merkinnän onnistuneesta sisäänkirjautumisesta. Ottaa parametrina käyttäjää esittävän User-olion sekä aikaleiman. 8.5.4 Logger.addLogout() Tekee Audit Trail -merkinnän uloskirjautumisesta. Ottaa parametrina käyttäjää esittävän User-olion sekä aikaleiman. 8.5.5 Logger.addFailedLogin() Tekee Audit Trail -merkinnän epäonnistuneesta sisäänkirjautumisesta. Ottaa parametrina käyttäjätunnuksen, aikaleiman sekä epäonnistumisen syyn tekstinä. Tässä ei voida käyttää User-oliota, koska sitä ei voi luoda esimerkiksi tuntemattoman käyttäjätunnuksen tapauksessa. 8.5.6 Logger.addEvent() Kirjaa Audit Trailiin tapahtuman, jolle ei ole omaa metodia. Ottaa parametrina User-olion, aikaleiman, tapahtumaa kuvaavan tekstin sekä lisäinformaatiota tapahtumasta. 8.5.7 Logger.addEventWithId() Muutoin sama kuin addevent, mutta ottaa ensimmäisenä parametrina käyttäjätunnuksen tekstimuodossa User-olion sijaan. Tarkoitettu tilanteisiin joissa User-oliota ei ole käytettävissä. 8.6 Ensimmäisellä iteraatiokierroksella toteutettavat ominaisuudet Esimmäiseen iteraation AAA-modulista toteutetaan Audit Trail kokonaisuudessaan sekä sisäänkirjautuminen sisäistä tietokantaa käyttäen. 12

9 Tietokantarakenne Tietokanta koostuu yksilöjoukoista Users, Students, Notes, Workgroups ja Logs. 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. Lisäksi järjestelmä pitää lokia tapahtumista. 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ä. 9.2 Students 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. Sähköpostiosoite (email TEXT) Puhelinnumero (phonenumber TEXT) 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 13

9.3 Notes 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) 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 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.6 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 14

Kuva 7: ER-kaavio 9.7 ER-kaavio Kuvassa 7 esitetyssä kaaviossa kuvataan järjestelmän tietokanta. 9.8 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 PHP-kieltä ja sen kirjastoja. Järjestelmän voi tästä johtuen siirtää sellaisenaan käytettäväksi useimmille Unix-pohjaisille käyttöjärjestelmille. 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. 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 15

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, TML-laboratorin LDAP-tietokanta sekä TKK:n ATK-keskuksen Sibboleth-järjestelmä. AAA-moduli on suunniteltu siten, että menetelmiä on helppo lisätä. 12.1.1 Järjestelmän oma tietokanta Toteutukseltaan yksinkertaisin todennusmenetelmä on järjestelmän oman tietokannnan käyttäminen. Siinä tietokantaan muiden käyttäjätietojen yhteyteen tallennetaan 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ätunnus-salasana-pari hyväksytty. 12.1.2 TML-laboratorin LDAP TML-laboratoriolla on olemassa LDAP-palvelin ja PHP:ssä on valmiina tuki LDAP:lle. Vaikkei LDAP:a olekaan tarkoitettu tunnistuspalveluksi, sitä voi hyödyntää myös sellaisena. LDAPtodennuksen yksityiskohdat ovat vielä avoinna. 16

12.1.3 ATK-keskuksen Sibboleth TKK:n ATK-keskus on kehittämässä opiskelijoiden todentamiseen tarkoitettua Sibbolethnimistä järjestelmää, joka sopisi Hirviön käyttöön erittäin hyvin, koska se kattaa kaikki TKK:n opiskelijat eikä vaadi uutta salasanaa. Järjestelmä on kuitenkin vielä testausvaiheessa eikä sen käyttöönotosta tämän projektin puitteissa ole varmuutta. 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 ainakin 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ä (joko manuaalisesti tai session vanhennuttua) Käyttäjä lisäsi muistiinpanon järjestelmään Käyttäjä muutti järjestelmässä olevaa muistiinpanoa Käyttäjä muutti opiskelijan tietoja 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. 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 tekstikentässä on estetty, mikäli lainausmerkkien tarkistus toimii. 17

HTML-tagit HTML-tagien pääsy syötteisiin ei aiheuta niin suurta tietoturvariskiä, kuin vihamieliset SQL-komennot, koska periaatteessa kantaan tallennettavaa dataa voivat syöttää vain opettajat ja sisältöylläpitäjät. Luonnollisesti tagit kuitenkin 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) 18