Puhuvatko projektisi it-ihmiset mystisillä lyhenteillä, ja et aina kehtaa kysyä selvennystä? En minäkään. Tosin vuosien varrella sekin rohkeus on lisääntynyt, ja siksi tässä artikkelissa käydään läpi yleisimmät mystiset kirjainyhdistelmät joita intranet-projektien käyttäjähallintaan liittyy. Kirjoitus on suunnattu erityisesti intranet-projektien projektipäälliköille.
North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
29.4.2011
Active Directory (AD) – käyttäjähakemisto
Active Directorysta puhutaan monissa projekteissa ja organisaatioissa lyhenteellä ”AD” eikä termiä usein vaivauduta selventämään ellei joku uskalla kysyä selvennystä. Usein olisi kuitenkin paikallaan todeta, että kun viitataan AD:hen, niin tarkoitetaan yrityksen sisäverkossa olevaa palvelinta joka varastoi yrityksen henkilökunnan käyttäjätunnukset ja monia muita perustietoja. Tähän palvelimeen organisaation eri tietojärjestelmät sitten ottavat yhteyttä kun haluavat selvittää, että onko Virtasen Pertillä oikeus päästä käyttämään järjestelmää vai ei.
Tuotteena Active Directory on Microsoftin tuote, mutta toimii sujuvasti myös monien muidenkin kuin Microsoftin tekemien tietojärjestelmien kanssa. Joillekin teknisille ihmisille ”AD” onkin muodostunut lähes yleiskäsitteeksi jolla joskus viitataan laajemminkin yrityksen käyttäjähakemistoihin. Näin on etenkin hyvin Microsoft-valtaisessa Suomessa jossa yrityksien käyttäjätunnukset ja perustiedot (nimi, sähköpostiosoite) tallennetaan lähes poikkeuksetta Active Directory -käyttäjähakemistoihin.
Active Directoryn valta-asema selittyy erityisesti Outlook/Exchange-sähköpostiohjelmiston yleisyydellä. Suomessa kun organisaatiot yleensä käyttävät Microsoftin sähköpostijärjestelmiä vaikka ostaisivat portaalituotteensa Oraclelta, IBM:ltä tai jostain muualta. Monella organisaatiolla Active Directorysta onkin vuosien varrella tullut keskitetty paikka myös muiden tietojärjestelmien käyttäjätunnuksille ja käyttöoikeuksille.
Tähän yhteen käyttäjähakemistoon pyritään monessa organisaatiossa esimerkiksi luomaan kaikki ne ryhmät joihin yrityksen työntekijät kuuluvat. Näitä samoja ryhmiä kun voidaan sitten käyttää eri tietojärjestelmissä. Joissain organisaatioissa käyttäjähakemiston tiedoissa saattaa olla myös tiedot työntekijöiden osaamisesta, yhteystiedoista ja organisaatiosijainnista. Viime vuosina moni organisaatio onkin aktiivisesti laittanut käyttäjähakemistojaan kuntoon ja pyrkinyt keskittämään tietoja työntekijöistä nimenomaan käyttäjähakemistoon.
Perinteisestihän työntekijöiden tiedot ovat asuneet esimerkiksi henkilöstöhallinnon tietojärjestelmissä tai olleet hajallaan eri puolilla organisaatiota. Edelleen tosin on usein järkevää pitää esimerkiksi henkilöstöhallinnon tietojärjestelmä henkilötietojen ”master”-paikkana ja ainoastaan automaattisesti päivittää käyttäjähakemiston tiedot suoraan henkilöstöhallinnon tietojärjestelmästä (esimerkiksi eräajona kerran vuorokaudessa). Nämä tiedon omistajuuskysymykset ovat kuitenkin monessa organisaatiossa vielä kovin kesken, ja ei ole ollenkaan poikkeuksellista törmätä tilanteeseen jossa isonkin organisaation käyttäjätiedot ovat ”hujan hajan” eri puolilla organisaation tietojärjestelmiä.
”LDAP” (Lightweight directory Access Protocol) -käyttäjähakemisto
Kaikki yritykset eivät toki nojaa Microsoftin tuotteisiin ja tällöin käyttäjähakemistoon viitataan usein lyhenteellä ”LDAP”. LDAP tulee sanoista ”lightweight directory access protocol” ja ei sellaisenaan vielä edusta varsinaisesti tuotetta. LDAP-hakemistoja löytyy monelta eri toimittajalta, esimerkiksi Oraclelta. Suomessakin Oraclen OID tulee vastaan säännöllisesti.
Tarkkaan ottaen LDAP on tosin vain protokolla joka määrittelee tietyt palvelut, ja eri ohjelmistotoimittajat sitten hoitavat itse hakemiston toteutuksen parhaaksi näkemällään tavalla. Esimerkiksi Microsoftinkin Active Directory perustuu LDAP-määrityksiin vahvasti, koska Microsoft on halunnut Active Directoryn olevan mahdollisimman yhteentoimiva sellaisten järjestelmien kanssa jotka tukevat LDAP:ia, mutta eivät erityisesti Active Directorya. Voikin sanoa, että Active Directory on Microsoftin näkemys LDAP-käyttäjähakemistosta.
Käyttäjähakemistojen tilanne pitää tuntea ennenkuin mitään ostetaan tai asennetaan
Esimerkiksi intranet-projekteissa käyttäjähakemistojen haasteiden kanssa touhuaminen tulee monelle yllätyksenä. Esimerkiksi viestintäihmiset harvoin törmäävät muissa yhteyksissä käyttäjätietojen hallinnan haasteisiin. Tällöin kaikki AD:t, LDAP:it ja autentikaatiomenetelmät tuntuvat helposti ahdistavilta. Parhaimmillaan näistä asioista ei tarvitsekaan kovin paljon välittää vaan IT:ltä tulee selkeät reunaehdot hankinnalle ja tiedot siitä miten käyttäjätietoja organisaatiossa nykyisin hallitaan.
Monille sisällönhallintajärjestelmille onkin varsin samantekevää millainen käyttäjähakemisto organisaatiolla on käytössään. Etenkin järeämmät järjestelmät osaavat hyödyntää suoraan useiden eri käyttäjähakemistojen tietoja. Pienempiä tuotteita taas voi olla jopa mahdotonta saada integroitua johonkin erilliseen käyttäjähakemistoon. Esimerkiksi pienempiä kotimaisia julkaisujärjestelmätuotteita ei yleensä saa integroitua kovin ketterästi ulkoiseen käyttäjähakemistoon. Tosin jotkut isommatkin tuotteet osaavat olla kranttuja. Esimerkiksi SharePoint haluaa aina Microsoftin Active Directoryn kaverikseen käytännössä.
Intranet-projekteissa käyttäjähakemistot nousevat yleensä pöydälle silloin kun ryhdytään miettimään mitä tietoja käyttäjistä pitäisi pystyä näyttämään esimerkiksi profiilikortilla tai puhelinluettelossa. Tällöin nämä tiedot pitää saada haettua jostain. Jos tiedot taas eivät ole käyttäjähakemistossa (tai eivät ole ajantasalla siellä), niin täytyy ryhtyä selvittelemään miten organisaation käyttäjähakemiston saisi kuntoon. Onkin suorastaan tyypillistä, että intranet-projektin rinnakkaisprojektina laitetaan organisaation käyttäjähakemiston tiedot kuntoon niiltä osin kuin intranet-palvelu vaatii.
Myös esimerkiksi ryhmätyötiloihin ja dokumenttienhallintaan liittyvät käyttöoikeudet halutaan usein toteuttaa ryhmillä ja nämä ryhmät halutaan ylläpitää käyttäjähakemistossa. Tämä voi vaatia monenlaista remonttia organisaation sisällä. Esimerkiksi jos ryhmiä ja käyttöoikeuksia pitäisi päästä hallinnoimaan muuallakin kuin IT-osastolla, niin näiden oikeuksien hallintaan pitää joskus rakentaa jopa aivan omia käyttöliittymiä tai ostaa erillissovelluksia. Tällöin aletaan joskus olla hyvin lähellä myös niitä tarpeita joiden perusteella organisaatiot hankkivat identiteetinhallintajärjestelmiä.
Hakemistosekamelska on monessa organisaatiossa karu todellisuus
Isommilta organisaatioilta saattaakin löytyä erilaisia käyttäjähakemistoja lukuisia. Parhaimmillaan mukana joukossa on vielä useita Active Directory -hakemistoja ja onpa kaiken kuorrutukseksi vielä hankittu jokin identiteetinhallintajärjestelmä. Pahimmillaan eri järjestelmät käyttävät useiden eri käyttäjähakemistojen tietoja ja samojen henkilöiden käyttäjätunnuksia saattaa olla useassa eri hakemistossa (ja jopa useita eri käyttäjätunnuksia). Tätä kaaosta sitten jossain kohtaa yleensä yritetään ottaa hallintaan identiteetinhallintaprojektilla.
SSO (Single-Sign-On) -kertakirjautuminen
Käyttäjähakemistoista puhuttaessa törmätään usein myös lyhenteeseen ”SSO”, joka tulee sanoista ”Single-Sign-On”, ja tarkoittaa tilannetta jossa työntekijä kirjautuu vain yhden kerran, mutta saa samalla kertaa pääsyn useaan eri sovellukseen. Suomessa SSO:sta puhutaan joskus myös ”kertakirjautuminen” termillä.
Yhdenlainen SSO on esimerkiksi kirjautuminen omalle työasemalle, ja pääseminen tämän jälkeen esimerkiksi sähköpostiohjelmaan ilman uutta käyttäjätunnuksen ja salasanan syöttämistä. SSO on terminä siitä erikoinen, että moni liiketoimintaihminenkin tuntee yleensä SSO-termin ja osaa vaatia ohjelmistolta tätä. Valitettavasti SSO ei ole ominaisuus tai teknologia.
Jotta voidaan saavuttaa ”SSO-tila”, niin taustalla olevien käyttäjähakemistojen täytyy olla keskenään yhteensopivat tai pääsynhallinta tulee olla keskitetty (esim. vain yksi hakemisto, tai keskitetty identiteetinhallintajärjestelmä). Tämän lisäksi tulee olla käytössä järjestelmä joka kirjaa käyttäjän taustalla yhdellä kertaa useisiin eri järjestelmiin.
Joissakin organisaatioissa esimerkiksi on keskitetty käyttäjähallinta- ja pääsynhallinta, mutta käyttäjä ei pääse kaikkiin tietojärjestelmiin automaattisesti sisälle, vaan omat tunnukset tulee syöttää joka kerta kun haluaa päästä johonkin tietojärjestelmään. Etuna on tietysti se, että ei tarvitse muistaa kuin yhdet tunnukset, mutta kyllä käyttäjän kannalta on tällöin homma jätetty puolitiehen.
Suunnittelemme toimivan intranetin
North Patrolin suunnitteluprojekteissa määritellään toimivimmat työkaluratkaisut kuhunkin intranet-ympäristöön. Lisäksi intranetin palvelumuotoilulla ja prototyypeillä suunnitellaan sellaiset sisältöratkaisut, jotka tukevat sisäistä viestintää, tiedon löydettävyyttä ja arkisista työsuorituksista selviämistä.
Lue intranettien suunnittelupalveluistamme tai varaa suoraan Teams-palaveri Sarin kanssa
Identiteetinhallintaprojektiin ei kannata suhtautua maailmoja syleilevästi
Identiteetinhallinta on mielenkiintoinen käsite jota eivät edes alan konsulttitoimistot aina määrittele yhtenäisesti (konsulttifirmoja ovat esim. Nixu, Trusteq). Toiset suhtautuvat asiaan teknisemmin, toiset filosofisemmin. Filosofisesti ajatellen kyse on siitä, että organisaatiossa on määritellyt prosessit ja käytännöt siihen mitä tietoa tallennetaan käyttäjistä ja kuinka kauan tietoa säilytetään. Myös käyttäjien pääsynhallinta on suunnitelmallisesti hallittua. Teknisemmästä näkökulmasta katsoen kyse on siitä, että käyttäjähallintaa on organisaatiossa keskitetty yhteen ”megahakemistoon” tai identiteetinhallintajärjestelmään. Tällöin tämä yksi megahakemisto toimii käyttäjätietojen ”master”-tietopaikkana jonne muuttuneita tietoja päivitetään ja josta kaikki tietojärjestelmät hakevat tarvitsemansa tiedot käyttäjistä ja käyttäjiin liittyvistä oikeuksista.
Identiteetinhallinta onkin ollut viime vuosina melkoinen muotitermi ja joskus tämä hirvitys tulee vastaan myös intranet-projekteissa. Extranet-projekteissa identiteetinhallinta saattaa olla jopa isompi asia kuin itse extranetin rakentaminen. Intranet-projekteissa identiteetinhallinta korostuu etenkin silloin kun intranettiin halutaan päästää myös ulkopuolisia yhteistyökumppaneita hallitusti (esim. ryhmätyötiloihin). Valitettavasti identiteetinhallinta saattaa helposti myös karata käsistä. Ei ole ollenkaan harvinaista törmätä identiteetinhallintaprojekteihin jotka vain jatkuvat ja jatkuvat. Ja jos jotain onkin saatu valmiiksi, niin sen on todettu kuitenkin olevan vain puolittainen ratkaisu ja silti uusille tietojärjestelmille annetaan poikkeuslupia. Näin ei tietysti ole kaikkialla, ja monia hienojakin suorituksia on tullut vastaan.
Intranet-projekteissa on kuitenkin oppinut olemaan tarkkana tilanteissa joissa kuulee organisaatiossa olevan käynnissä ”identiteetinhallintaprojekti” jonka seurauksena ”kaikki muuttuu paremmaksi”. Tällöin on syytä selvittää tarkkaan millainen projekti on kyseessä, ja liittyykö siihen kenties jonkun erillisen identiteetinhallintajärjestelmän hankinta. Isoimmat projektit ovat nimittäin useiden vuosien projekteja joissa kartoitetaan nykytilannetta, rakennetaan visio täysin yhdistetystä käyttäjähallinnasta organisaatiossa ja lopulta ostetaan jokin massiivinen identiteetinhallintajärjestelmä jonka avulla voidaan ”orkestroida” kaikkia eri täsmähakemistoja ja hallita kokonaisuutta.
Ajatus on toki kaunis ja kannatettava. Organisaation etenemistä ei kuitenkaan kannata pysäyttää muutamaksi vuodeksi odottelemaan tämän projektin valmistumista.
Oma suositukseni onkin, että identiteetinhallintaan kannattaa suhtautua innostuneesti, mutta käytännönläheisesti. Liian massiivisilla ratkaisuilla vain hidastetaan tarpeettomasti organisaatioiden luontaista kehitystä ja uudistumista. Esimerkiksi intranet-projekteissa kannattaa aikaisessa vaiheessa selvittää käyttäjähallinnan nykytila organisaatiossa. Nykytilan pohjalta voi yleensä rakentaa muutaman eri vaihtoehdon käyttäjähallinnan toteutukselle ja nämä on syytä kirjoittaa mukaan myös tarjouspyyntöön. Jos omalla IT-osastolla on asian suhteen erittäin tiukat vaatimukset, niin nämäkin kannattaa keskustella läpi jotta ymmärtää miksi vaatimukset ovat olemassa ja mitä nämä tarkoittavat intranet-projektin kannalta.
Käyttäjähallinta ja käyttöoikeudet ovat asioita joita yksikään intranet-projektin projektipäällikkö ei voi ohittaa. Ja projektin onnistumisen todennäköisyyttä parantaa merkittävästi jos ymmärtää mistä on kyse silloin kun keskustellaan mystisillä AD/LDAP/SSO/identiteetinhallinta -termeillä.
Teknologiavalinta on vuosikymmenen investointi
Teknologiaratkaisuissa ei kannata tehdä valintojaan kuumimpien trendien mukaan, vaan soveltuvuuden, skaalautuvuuden, ylläpitokokemuksen, yhteensopivuuden ja elinkaarikustannuksien ehdoilla. North Patrol auttaa näkemään teknologiavaihtoehtojen plussat ja miinukset puolueettomasti, konkreettisesti ja kaukonäköisesti.
