4. Roolimallipalvelu 4.1 Tiedot palvelusta Palvelun nimi: Palvelun versio 01.01.00 Toteuttaa palvelun yksilöllistä palvelua (kts. M14.4.42) Roolimallipalvelu (Model role service) MYJ:lle, jotka toteuttavat MoReq2010 mukaista roolimallia käytetään: 2f6d05c6-51e6-4a32-a7fc-c0a6883eb85b MYJ:lle, jotka toteuttavat omaa (natiivia) roolimalliaan käytetään: d945dcd9-dc2d-491d-965a-11ce936d044b 4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa 4.2.1 Standardien ja ns. teollisuusstandardien puuttuminen roolien ja käyttöoikeuksien hallinnassa Tämä MoReq2010 :n moduuli sisältää mallin käyttäjien roolien hallinnasta niin, että se yhdessä toiminnallisten määrittelyjen kanssa kattaa käyttäjien oikeuksien hallinnan MYJ:ää käytettäessä. MoReq2010 :n julkistamisen aikaan ei ole olemassa teollisuudessa laajalti käytettyä standardia, jota voitaisiin pitää mallina, kun tietojärjestelmien entiteettejä annetaan käyttöön. Perustoiminnan sisältävät mallit, joissa määritellään oikeudet luoda, lukea, päivittää ja poistaa (CRUD) ovat liian yksinkertaisia asiakirjajärjestelmille. Esimerkiksi CRUD ei erottele poistamista (delete) ja hävittämistä (destruction) eikä anna lupaa asiakirjajärjestelmissä tärkeiden asiaan liittyvien entiteettien käyttöön. Koska teollisuusstandardia ei ole, järjestelmätoimittajat ovat kehittäneet omia lähestymistapojaan käyttöoikeuksien hallintaan asiakirjajärjestelmissä. Nämä usein tehokkaatkin toimittajakohtaiset menetelmät ovat lähes aina sovelluskohtaisia eikä niitä voi useinkaan käyttää tietojärjestelmien yhteisenä käyttäjähallintajärjestelmänä. 4.2.2. Roolipohjainen käyttäjähallintapalvelun malli MoReq2010 :n roolipohjainen käyttäjähallintapalvelun malli on yksinkertainen standardoitu malli, joka täyttää tämän määrittelyn mukaisessa kontekstissa käytettävien järjestelmien tarpeet. Malli on sekä neutraali että nykyaikaisissa tietojärjestelmissä käytettäviin yleisiin konsepteihin, kuten saavutettavuusluetteloihin ja roolimäärityksiin perustuva. MoReq2010 roolien hallintamalli voi kuitenkin esittää vain yhden mahdollisen pääsynhallintaan. Tämä malli voikin merkittävästi poiketa aiemmin kehitetyistä asiakirjajärjestelmistä, joita ei voida saada MoReq2010 -yhteensopiviksi ilman merkittävää uudelleenkehittämistä sisäisiin pääsynhallintaratkaisuihin verrattuna. Tämä johtaa ristiriitaan: sillä aikaa kun uudet asiakirjajärjestelmät voidaan rakentaa käyttämään roolimallia, sitä ei välttämättä voida toteuttaa kustannustehokkaasti markkinoilla olevissa järjestelmissä. 4.2.3 Lähestymistapoja roolipohjaisen mallin testaukseen hyväksyntään Aiemmin selitetyistä syistä johtuen DLM Forum Säätiö sallii kaksi mahdollista lähestymistapaa MoReq2010 yhdenmukaisuuden testaukseen ja hyväksyntään.
Joko A: Asiakirjajärjestelmä toteutetaan kokonaisuudessaan MoReq2010 :n roolipohjaisen mallin mukaisesti ja se testataan ja hyväksytään tämän mallin vaatimusten mukaisesti. Tai B: Asiakirjajärjestelmä toteuttaa oman käytönhallintamallinsa, jolloin seuraavat vaatimukset on täytettävä: on osoitettava, että järjestelmän oma käytönhallintamalli on toiminnaltaan ja joustavuudeltaan vastaava kuin MoReq2010 malli roolipalvelusta. Järjestelmän on tuettava yhteen toimivuutta kykenemällä konvertoimaan aineistonsiirrossa alkuperäiset käytönhallintatiedot MoReq2010 roolien hallintamalliin. Tällöin käyttäjien ja ryhmien on säilytettävä vastaavat käyttöoikeustasot entiteetteihin ja käytettävä samaa auktoriteettia kun data on siirretty toiseen MYJ:ään. 4.2.4 Kuinka täytetään vaihtoehto B:n mukaiset vaatimukset? Voidakseen osoittaa, että MYJ:n oma käyttäjähallinta vastaa joustavuudessa ja toiminnallisuudessa MoReq2010 roolien hallintamallia, asiakirjajärjestelmän on täytyy osoittaa kaikki seuraavat ominaisuudet: Käyttäjä ei voi päästä käyttämään mitään entiteettiä MYJ:ssä ennenkuin hänelle on annettu lupa saada aineisto käyttöönsä joko yksilönä tai ryhmän jäsenenä. On olemassa useita käyttäjien määriteltäviä pääsytasoja aineistoihin mukaan lukien läpinäkymätön mahdollisuus antaa käyttäjille käyttöoikeuksia niin että he voivat: löytää joitakin entiteettejä, mutta ei toisia toteuttaa joitakin toimintoja, mutta ei toisia. Oikeus päästä käyttämään aineistoa voidaan asettaa yksittäisen entiteetin tasolle erikseen tai kerralla koko arkistolle, sarjalle tai yhdelle asiakirjaryhmälle. Oikeus päästä käyttämään aineistoa ja toteuttaa toimintoja voidaan asettaa erilaiseksi eri osissa MYJ:ää. Esimerkiksi on oltava mahdollista asettaa käyttäjän oikeus toteuttaa toimintoja tietyissä luokissa toiseksi kuin saman käyttäjän oikeudet toisissa luokissa samassa luokitusjärjestelmässä. Kun uusi entiteetti muodostetaan, sille syntyy riittävät oletuskäyttöoikeudet.esimerkiksi kun uusi asiakirja liitetään olemassa olevaan asiakirjaryhmään, se saa samat oikeudet kuin muutkin asiakirjat ko. ryhmässä. On olemassa roolityyppejä tai pääsyoikeuksia, joita tiettyjen entiteettien omistajat eivät voi estää, että niiden roolien tai oikeuksien käyttäjät voivat hallinnoida koko tai osaa MYJ:stä. Kun konvertoidaan metadataa järjestelmän oman pääsynhallinnan siirtoa varten MoReq2010 roolimallipalvelun metadataformaattiin seuraavat asiat on otettava huomioon: Yksikään käyttäjä ei voi saada enemmän käyttöoikeuksia kuin tällä oli oikeuksia alkuperäisessä ympäristössä. Yhdellekään käyttäjälle ei saa antaa oikeuksia toteuttaa toimintoja muualla kuin niissä entiteeteissä, joissa hänellä oli vastaava oikeus alkuperäisessä ympäristössä. Ryhmän käyttöoikeuksia ei saa muuttaa sen yksilöiden käyttöoikeuksiksi.
Asiakirjajärjestelmän täytyy käyttää periytymistoimintoa kun se on mahdollista ja välttää, että aineistoa siirrettäessä jokaisesta perijä-entiteetistä lisätään erillinen, toistuva joukko pääsynhallinnan pääsylistalle, jos käyttöoikeudet voidaan hallita ylemmän tason yhdellä pääsynhallintamäärityksellä. Järjestelmätoimittajan täytyy kuvailla asiakirjajärjestelmän konversio-algoritmi ja tarjota informaatiota ja esimerkkejä kuinka siirretty data rooleista ja pääsynhallintalistoista on toteutettu, jotta rooleihin perustuva malli voidaan toteuttaa niin tarkasti kuin mahdollista. Järjestelmätoimittajan on luovutettava käyttäjähallinnan kuvaus (mapping schema) käyttöön sen liittämiseksi tuotteen testiraporttiin. Lisää opastusta ja ohjausta järjestelmätoimittajille on saatavissa DLM Forumista Tämän moduulin loppuosa kuvailee MoReq2010 roolimallipalvelun konseptin ja vaatimukset. 4.3 Keskeiset konseptit 4.3.1 Roolien määrittely MYJ:n täytyy ennen muita toimintoja ensiksi alustavasti tarkistaa onko käyttäjällä oikeus toteuttaa haluamansa toiminto. Toimintojen käyttöoikeus annetaan käyttäjille, kun heidät määritellään rooleihin. Käyttöoikeudet täyttävästä käyttäjästä (kts. R3.4.1), jolla on oikeus tehdä toimintoja käytetään koko tässä määrittelyssä termiä käyttöoikeuksien haltija. Siitä syystä, että sama rooli voidaan antaa kaikille MYJ:n entiteeteille tai sitä käytetään useissa asiakirjajärjestelmissä, kaikki roolien määrittelyt hallitaan roolipalvelulla. Roolin määrittely edustaa toimintojen määrittelystä koostuvaa ryhmää, kuten kaaviossa 4a on esitetty. Roolien ja toimintojen määrittely sisältää monesta-moneen (many-to-many) suhteen: mihin tahansa rooliin voi kuulua useita siihen kuuluvia toimintoja ja samaa toimintoa voidaan toteuttaa useammassa kuin yhdessä roolissa. Termi rooli kertoo, että siihen kuuluva toimintojen ryhmä on valittu loogisesti kuvaamaan kollektiivisesti määriteltyä tietyt tehtävät hallitsevaa henkilökunnan jäsentä, esimerkiksi paikallinen asiakirjavastaava. Roolien määritteleminen perustuen toimintojen kokonaisuuksiin on keskeistä asiakirjajärjestelmien hallinnassa. Moreq 2010 määrittelyssä on lukuisa joukko toimintoja ja niiden liittäminen käyttäjien ja ryhmien tasolla olisi epäkäytännöllistä.
Kaavio 4a Toiminnot liitetään rooleihin (kaikkiin toimintoihin täytyy liittyä vähintään yksi rooli) 4.3.2 Roolien luovuttaminen Rooli voidaan luovuttaa joko käyttäjälle tai ryhmälle mihin tahansa asiakirjajärjestelmän entiteettiin palvelut mukaan lukien. Kun rooli otetaan käyttöön, luodaan kullekin käyttäjälle tai ryhmälle pääsynhallinnan sääntöön luettelo luvallisista rooleista entiteetin pääsynhallintaluetteloon (ACS). Käyttäjälle luovutettu entiteettiin liittyvä rooli antaa oikeuden kaikkiin luettelossa määriteltyihin rooliin liitettyihin toimintoihin. Roolin luovuttaminen ryhmälle merkitsee pääsyoikeuden luovuttamista ryhmän jokaiselle jäsenelle (kts. 3. Käyttäjien ja ryhmien palvelu). Ryhmään liittyvät uudet jäsenet perivät automaattisesti roolin, kun taas ryhmän jättävät automaattisesti menettävät automaattisesti pääsyn tähän rooliin ilman että sitä tarvitsee määritellä henkilökohtaisesti. Roolien luovuttaminen ryhmille on suositeltava hyvä käytäntö koska se tekee käyttäjien pääsynhallinnan entiteetteihin helpoksi hallita kun he liittyvät tai poistuvat organisaatiosta, vaihtavat töitä. Tällöin ei tarvitse päivittää entiteettien pääsynhallintalistoja asiakirjajärjestelmässä. Ryhmien hallinta on kiistatta yksinkertaisempaa ja vähemmän virhealtis verrattuna jatkuvaan yksittäisten käyttäjien roolien hallinta. Kaavio 4b osoittaa kuinka yhdelle käyttäjälle ja tai ryhmälle luovutetaan yksi tai useampi rooli entiteettiin lisäämällä yksi pääsynhallintatieto entiteetin luetteloon. Jokaisella entiteetillä samoin palveluilla on pääsynhallintaluettelo.
Kaavio 4b Pääsynhallintaluettelo, joka koostuu syötetyistä tiedoista, jotka kytkevät käyttäjän tai ryhmän rooliin. 4.3.3 Roolien periminen Entiteetillä voi olla omien pääsynhallintaluettelon määritysten lisäksi perittyjä ryhmien ja käyttäjien rooleja, jotka on luovutettu muille entiteeteille. Moreq 2010 ilmoittaa erillisissä toiminnallisissa määrityksissä milloin tällainen roolien periminen voi tapahtua. Yleisenä sääntönä koko määrityksessä jos vanhempi/lapsi suhde entiteetien välillä on olemassa, lapsi perii vanhemman pääsynhallintaluettelon. Esimerkiksi lapsen asemassa oleva kertymä perii roolit vanhempikertymältä samoin tekee asiakirja. Tietyissä olosuhteissa entiteetit voivat periä rooleja useista lähteistä, kuten on kuvattu kohdassa 4.3.5 Monilähtöinen periytyminen. Periytyminen on erittäin tärkeä toimintamalli suurissa asiakirjajärjestelmissä, missä roolien määrittely yksittäisiä entiteettejä kohtaan on epäkäytännöllistä. Yleinen toimintamalli periytymisestä voidaan myös rikkoa joitakin rooleja varten, jos tällaista tarvitaan. Moreq 2010 asettaa ehdon, jonka mukaan jokaisessa pääsynhallintaluettelossa voidaan estää Periytä tai sallia periytyvätkö vanhempi-enteettien roolit lapsi-entiteeteille. Jos ehdon status on käännetty pois pääsynhallintaluettelossa, vain järjestelmän hallintaroolit perivät automaattisesti roolit vanhempi-entiteetiltä. 4.3.4 Hallintaroolit Moreq 2010:ssa on kahdenlaisia hallintarooleja järjestelmän hallinnoijan (administrator) roolit ei-järjestelmän hallinnoijan roolit
Roolin tyyppi on määritelty osana roolin määritystä. Järjestelmän hallinnoijan rooli, joka on luovutettu koko palvelukokonaisuudelle tai yhdelle vanhempi-entiteetille pätee kaikkiin entiteetteihin, jotka perivät tältä entiteetiltä tai palvelulta. Näin ollen järjestelmän hallinnoijan rooli ylittää ehdon periyttämisen kiellosta lapsi-entiteeteille. Kaavio 4c Hallinnoijan roolit ylittävät roolien periyttämisen ehdollisen merkinnän. 4.3.5 Monilähtöinen periytyminen Kuten aiemmin on mainittu, kuuluu Moreq 2010 määrittelyyn osia, joissa entiteetti voi periä rooleja useammalta entiteetiltä. Esimerkiksi asiakirjapalvelussa ylläpidettävät kertymät ja asiakirjat perivät pääsynhallinta-asetukset sekä vanhempi-kertymältä että luokitukselta. tämä on esitetty Kaaviossa 4d. Missä näin tapahtuu, entiteetti perii roolinsa sekä kertymältä että luokitukselta. Kuitenkin, jos peri kaikki -lippu on pois käytöstä, lapsi-entiteetti perii vain entiteettien hallinnolliset roolit.
Kaavio 4d Pääsynhallintaluettelot voidaan joskus periä useammasta kuin yhdestä lähteestä. Tämä järjestely sallii erilaisten organisaatioiden määritellä pääsy asiakirjoihin sekä luokituksen että kertymän tasolla. 4.3.6 Oletusroolit Asiakirjajärjestelmissä on yleinen käytäntö, että ne asennetaan oletusarvoilla, joissa järjestelmätoimittajat ovat ennakkoon määritelleet järjestelmäasennuksessa tällaisen roolijoukon. Näin käyttäjät voivat ruveta käyttämään järjestelmää välittömästi. Tässä tapauksessa tällaisia oletusrooleja on voitava muuttaa ja tarvittaessa poistaa (jos niitä ei ole käytetty); luvan tähän saaneet käyttäjät voivat myös hävittää ne. Järjestelmätoimittaja voi määritellä toiset ennalta määritellyt roolit vain toimittajan muutettaviksi pysyviksi ja tietyssä asiakirjasovelluksessa käytettäviksi muuttamattomina rooleiksi. MoReq2010 antaa toimittajille mahdollisuuden tarjota yksi tai useampi oletusrooli tuotteissaan sillä ehdolla, että ne on dokumentoitu osana testiraporttia. Edellytetään, että Moreq-yhteensopiva asiakirjajärjestelmällä voidaan luoda, muokata ja tuhota asiakaskohtaisia roolimäärityksiä perustuen käyttäjäorganisaation asiakirjahallintapolitiikkaan.
Huomaa, että vaikka jotkin järjestelmätoimittajan määrittämät kiinteät roolit ovat kiinteitä tässä järjestelmässä, sellaiset roolit eivät välttämättä säily kiinteinä kun aineisto siirretään asiakirjajärjestelmästä toiseen.