Virtu-luottamusverkostohanke Määrityksistä 31.8.2008 mennessä saadut kommentit 1.10.2008/mikael.linden@csc.fi Kommentti Panorama Partners käyttöoikeuksien hallinnan osalta määrittelyvaiheen tulokset nähtiin puutteellisina. Toivottavaa on, että VIRTU-luottamusverkostohanke keskittyy tulevissa versioissaan myös käyttöoikeuksien hallinnan problematiikkaan, mikä yleisesti ottaen on haastavampaa kuin pelkkä tunnistaminen Lisäksi koettiin, että VIRTU-luottamusverkostohankkeen tulisi jatkossa antaa suosituksia virastoille miten virkamiehen tunnistamiseen ja käyttöoikeuksien hallintaan liittyviä haasteita tulisi lähestyä. Nykyisellään VIRTU mahdollistaa turhan heterogeenisen toimintaympäristön, josta voi aiheutua hankaluuksia tulevien VIRTUversioiden myötä. Ohje Virtu-yhteensopivan palvelun kehittäjälle koettiin enemmänkin palveluarkkitehtuurin analyysidokumentiksi eikä varsinaisesti suunnitteluohjeeksi. Syynä tähän oli lähinnä se, että dokumentti esitti vaihtoehtoja VIRTU-yhteensopivuudelle, mutta ei varsinaisesti suositellut tai ottanut kantaa vaihtoehtojen paremmuuteen. Ohje voisi ottaa kantaa mm. eri käyttöoikeuksien hallintamalleihin ja mitä vaikutuksia niillä on palvelun toteutukseen. Suureksi haasteeksi koettiin virkamiesten työsuhteen elinkaaren muutoksen hallinta käytettävissä palveluissa. Palvelu pystyy havaitsemaan uuden virkamiehen ensimmäisellä kirjautumiskerralla, mutta esim. nimen muutos tai virastosta poistuminen ovat haasteellisempia. Virtu-hankkeen huomio kommenteista On totta, että määrittelyvaihe ei syventynyt erityisesti käyttöoikeuksien hallintaan ja että oikeuksienhallinta on yleisesti ottaen henkilöllisyyden todentamista monisyisempää. Virtuluottamusverkostossa koitetaan aluksi lähteä liikkeelle autentikoinnista, johon myös vireille pannuissa Virtu-piloteissa on osoitettu ensisijaista mielenkiintoa. Myöhemmin huomion kohdetta laajennetaan valtuuksien hallintaan, minkä uskomme olevan mahdollista taaksepäin yhteensopivasti. Vaihtoehdot valtuuksien hallinnan periaatteista esitettiin jo Virtu-esitutkimusraportissa. Virtu-hanke on tukenut virastojen sisäistä identiteetinhallintaa ValtITkäyttäjähallintokoulussa. Tarpeita jatkotuelle tarkkaillaan. Myös VAHTI 9/2006 tarjoaa suosituksia virastoille. Kaikkeentepsivien ohjeiden laatiminen on kuitenkin vaikeaa, koska julkishallinnon organisaatiot ovat kooltaan ja luonteeltaan erilaisia. Palvelun kehittäjän ohje oli luonteeltaan lähinnä taustoittava ja näkökulmia avaava. Ehkä dokumentin nimi oli harhaanjohtava, ja se on syytä nimetä uudelleen palveluarkkitehtuurin analyysiksi. Nimen ja muiden attribuuttien muutos välittyy palveluun seuraavalla kirjautumiskerralla annettavassa sunnistusselosteessa. Haastavampi tilanne syntyy, kun virkamies poistuu kotivirastonsa palveluksesta ja hänen identiteettinsä pitäisi sulkea (de-provisioida) palvelussa. Nykyinen Virtu-arkkitehtuuri antaa vähäiset eväät federoituun de-provisiointiin, ja myös provisiointi edellyttää virkamiehen ensimmäistä kirjautumista palveluun.
Käyttöoikeuksien hallinnassa suurimpana haasteena nähtiin palvelun määrittelemän käyttöoikeusmallin julkaiseminen kuluttavien virastojen identiteetinhallinnan piiriin. Oletuksena on, että virastot tietävät parhaiten omien virkamiestensä työroolit (joita siis voi olla virkamiehellä yksi tai useampi) ja nämä tulisi linkittää palveluiden määrittelemiin käyttöoikeuskohteisiin (esim. käyttäjärooli). Perusperiaatteena tunnistusselosteissa tulisi olla, että se sisältää vain virkamiehen käyttöoikeudet kyseiseen palveluun, eikä esim. hänen kaikki käyttöoikeudet. Tunnistuslähteen päättelyyn liittyvä määrittely koettiin keskeneräiseksi. Syynä tähän on myös SAML 2.0-standardin jälkeiset ehdotukset tunnistuslähteen päättelypalvelulle. Tunnistuslähteen pakollisuus yhteisen domainin evästeen käytölle koettiin turhaksi, varsinkin kun alkuvaiheessa Shibbolethin WAYF-tyyppinen päättely on teknisesti yksinkertaisempi toteuttaa ja riittää VIRTUluottamusverkoston volyymiin. Lisäksi palveluntarjoajalle yhteisen domainin evästeen tukeminen on vaihtoehtoista. Jos kumminkin yhteisen domainin evästeen toteuttamiseen päädytään, koettiin operaattori luonnollisena osapuolena hallinnoimaan kyseistä domainia. Toimintakäytännöissä lueteltiin tunnistuslähteen päättelypalvelun tarjoamisen vastuun operaattorille, mikä koettiin hyväksi ratkaisuksi. Tällöin periaatteessa kaikki palveluntarjoajat voivat kääntyä keskitettyyn palveluun, jonka käyttöä VIRTUluottamusverkostohankkeessa suositellaan palveluntarjoajille. VIRTU-luottamusverkostossa virkamiehen tietoturvataso on istuntokohtainen, esim. riippuen siitä millä tavalla hänet on tunnistettu. Virkamieskortilla saa korkeamman tietoturvatason kuin esim. salasanalla. Miten tunnistuslähteet ja palvelut käsittelevät ajonaikaisesti virkamiesten tietoturvatasoja, kun virkamies yrittää käyttää palvelua? Miten tietoturvatasojen määrittäminen käytännössä tapahtuu? Miten palvelu tietää sisäänkirjautuvan virkamiehen tietoturvatason? Jatkokehityshankkeena voidaan selvittää, voiko SAML:n sijaan muita tekniikoita (esim. SPML) käyttää provisiointiin ja deprovisiointiin. Esitetyn käyttöoikeusmallin toimivuudesta kerätään kokemuksia Virtupiloteissa ja niiden jälkeen, ja mallia kehitetään kokemusten perusteella. Alkuvaiheessa Virtu-luottamusverkoston painopiste lienee kuitenkin henkilöllisyyden todentamisessa. Kyllä. Kokemuksia eri tuotteiden tuesta käyttöoikeuksien ja muiden attribuuttien kohdennettuun luovuttamiseen kerätään piloteissa.. SAML2.0-määritykseen sisältyvä, evästeisiin perustuva tunnistuslähteen päättelypalvelu on kömpelö moniorganisaatioympäristössä. Tunnistuslähteen päättelypalvelusta toivotaan saatavan lisää kokemusta Virtu-piloteissa. Kyllä, joskin palveluntarjoajia ei estetä tekemästä tunnistuslähteen päättelyä myös omatoimisesti. Suojattavan kohteen (oli kyseessä sitten palvelu tai tunnistuslähde) (staattinen) turvataso määritetään Tietoturvatasot-kärkihankkeessa tehtävän kehikon mukaisesti. Lähtökohta on, että kunkin tunnistuslähteen ja palvelun turvataso on luottamusverkoston operaattorin tiedossa, ja operaattori voi ilmaista tunnistuslähdeiden ja palveluiden turvatason esimerkiksi tarjoamalla luottamusverkostossa useita SAML2-metadatatiedostoja: tason 2 palvelulle tarkoitetussa metadatatiedostossa on mukana kaikki tason 2-4 tunnistuslähteet, tason
3 palvelulle tarkoitetussa metadatassa on tason 3-4 tunnistuslähteet ja tason 4 palveluille tarkoitetussa metadatassa vain tason 4 tunnistuslähteet. Lisäksi koettiin, että esim. siirtyminen tietoturvatasolta 2 tasolle 3, vaatii eri osa-alueilla hyvin eritasoisia vaatimuksia, jotka voivat aiheuttaa epäsopua. Jos esim. virasto haluaisi käyttää virkamieskorttitunnistusta tason 3 palveluiden kanssa, joutuu virasto käytännössä myös toteuttamaan jäljitettävyyteen liittyvät vaatimukset. Virtu SAML 2.0 profiili: Onko tässä dokumentissa tarkoitus jossain vaiheessa kuvata yhteensopivuudet SAML Authority vaatimusten kanssa? Vai jätetäänkö esim. attribuuttikyselyt VIRTUluottamusverkostohankkeen ulkopuolelle (vrt. KARVA). Virtu-skeema ja attribuuttien muodostamisohje: virtuemployeetype attribuutin kuvaus puuttuu kohdan 4.9.3 otsikko on virheellinen Viittaus RFC5126 pitäisi olla RFC4515 (LDAP 3 schema määrittely) virtupersonentitlement attribuutin URL-muotoisuus koettiin erikoiseksi. Jos tarkoitus on välittää esim. palvelukohtaisia käyttäjärooleja, niin miten ne paketoidaan URL-muotoon? Ohje Virtu-yhteensopivan palvelun kehittäjälle: Kohdan 3.3 kuva ja taulukot ovat moniselitteisiä tekstiin nähden. Tässä olisi myös hyvä huomioida, että palvelu voi linkittää joko työroolit (title) ja palvelukohtaiset käyttäjäroolit (virtupersonentitlement) palvelun ns. sovellusrooleihin, jotka ovat tyypillisesti hienojakoisempia. TietoEnator Virastojen työtä liittymisen näkökulmasta ajatellen helpottaisi, jos Henkilöllisyyden todentamisen turvataso ilmaistaan tunnistusselosteessa, joko SAML authentication context-attribuutin avulla tai tavallisella SAML-attribuuttiassertiolla. Toteutuksen yksityiskohta on kiinnittämättä, toivomme pilottien tuovan valaistusta tähän. Nykyisessä määrityksen versiossa palvelun tietoturvatasoa ja sen edellyttämää autentikoinnin tukevuutta ei ole kytketty toisiinsa. Tasolla 2 oleva palvelu voi vaatia vahvaa autentikointia, tai tasolla 4 oleva palvelu voi kelpuuttaa salasana-autentikoinnin. Tunnistuslähde voi kuitenkin suorittaa autentikoinnin tukevammalla tasolla kuin mitä palvelu on pyytänyt. Toistaiseksi tämä kysymys on jätetty vastaisten hankkeiden harteille. URL häntä voi sisältää parametreja, esim http://valtiokonttori.fi/rondo/tty/1234/hyvaksyja?projekti=2345 URL:n etu on, että sen nimiavaruuksiin on vakiintuneet hallintakäytännöt (Internetin Domain-nimijärjestelmä). Alkuvaiheessa Virtu-luottamusverkoston painopiste on federoitu
alkuvaiheessa keskityttäisiin vain federoidun tunnistamisen ja käyttäjähallinnon tulo/poistuminen/muutostilanteiden kuntoon laittamiseen. VirtuEmployeeType avaaminen on jäänyt puuttuumaan attributtien määrittelystä. O ja OU suhde toisiinsa kaipaisi esimerkkiä. Asennuspäiväkirjat olisivat pakollisia osallistuville organisaatioille. Niistä oppii parhaiten. Esim. varmasti moni organisaatio saattaa jäädä miettimään pitkäksi aikaa, että miten tuonkin tiedon tuolta järjestelmästä saa helposti keskitettyyn LDAP-hakemistoon. Eli proto-sovellukset ja malliratkaisut tukisivat ettei pyörää tarvitse keksiä uudestaan. Valmiit lomakepohjat MUST ja RECOMMENDED; MAY ja OPTIONAL tietojen alkuperän ja keräämisen selvittämistä varten. Valmiit pohjat, jolla organisaatio voisi heti valita HELPPON, KATTAVAN vai TÄYDELLISEN lähestymisen. Tarvitaisiinko virtuhomeorganizationtype lisäksi virtuorganizationtype valmiiksi määriteltynä. LDAPia varten voisi olla hyvä määritellä virtuorganizationtype, joka voisi olla liitettynä suoraan organisaatio olioon. (lähinnä implementointi näkökulma) Preferred Language olisi hyvä olla mukana. Viranomaiskäyttöisiä järjestelmä (palvelut) tehdään käytännössä kaksi kieliseksi, tämän tiedon välittäminen automaattisesti olisi hyvä. Tarve keskitetylle tunnistuslähteelle olisi välitön, että SAML 2.0 tekniikkaa voitaisiin sitoutua palveluja suunnittelevissa organisaatioissa. Katsottaessa ongelmaa palvelusta päin: palvelu, joka on yleensä suunnattu pienen käyttäjämäärän ja/tai kapean sektorin esim. kuntakäyttäjille, ei yksinkertaisesti pystytä ratkaisemaan SAML 2.0 tekniikkalla käyttäjäorganisaatioden pakottamisen puutteen takia. Ihan reaalisesti kyseenalaistetaan, että voidaanko pakottaa organisaatio esim. 3 käyttäjän takia hankkimaan oma IdP:nsä. Lisäksi aita näyttää olevan vielä siinä kohtaa matalin, että on helpompi ratkaista ne pari sataa käyttäjää tarjoamalla joko itsepalveluna toimivaa ylläpitokäyttöliittymää tai hoitaa se itse. tunnistaminen, sekä virastojen sisäisen käyttäjähallinnon kohtaminen. Asennuspäiväkirjojen julkaisemista varten voidaan ajatella esimerkiksi wiki-sivustoa, jota luottamusverkoston operaattori hallinnoi. Mutta olisivatko yksityissektorin toimijat halukkaita jakamaan asennuspäiväkirjoja kilpailijoidensa kanssa? osana luottamusverkoston operaattorin tarjoamaa tukimateriaalia Virtu-luottamusverkostossa ei oteta kantaa organisaation sisäisiin toteutusvälineisiin, kuten LDAP-hakemistoon Tarve keskitetylle tunnistuslähteelle on tiedostettu ja mukana Virtuesitutkimusraportissa. Sitä ei kuitenkaan toteuteta Virtuluottamusverkostohankkeessa, se jää Valtion IT-palvelukeskuksen vastaisen palvelukehityksen varaan.
Ubisecure Oy Virtu-spesifikaatiossa mainitut käyttötapaukset (1. Informaatioportaalit, 2. Kyselyjärjestelmä, 3. Asiankäsittelyjärjestelmä) voitaisiin toteuttaa myös SAML Technical Overview-dokumentin esittämien käyttöskenaarioiden mukaan. Esimerkiksi: apauksessa informaatioportaalit voitaisiin noudattaa skenaariota "Federation Using Transient Pseudonym Identifiers". Tapauksessa asiankäsittelyjärjestelmät, noudatettaisiin joko skenaariota "Federation Using Persistent Pseudonym Identifiers" tai "Federation Using Out-of-Band Account Linking", siten että käyttäjän persistent NameID ja NameQualifier toimivat käyttäjien linkittävänä datana. Virtu-profiilissa on valittu käyttäjän identiteetin ja sen namespacen välittämiseen varsin omintakeinen tapa, jossa asetetaan pakolliseksi rakenteellinen attribuutti, jossa nimen namespace tulee parseroida attribuutin arvosta (erotettu %-merkillä). Perusteluna rakenteellisen attribuutin käytölle nimien sijasta on määrittelyissä mainittu mm. se että NameIDManagement protokollan käyttöä ei näin vaadittaisi. Kuitenkin, mikään edellä mainituista SAML Technical Overviewin käyttötapauksista ei itse asiassa myöskään vaadi NameIDManagementprotokollan tukemista. Myöskään Libertyn IdP Lite ja SP Lite leimoihin ei vaadita tämän protokollan tukemista. Eräs Virtu-määrittelyn tavoitteista on ollut helppo käyttöönotto kaupallisilla tuotteilla. Tätä käyttöönottoa myös helpottaisi jos käyttötapaukset noudattaisivat näitä edellä mainittuja SAML suosituksia. Virtussa ehdotettu rakenteelliseen attribuuttiin perustuva käyttäjien mäppäys ja käsittely ei varmastikaan ole tuettuna suoraan missään kaupallisissa tuotteissa. Jääkö tässä SP:n vastuulle tuon %-merkin jälkeisen osan validointi? Toisin sanoen jääkö tässä SP:n vastuulle validoida, että ko. DNS nimiavaruuden haltija on se IDP jolta nimi saatiin? Tällainen validointi ei kuulu minkään SAML-tuotteen ominaisuuksiin. Käyttötapaukset ovat luonteeltaan enemmän palveluarkkitehtuuria analysoivia, eivätkä sinällään ohjaa käyttämään mitään tiettyä SAMLmäärityksen nimitunnistetta (NameID). Virtu-määrityksissä virkamiehen yksilöiväksi tunnisteeksi on ehdotettu virtupersonprincipalnamea, jonka syntaksi on muotoa tunniste%domain. Domain puolestaan on mäpätty tunnistuslähteisiin luottamusverkoston SAML2.0-metadatassa (SAML2-profiilin kohta 4.2.1), joka määrittää, mitä virtupersonprincipalname-loppuosia kukin tunnistuslähde saa käyttää. Tämä palo-osastointi on oleellista Virtuluottamusverkoston turvallisuusmallissa, koska Virtuluottamusverkoston arkkitehtuuri on hajautettu. Kuvitteellinen esimerkki: Valtioneuvoston tietohallintoyksikön tunnistuslähde antaa tunnistusselosteita, joissa virtupersonprincipalname-loppuosa on %vnk.fi ja Rötvälän kunta %rotvala.fi. Ilman palo-osastointia Rötvälän kunnan murrettu tai pahansuopa tunnistuslähde voisi antaa tunnistusselosteen vanhanen%vnk.fi, jolloin hakkeri voisi onnistua esiintymään esimerkiksi pääministeri Vanhasena. Tällöin koko luottamusverkosto olisi yhtä heikko kuin sen heikoin lenkki. Palo-osastoinnin ansiosta Rötvälän kunnan tunnistuslähteen murtanut hakkeri voi kuitenkin impersonoida vain Rötvälän kunnan virkamiehen, ja syttynyt tulipalo saadaan rajattua Rötvälään. Näin yksi huonosti käyttäytyvä tunnistuslähde ei vaaranna muita kotiorganisaatioita. SAML Service Provider palvelimen tehtäväksi jää tarkistaa, että
Ei ole pois suljettu että jotkut tuotetalot, kuten Ubisecure, toteuttaisivat tällaiset Virtu-spesifiset suomalaispiirteet, mutta varmaa on että se karsii mahdollisia vaihtoehtoja. Lisäksi kaikki erityispiirteet merkitsevät käytännössä Valtiohallinnolle kalliimpia ratkaisuja hankinta- ja ylläpitomielessä kokonaisuutena. Tuotetaloille se vastaavasti merkitsee raskaampia prosesseja. Omasta kokemuksestamme juuri päättyvästä kansainvälisestä Liberty/SAML interop-hankkeesta johon olemme osallistuneet ja yleisenä huomiona voisi painottaa sitä melkein itsestään selvää seikkaa, että tukeutuminen alan yleisiin käytäntöihin helpottaa suunnattomasti järjestelmien yhteenliittämistä. Kansainvälisen Liberty/SAML interop-hankkeen laajuus myös kertoo jotakin mittakaavasta: esim. itse testaushanke vaatii yli kolme kuukautta kalenteriaikaa usealta henkilöltä. Lisäksi kukin osapuoli myös sitoutuu sopimuksilla tuohon panostukseen jotta yhteen toimivuus kaikkien kesken ylipäätään on mahdollista todentaa. Jos ei Suomessa haluta luoda omaa Virtu-standardointi- ja yhteensopivuusprosessia, niin olisi ehkä kuitenkin kaikille osapuolille parempi jos noudatettaisiin kansainvälisiä alan käytäntöjä ja yhteensopivuuden jo takaavia malleja. Interopissa myös kaikkien IDP Lite/SP Lite toimijoiden on tuettava persistent-id muotoisia nimiä. Sen sijaan esim. SAML attribuutteja ja niiden käsiteltävyyttä ei IDP Lite/SP Lite interopissa testata. Virtu määrittelyn tulisi olla yhteensopiva sellaisten tuotteiden kanssa jotka täyttää IDP Lite tai SP virtupersonprincipalname-attribuutin loppuosa vastaa SAML2- metadatassa kyseiselle tunnistuslähteelle sallittuja loppuosia. Selvityksemme mukaan kaupalliset SAML2 Service Provider toteutukset mahdollistavat toiminnallisuuden, jossa saapuneisiin tunnistusselosteisiin kohdistetaan seuraava toimintosarja (esim. skripti): 1) poimi tunnistusselosteesta virtupersonprincipalnameattribuutun %-merkin jälkeinen osuus 2) ota luottamusverkoston SAML2-metadata, ja etsi tunnistusselosteen antaneen tunnistuslähteen elementti. 3) tarkista, että elementistä löytyy SAML2-profiilin kohdan 4.2.1 tarkoittama lapsielementti, joka vastaa virtupersonprincipalnamen %-merkin jälkeistä osuutta. 4) Jos ei löydy, hylkää kirjautuminen Virtu-esitutkimusvaiheessa saimme kaupallisia SAML2-tuotteita tarjoavilta yrityksiltä sensuuntaisia viestejä, että SAML-määritysten IdP/SP Lite profiilitkin ovat vielä tarpeettoman laajoja, ja niiden edellyttäminen rajaa Virtu-luottamusverkostosta ulos tuotteita, joilla Virtu-luottamusverkostossa vaadittavat toiminnallisuudet voitaisiin muuten toteuttaa. Tämän seurauksena määrittelyvaiheessa lähdettiin hakemaan pienintä tarpeellisena pidettyä SAML2-profiilia. Vastaavalla tavalla esimerkiksi Ficom ry on määritellyt ETSI 102 204/207 mobiiliallekirjoitusmäärityksille soveltamisohjeen, jota Suomessa käytetään. Tuki attribuuttien käsiteltävyydelle kaupallisissa tuotteissa jää testattavaksi piloteissa. Jos Virtu-luottamusverkoston turvamalli osoittautuu ylivoimaiseksi kaupallisille tuotteille, täytyy
Lite vaatimukset. Toisin sanoen Virtussa toimiville tuotteille ei tulisi asettaa muita vaatimuksia. Nyt Virtu asettaa pakolliseksi yhden SAML attribuutin. Tähän attribuuttiin on myös rakennettu oma Virtu-rakenne rakenne, jonka tulkinta pitää tehdä ohjelmallisesti IDP:n/SP:n päässä (eli nimi%domain -syntaksi) Olisi meidän mielestämme enemmän SAML-speksien ja tapojen mukaista pakottaa tuo käyttäjätunnus attribuutin sijaan NameID:ksi ja käyttää domainin ilmoittamiseen SAMLin omaa NameQualifierattribuuttia, joka on määritelty CORE-dokumentissa näin: "The security or administrative domain that qualifies the name. This attribute provides a means to federate names from disparate user stores without collision." Näin käytettäisiin SAML-speksien omia rakenteita käyttäjätunnuksen ja erityisesti nimen domainin käsittelyyn. Virtun SAML profiilissa jätetään hyvin monia yksiityiskohtia auki ja monien toimintojen kohdalla mainitaan optional. Tämä lähestymistapa tekee yhteensopivien järjestelmien tekemisestä hyvin hankalaa. Mitä tarkemmin ja spesifisemmin tuetut ominaisuudet pystytään rajaamaan, sitä helpompaa on järjestelmien liittäminen yhteen. Ihanteellisesti, jos nyt ei tiedetä käyttöä jollekin ominaisuudelle tai toiminnolle, se tulisi merkitä MUST NOT ja ominaisuudet joita tarvitaan MUST. Näin spesifikaatio tekisi selväksi kuinka järjestelmää on ajateltu käytettävän. Toisin kuin profiilissa mainitaan, metadatassa ei voi vaatia assertioiden salaamista. Signeerauksen vaatiminen on kyllä mahdollista. Lisäksi pienenä huomautuksena kappaleessa 4.2.3 esitelty analyysi "brokenidp.com"-palvelimen tekemistä valheellisista vahvemmista tunnistuksista on jossain määrin hämmentävä. Rikottu IDP:hän voi tehdä paljon enemmänkin pahaa, kuin väärentää vahvemman tunnistuksen? Sehän voi saman tien väärentää minkä tahansa kyseisen IDP:n hallinnassa olevat domainin käyttäjän identiteetin ja roolit. Rikotun IDP:n ongelma ei siten varsinaisesti liity vahvemman luottamusverkoston turvamallia ja arkkitehtuuria muuttaa. Määrityksiä kirjoitettaessa emme nähneet virtupersonprincipalnamen pakottamisen NameID-kenttään tuovan suurta lisäarvoa. Tutustumme NameQualifier-vaihtoehtoon. Hankimme lisää kokemusta eri vaihtoehdoista Virtu-piloteissa. Selvitetään. Hankitaan kokemuksia pilotissa. Tarkennetaan Murrettu tai pahansuopa tunnistuslähde voi aiheuttaa myös muuta häiriötä (vrt. edellä).
tunnistuksen pyytämiseen? Väestörekisterikeskus Dokumenteihin tarvittaisiin kokonaiset schemat ja esimerkit tunnistusprosessien sanomakuluista (viestisekvenssit, eli kuinka SAML-assertioita vaihdetaan osapuolten välillä). Dokumentaatiota tarvitaan yhtä lailla: - tarkentamaan toimittajien tekemistä käyttöönotoissa - toimittajaohjauksessa, jotta tilaaja voi ottaa kantaa toimittajan työmääriin, osaamiseen yms. - Virheselvittelyissä jne. Jos dokumentaatiot ovat kattavia, onnistuvat toteutuksetkin helpommin ja huomattavasti pienemmin kustannuksin. Kirjataan huomio ylös ja pyritään toteuttamaan se sitten, kun Virtuluottamusverkosto on käytössä ja painopiste siirtyy organisaatioiden tukemiseen Virtu-käyttöönotossa. SAML2.0:n perustoiminnallisuuksiin löytyy varsin hyvää aineistoa myös OASIS:n dokumentaatiosta: http://www.oasis-open.org/committees/download.php/28345/sstcsaml-tech-overview-2.0.pdf