Kysymys Vastaus Viite Rivi 26, IdM-järjestelmä integroituu Itä-Suomen yliopiston Azure AD:hen ja suomi.fitunnistautumispalveluun. Onko kyseessä kaksi liitettävää tunnistuspalvelua (Azure AD ja suomi.fi) joista tulee hyväksyä tunnistautunut käyttäjä VAI erilliset toiminnallisuuden kuten Azure AD kohdejärjestelmänä jonne provisioidaan tunnus ja suomi.fi tunnistuslähteenä VAI jotain muuta? Kyseessä on kaksi liitettävää tunnistuspalvelua. Tiedot päivittyvät Azure AD:lle paikallisen AD:n kautta. Rivi 37, IdM-järjestelmän on kyettävä tietokantarajapintojen avulla valvomaan ulkoisia tietokantoja IDM:n ylläpitämien tietojen päivittämiseksi. Mitä tarkoittaa tietokantojen valvonta? Jos toimitamme ratkaisun palveluna, voidaanko silloin käyttää toimittajan valitsemaa palvelun sisäistä tietokantaratkaisua toimittajan konesalissa tai valitsemassa kohteessa? Rivi 57, IdM-järjestelmän tulee automaattisesti luoda, ylläpitää ja poistaa organisaatiorakenteen mukaisia rooleja sekä LDAP- ja AD-ryhmiä. Mitä automaattisesti luodut roolit palvelevat / mihin käyttöön tulevat? Mistä tulee organisaatiorakenne? Rivi 58, IdM-järjestelmän tulee automaattisesti luoda, ylläpitää ja poistaa sopimustyypin mukaisia rooleja sekä LDAP- ja AD-ryhmiä. Mihin käyttöön roolit tulevat? Luodaanko ADryhmiä vai tarkoitetaanko tässä olemassa oleviin AD-ryhmiin liitettäviä identiteettejä? Onko esimerkkejä näistä tapauksista? Ulkoinen tietokanta sisältää tietoja käyttäjistä ja käyttäjien oikeuksista/käyttöoikeussopimuksesta. IDM-järjestelmän tulee pystyä tarkkailemaan muutoksia ulkoisessa tietokannassa ja provisoimaan käyttöoikeuksia tapahtuneiden muutoksien perusteella. Ulkoinen tietokanta voidaan tässä siis rinnastaa lähdejärjestelmään. Tietokannan tiedot voidaan lukea myös kertaluontoisesti sisälle uuteen identiteetinhallintajärjestelmään. Automaattisesti luotujen roolien perusteella erotellaan esimerkiksi opiskelijat ja henkilökunta. Näiden perusteella myönnetään myös automaattisesti käyttöoikeuksia Organisaatiorakenne tulee henkilöstötietojärjestelmästä (Mepco) sekä opintotietojärjestelmästä (Oodi). Organisaatiorakenne tulee henkilöstötietojärjestelmästä (Mepco) sekä opintotietojärjestelmästä (Oodi). IdM:n tulee pystyä automaattisesti ylläpitämään organisaatiorakenteen mukaisia ADryhmiä. Nykyisellään organisaatiorakenne on toteutettu AD-ryhmillä hierarkisesti. Esimerkkinä UEF henkilökuntaan kuuluva käyttäjä, joka työskentelee toimipaikassa nimeltä Tietotekniikkapalvelut (Koodi 101180). Tietotekniikkapalvelut kuuluu yliopistopalveluihin (1011) joka taas kuuluu yliopiston johtoon (10). UEF-Employee (UEF Henkilökuntaa) UEF-Employee-10 UEF-Employee-1011 (Yliopistopalvelut yksikössä) UEF-Employee-101180 (Tietotekniikkapalvelut yksikössä) Esimerkiksi jos organisaatiorakenne muuttuu ja yliopistoon perustetaan uusi yksikkö, organisaation muutos tehdään henkilöstöjärjestelmään ja tämän perusteella IDM luo tarvittavat ryhmät AD:lle. ks edellinen.
Rivi 59, IdM-järjestelmän tulee automaattisesti luoda, ylläpitää ja poistaa rooleja sekä ADja LDAP-ryhmiä, jotka ovat samanaikaisesti sidoksissa sekä sopimustyyppiin että (MEPCO). Roolit määräytyvät voimassaolevien työsopimusten mukaisesti. * Sopimustyypit tulevat henkilökunnan osalta henkilöstöhallintojärjestelmästä organisaatioon. Esim. "tiedekunnan X opiskelijat", "kustannuspaikan Y henkilökunta", Työsopimus sisältää mm. attribuutteja alkaa, loppuu, yksikkö, titteli ym. Joiden "laitoksen Z muuhun henkilökuntaan rinnastettavat". Samalla identiteetillä voi olla useita perusteella idm tulee osata provisioida oikeat roolit * Sopimustyypit opiskelijoiden erilaisia sopimustyyppejä, jotka voivat kohdistua eri organisaatioyksikköön (esim. osalta tulevat opintotietojärjestelmät. Roolit määräytyvät voimassaolevien opintooikeuksien perusteella. Opinto-oikeus sisältää mm. attribuutteja alkaa, loppuu, laitos, henkilökuntaa yksikössä A ja opiskelija yksikössä B). Samalla identiteetilä voi myös olla useita samanlaisia sopimustyyppejä, jotka kohdistuvat eri organisaatioyksikköön (esim. opintojen tyyppi henkilökuntaa yksikössä C ja D). Kaikista näistä yhdistelmistä on luotava automaattisesti Roolien ja ryhmien hallinta kuuluu oleellisesti identiteetinhallintaprosessiin. vastaavat roolit ja ryhmät. Liittyen ilmeisesti riveihin 57 ja 58. Mistä sopimustyyppi ja Esimerkki: Henkilöllä alkaa uusi työsopimus 1.1.2019 ja päättyy 31.12.2019. organisaatio tieto päätellään? Tuleeko roolit ja ryhmät liittää myös automaattisesti Työsopimus tehdään yksikköön Tietotekniikkapalvelut ja henkilön työnimike on ITasiantuntija. Nämä edellämainitut tiedot kirjataan henkilöstöjärjestelmään uutena mukaan identiteetinhallintaprosessiin? Esimerkit identiteetin käsittelystä kun rooli ja ryhmä luodaan automaattisesti? tietueena. Idm-järjestelmä havaitsee, että kyseisen henkilön käyttäjätunnukseen on tullut muutoksia ja laskee uudet roolit/käyttöoikeudet pohjautuen tähän työsopimuksen tietoon. Ryhmät provisioidaan automaattisesti myös tämän tiedon perusteella. Esimerkiksi jos käyttäjä on esimies annettaisiin AD-ryhmä UEF- Managers.. Ja organisaation AD-ryhmät aiemmin olleen esimerkin mukaisesti. Henkilörekisteristä voidaan siirtää käyttäjä- ja työsopimustiedot suoraan keskitettyyn identiteettivarastoon eikä erillistä SQL-pohjaista käyttäjä- ja sopimuskantaa silloin tarvita. Onko Mepcosta saatavilla sopimustiedot vaiko se vain lisätietojen tuoja esim palkanmaksujärjestelmänä? Mikä on erillisen MSSQL käyttäjä- ja sopimustietokannan rooli uudessa toteutuksessa? Onko se pakollinen komponentti osana henkilökunnan tietolähteen ketjua? MEPCOSTA on saatavilla henkilökunnan sopimustiedot, joiden perusteella käyttöoikeudet voidaan provisioida. Jos uusi tuote tarjoaa vastaavan toiminnallisuuden sisäänrakennettuna, voidaan erillisestä MSSQL kannasta luopua. Tässä tapauksessa tietokantojen sisältämät tiedot voidaan lukea uuteen järjestelmään sisään kertaluontoisesti. Erillinen MSSQL käyttäjä- ja sopimusietokanta on tarvittu niiden käyttäjien tietojen ja sopimusten lähdejärjestelmäksi, joilla ei ole suoraa työsopimusta yliopistoon (MEPCO) tai opiskeluoikeutta (OODI). Tällaisia lisäkäyttöoikeuksia pitää pystyä edelleen anomaan ja antamaan. Pakolliset vaatimukset E08: Mikäli sähköpostiosoitetta ei kyetä luomaan, tulisi käyttäjää informoida tästä. Mitä mediaa tässä haluttaisiin käytettävän? Itsepalveluportaalin huomautus tunnusta vastaanottaessa? Käykö SMS viesti? Mikäli henkilöllä ei ole mobiilinumeroakaan, käykö ilmoitustie service deskin kautta? Pakolliset vaatimukset E17: Oodista on saatavilla opiskelijat valittu (2) -tilassa ennen lukukautta ja näin voisi mennä vaikkapa jatkuvasti käynnissä olevan opiskelijavalinnan kanssa. Tarkoittaako kyseinen vaatimus tätä? Vai onko kyseessä täysin lähderekisteririippumaton identiteetti, joka pitäisi tehdä esimerkiksi käyttäjän itserekisteröitymisenä? Tai molemmat Jos käyttäjällä on tiedossa oleva puhelinnumero, voidaan käyttää tekstiviestiä. Muussa tapauksessa ilmoitus voidaan lähettää services deskiin. Kun opiskelijoilla on opintotietojärjestelmässä opinto-oikeus valittu-tilassa heidän E17: Käyttäjäidentiteetin aktivionti- ja käyttöönottomahdollisuus ennen tulee olla mahdollista aktivoida tunnuksensa käyttöön itsepalveluportaalin kautta virallisen sopimuksen/opinto-oikeuden alkamista käyttäen suomi.fi-tunnistautumista. Vastaavasti henkilökunnan tulisi pystyä aktivoimaan tunnuksensa käyttöön 2 viikkoa ennen henkilötietojärjestelmässä olevaa sopimuksen alkamispäivämäärää ennen rajoitetuin oikeuksin. Pakolliset vaatimukset A01: Identiteettivaraston toiminta UFOrekisterinä on mahdollista Kyllä täyttyy. muttei ehkä suositeltavaa. Täyttyykö vaatimus, jos tarjotaan UFOrekisteriä, sen integrointia ja käyttöliittymää tarjouksen osana? Projektin aikataulu: olemme parhaillaan ison IDM-toteutuksen parissa ja halusisimme Käyttöönottoprojekti pyritään aloittamaan mahdollisimman pian kilpailutuksen tietää, milloin toteutus viimeistään on aloitettava. päättymisen jälkeen ja järjestelmän tulisi olla tuotantokäytössä 1.1.2019 alkaen. Voisitteko vielä sanoa käyttäjienne lukumäärät: henkilökunta, opiskelijat ja muut. Tutkinto-opiskelijoita noin 15000, avoimen opiskelijoita noin 7000, henkilökuntaa noin 2500
IdM-järjestelmä luo uusille käyttäjille automaattisesti sähköpostiosoitteen henkilökunnalle määritellyn nimeämiskäytännön mukaisesti. Mikäli IdM-järjestelmä ei pysty luomaan käyttäjälle sähköpostiosoitetta automaattisesti nimeämiskäytännön mukaisesti, ilmoittaa IdM-järjestelmä epäonnistumisesta käyttäjälle. Epäonnistuneesta luonnista pitää välittyä tieto servicedeskille, jotta servicedesk voi muodostaa kokonimiosoitteen manuaalisesti IdM-järjestelmässä. Sähköpostisoitteen elinkaaren hallinta: päiväykset milloin sähköpostiosoite/alias poistunut käytöstä. Varattujen sähköpostiosoitteiden lista: Listan katselu ja muokkaus. Jos IDM luo käyttäjille osoitteet niin se myös hallitsee niitä. Kysymyksemme on, miksi tätä reaaliaikaista listaa pitää voida muokata? Manuaalista muokkaamista tarvitaan vain joissain erikoistapauksissa. Esimerkiksi henkilön sähköpostiosoitteen muuttuessa (esimerkiksi sukunimi vaihtuu) tulee vanha alias pysyä varattuna (secondary) käyttäjälle myös jatkossa. Näpä erikoistapaukset pystytyään myös mahdollisesti automatisoimaan. E17 Käyttäjäidentiteetin aktivionti- ja käyttöönottomahdollisuus ennen virallisen sopimuksen/opinto-oikeuden alkamista. Millä säännöillä tämä tulisi olla mahdollista? Käyttäjäindentiteetin tulisi olla aktivoitavissa kaksi viikkoa ennen työsopimuksen/opinto-oikeuden alkamista. Vaatimus T01: Tuleeko tarjota molemmat vaihtoehdot vai riittääkö hyväksyttyyn Toimittaja voi tarjota joko molemmat vaihtoehdot tai vain toisen. tarjoukseen joko on-premise- tai pilviratkaisu? Vaatimus R04: Tarkoitetaanko tässä tietokannoilla HR-järjestelmää (Mepco), Ulkoisella tietokannalla tarkoitetaan tässä tapauksessa käyttäjäsopimustietokantaa. opiskelijatietojärjestelmää (Oodi), henkilöstötietojärjestelmää (Prima) ja käyttäjäsopimustietokantaa vai jotain muuta? Vaatimus E02: Tarkoitetaanko tällä sitä, että lähdejärjestelmien luotetuimmuus on oltava määritettävissä identiteettikohtaisesti vai yhdellä parametrilla järjestelmän laajuisesti Henkilötietojen osalta lähdejärjestelmän luotetuimmuusjärjestys on oltava määriteltävissä järjestelmän laajuisesti. Eli mikä henkilötietojen osalta on ensisijaisin ja luotetuin lähdejärjestelmä ja mikä seuraavaksi jne. Tätä järjestystä noudatetaan kaikille identiteeteille. R04: IdM-järjestelmän on kyettävä tietokantarajapintojen avulla valvomaan ulkoisia tietokantoja IDM:n ylläpitämien tietojen päivittämiseksi. E02: IdM-järjestelmän tulee mahdollistaa henkilötietojen siirto useammasta määräävästä lähdetietojärjestelmästä. Mikäli sama tieto (henkilö) löytyy useammasta lähdejärjestelmästä, IdM-järjestelmään tulee voida määritellä luotetuimmuusjärjestys. Luotetuimmuusjärjestyksen perusteella IdMjärjestelmä valitsee, minkä lähdejärjestelmän henkilöstä tarjoamat tiedot IdM-järjestelmä välittää eteenpäin kohdejärjestelmiin. Vaatimus E04: Onko tarkoitus, että vaatimuksessa kuvattu käyttäjäidentiteetin käyttöönotto tapahtuu IDM-järjestelmän puitteissa vai onko tätä varten olemassa jokin ulkopuolinen sovellus/portaali, josta tieto tulee IDM:lle? Vaatimus E14: Tarkoittaako rooli tässä käytännössä ilmentymää vastaavista AD ja LDAP - ryhmistä? Vai onko tarpeen, että näihin automaattisesti luotaviin rooleihin voidaan käsin liittää muitakin käyttöoikeuksia (esim. AD-ryhmiä)? Mille identiteettimäärille ratkaisu tulisi, eroteltuna käyttäjätyypeittäin (opiskelijat, henkilökunta, ulkoiset)? Voiko tarjoukseen sisältyä englanninkielistä materiaalia? Millä aikavälillä käyttöönottoprojektin tulisi alustavasti tapahtua? Tuleeko käyttöönottoprojektiin sisältyä roolien ja prosessien määritystyötä? Mikäli kyllä, kuinka monen roolin ja/tai prosessin osalta Vaatimuksessa kuvattu käyttöönotto tapahtuu IDM-järjestelmän sisällä. Roolilla tarkoitetaan henkilön sopimuksen kautta tulevaa roolia esim. työntekijä tai perusopiskelija. Näiden roolien perusteella käyttäjälle tulee provisioida vastaavat AD ja LDAP ryhmät. Rooleihin tulee pystyä lisäämään tarvittava määrä esim. AD-ryhmiä, jotka provoisioidaan. Tutkinto-opiskelijoita noin 15000, avoimen opiskelijoita noin 7000, henkilökuntaa noin 2500 Kyllä voi Käyttöönottoprojekti pyritään aloittamaan mahdollisimman pian kilpailutuksen päättymisen jälkeen ja järjestelmän tulisi olla tuotantokäytössä 1.1.2019 alkaen. Rooleja tullaan määrittelemään uudelleen, mutta se on lähinnä sisäistä työtä. Pyrimme vähentämään roolien määrää ja sujuvoittamaan ja automatisoimaan prosesseja. Rooleja ja prosesseja tullaan varmasti myös käymään läpi yhdessä toimittajan kanssa, mutta tarkkaa määrää on vaikea sanoa. E04: IdM-järjestelmän tulee mahdollistaa uuden käyttäidentiteetin luonti "Luotu" -tilaan. E14: IdM-järjestelmän tulee automaattisesti luoda, ylläpitää ja poistaa rooleja sekä AD- ja LDAP-ryhmiä, jotka ovat samanaikaisesti sidoksissa sekä sopimustyyppiin että organisaatioon. Esim. "tiedekunnan X opiskelijat", "kustannuspaikan Y henkilökunta", "laitoksen Z muuhun henkilökuntaan rinnastettavat". Samalla identiteetillä voi olla useita erilaisia sopimustyyppejä, jotka voivat kohdistua eri organisaatioyksikköön (esim. henkilökuntaa yksikössä A ja opiskelija yksikössä B). Samalla identiteetilä voi myös olla useita samanlaisia sopimustyyppejä, jotka kohdistuvat eri organisaatioyksikköön (esim. henkilökuntaa yksikössä C ja D). Kaikista näistä yhdistelmistä on luotava automaattisesti vastaavat roolit ja ryhmät.
Tarjouspyyntö mahdollistaa ratkaisun tarjoamista pilvipalveluna - minkälainen vastuunjako ylläpito- ja tukipalveluiden osalta on tavoitteena? * Ylläpitäisikö Itä-Suomen Yliopiston henkilöstö sovellusta esim. mahdollisten rooli- ja prosessimuutoksien osalta? Kyllä. Ostamme tarvittaessa konsulttiapua toimittajalta tuntityönä. * Vastaisiko Itä-Suomen Yliopiston henkilöstö ratkaisun ohjelmisto- ja tietoturvapäivitysten Kyllä asennuksista? * Ottaako Itä-Suomen Yliopiston henkilöstö vastaan loppukäyttäjien tukipyynnöt Kyllä, loppukäyttäjien tukipyynnöt käsitellään Itä-Suomen Yliopiston henkilöstön toimesta. * Tuleeko ylläpito- ja tukipalvelut tarjota suomenkielisinä Mahdollisuuksien mukaan kyllä. Minkälaiset palvelu- ja vasteajat olisivat? Kyseessä on yliopiston toiminnan kannalta kriittinen järjestelmä, joten vasteaikojen tulisi olla sen mukaisia. Vasteaikoihin vaikuttaa myös se, ajetaanko järjestelmää omassa konesalissa vai pilvipalveluna. * Tuleeko käyttöönottoprojektiin sisältyä Itä-Suomen Yliopiston henkilöstön kouluttamista Järjestelmän pääkäyttäjien koulutuksen sekä pääkäyttäjien tarvitseman ja/tai koulutusmateriaalin tuottamista? dokumentaation tuottamisen tulee sisältyä käyttöönottoprojektiin. - Hintalomakkeessa kohdassa 1 pyydetään vuosihintoja Järjestelmän yhteenlasketut Pilvi-vaihtoehdossa tässä vitataan myöskin infra- ja käyttöpalvelukustannuksiin. vuosikustannukset sisältäen käyttöoikeus/lisenssi-, ylläpito- ja tukikustannukset Viitataanko ylläpito- ja tukikustannuksilla vain tuotteen tukeen (päivityspaketit, tuotetukipyynnöt) vai myöskin pilvi-vaihtoehdossa infra- ja käyttöpalvelukustannuksiin? Käytetäänkö asteikkoa 1-3-5 (rivillä 5) vai 1-2-3? Millaista aikataulua projektille on ajateltu? Milloin käyttöönottoprojekti alkaisi? Onko tarkoitus hankkia järjestelmän lisenssit osto- vai vuokrausmallilla? Ilmeisesti hinnat halutaan molempiin kohtiin eli järjestelmä asiakkaan omassa konesalissa sekä järjestelmä pilvipalveluna palveluntarjoajan konesalissa? Haluaako Itä-Suomen yliopisto mielummin omistaa lisenssit vai vuokrata ne? Ohjelmistolisenssit IdM-järjestelmälle hinnoitellaan tyypillisesti käyttäjämäärän mukaan. Tulevien vuosien käyttäjämäärä ei tietenkään ole nyt tiedossa. Onko mahdollista tehdä hinnoittelu nyt tiedossa olevien käyttäjämäärien mukaan ja laskea sillä hinnat tuleville vuosille - kuitenkin siten että todellisuudessa realisoitunutta käyttäjämäärä käytetään tulevina vuosina laskutusperusteena? Voi siis olla enemmän tai vähemmän kuin tämän hetkisillä käyttäjämäärillä laskettu kustannus. Yksikköhinta toki olisi sama. Käyttöönottoprojektista sanotaan tarjouspyynnössä seuraavaa: Tietokantaan tehdään näkymä, jonka perusteella idm voi lukea henkilö- ja sopimustiedot. Kysymys: Onko edellä mainitun näkymän tekeminen tietokantaan asiakkaan vastuulla (ennen käyttöönottoprojektia) vai toimittajan vastuulla tehdä se osana käyttöönottoprojektia? Käytämme asteikkoa 1-2-3, dokumenttiin on jäänyt virhe tuon osalta. Käyttöönottoprojekti on tarkoitus käynnistää heti kilpailutuksen ratkettua ja tuote on tarkoitus ottaa käyttöön 2018-2019 vuodenvaihteessa. Jos järjestelmää ajetaan omassa konesalissa, ostamme tarvittavat lisenssit. Pilvipalveluna tuotetun järjestelmän lisenssit vuokrataan. Haluamme hinnat molempiin kohtiin. Jos järjestelmää ajetaan omassa konesalissa, ostamme tarvittavat lisenssit. Pilvipalveluna tuotetun järjestelmän lisenssit vuokrataan. Kyllä on mahdollista. Asiakkaan vastuulla Mitä valmiita rajapintoja lähdetietojen siirtämiseksi Mepco ja Oodi sekä MSSQL-tietokanta tarjoavat? Onko halutut käyttöoikeusroolit valmiina kuvattuina? Vai pitääkö käyttöönottoprojektissa varata aikaa näiden määrittelyyn / suunnitteluun? Oodista ja MSSQL-tietokannasta tulevat tiedot voidaan lukea sisälle järjestelmään välitaulun kautta. Mepco tuottaa tiedon työsuhteista joko XML- tai CSVformaateissa. Rooleja tullaan määrittelemään uudelleen, mutta se on lähinnä sisäistä työtä. Pyrimme vähentämään roolien määrää ja sujuvoittamaan ja automatisoimaan prosesseja. Rooleja tullaan myös käymään läpi yhdessä toimittajan kanssa. Mikä on toivottu aloitusaika projektille? Projekti pyritään aloittamaan mahdollisimman pian kilpailutuksen päättymisen jälkeen ja tavoite on, että uusi järjestelmä olisi käytössä 1.1.2019 alkaen.
Lainaus liitteestä 5 Lähdejärjestelmä voi olla joko tiedon lähde, provisioinnin kohde tai molemmat. Kysymys: Mitkä lähdejärjestelmistä toimivat myös kohdejärjestelminä Kun Azure AD on kohdejärjestelmänä, niin mitä tietoja on tarkoitus välittää ja päivittää Azure ADn suuntaan? Liitteessä 1 mainitaan lähdejärjestelmänä henkilöstötietojärjestelmä Prima ja liitteessä 5 henkilöstöhallinnan järjestelmä MEPCO. Kysymys: Kumpi näistä on käytössä vai ovatko ne molemmat? Lainaus Liitteestä 2: R04 IdM-järjestelmän on kyettävä tietokantarajapintojen avulla valvomaan ulkoisia tietokantoja IDM:n ylläpitämien tietojen päivittämiseksi. Kysymys: Onko käyttöönottoprojektin aikana tarkoitus vähentää käytössä olevien tietokantojen määrää? Kysymys: Voisimmeko saada mahdollisimman pian kuvaukset kaikista uuteen IdMjärjestelmään liitettävistä rajapinnoista (erityisesti Azure AD:n rajapintakuvauksen)? Lainaus Liitteestä 2: Liitä tarjoukseesi IdM-ohjelmistoon kohdistuvien (miel. riippumattomien tahojen suorittamien) suorituskykytestien tulokset. Kysymys: Aiheuttaako mahdollinen testitulosten puuttuminen tarjouksen hylkäämisen? Tällä hetkellä Oodi-opintotietojärjestelmä toimii myös kohdejärjestelmänä opiskelijan sähköpostiosoitteen osalta. Toiminnallisuutta tarvittaneen myös opintotietojärjestelmän vaihtuessa tulevaisuudessa. Tiedot päivittyvät Azure AD:lle paikallisen AD:n kautta. AD:lta välitetään henkilön perustiedot ja AD ryhmätiedot Tällä hetkellä käytössä on Prima, mutta otamme Mepcon käyttöön 1.1.2019 alkaen. Uuteen IDM-järjestelmään ei siis tule mitään kytköksiä Primaan. Kyllä, tarkoitus on vähentää tietokantojen määrää jos uusi tuote tarjoaa vastaavan toiminnallisuuden sisäänrakennettuna. Tässä tapauksessa tietokantojen sisältämät tiedot voidaan lukea uuteen järjestelmään sisään kertaluontoisesti. Toimitamme kuvaukset rajapinnoista kilpailutuksen päätyttyä. Tiedot päivittyävät Azure AD:lle paikallisen AD:n kautta. Ei aiheuta. IdM-järjestelmän on kyettävä tietokantarajapintojen avulla valvomaan ulkoisia tietokantoja IDM:n ylläpitämien tietojen päivittämiseksi.