Käsitteet ojennukseen: Active Directory (AD), LDAP, SSO ja identiteetinhallinta

Otathan huomioon, että tämä artikkeli on yli 13 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreempana lukemisena sinua voisi kiinnostaa vaikkapa jokin näistä artikkeleista:

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.

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.

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ä.

PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Parhaat muotoiluratkaisut tuote- ja palvelusivuille (15.5.2024 klo 10:00). Ilmoittaudu webinaariin

Perttu Tolvanen

KTM Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu konsultoi asiakkaita hankkeiden valmistelussa ja vaatimusten määrittelyssä sekä tukee asiakkaita teknologia- ja toteuttajakumppaneiden valinnassa.

Pertulla on yli viidentoista vuoden kokemus erilaisista web-, extranet- ja intranet-projekteista mm. projektipäällikön, suunnittelijan ja konsultin rooleissa. Aiemmassa työhistoriassaan Perttu on toiminut tilaajana ja projektipäällikkönä suuressa mediayhtiössä, sisällönhallintajärjestelmien konsulttina isossa IT-alan yrityksessä sekä itsenäisenä, riippumattomana konsulttina omassa yrityksessään. Hän on myös tunnettu kouluttaja ja bloggaaja. Perttu on myös päätoimittaja web-aiheisessa Vierityspalkki.fi -blogissa.

North Patrol auttaa onnistumaan

Meitä on kymmenen konsulttia, kaikki kokeneita suunnittelijoita tai teknologia-asiantuntijoita. Joka vuosi viemme läpi yli 50 projektia, joissa autamme hankkeensa eri vaiheissa olevia asiakkaitamme luomaan uusia digipalveluja ja tietojärjestelmiä. Asiakkaamme ovat olleet erittäin tyytyväisiä työhömme (arvosana 9,5/10), ja monet heistä palaavat asiakkaiksi yhä uudestaan.

Olemme apunasi, kun kaipaat puolueetonta näkemystä teknologiavalintoihin, kirkastusta palvelukonseptin ideaan, tarkennusta vaatimusten määrittelyyn, konkreettista tukea tarjouskilpailuun tai ohjausta toteutusprojektin läpivientiin.

Ota selvää firmastamme

Miten erotumme kilpailijoistamme?

  • Digipalveluiden suunnitteluun erikoistuminen

    Olemme erikoistuneet digipalveluiden laadukkaaseen suunnittelutyöhön ja vaatimusmäärittelyyn. Missiomme on auttaa asiakkaita onnistumaan hankkeissaan luomalla mahdollisimman hyvät lähtökohdat toteutusvaiheelle – oli sitten kyse ketterästä toteutuksesta omalla tiimillä tai kumppanin kanssa tehtävästä hankkeesta tai julkisesti kilpailutettavasta urakasta.

  • Emme myy koodausta emmekä lisenssejä

    Moni teknologiakonsultti suosittelee asiakkailleen teknisiä ratkaisuja, joita sama talo myös toteuttaa. Meillä tätä vinoumaa ei ole, koska meiltä ei voi ostaa koodausta tai lisenssejä eikä meillä ole riippuvuuksia teknologiatoimittajiin. Näkökulmamme ohjelmistomarkkinaan on laaja-alainen. Tavoitteena on aina löytää asiakkaalle parhaiten soveltuva ohjelmistoratkaisu, oli se sitten räätälöity ratkaisu, saas-palvelu, avoimen lähdekoodin alusta tai näiden yhdistelmä.

  • Tehokkuus, tavoitteellisuus ja tuloksellisuus

    Toimeksiannoillemme sovitaan aina konkreettinen lopputuotos, jonka avulla asiakas pääsee hankkeessaan eteenpäin. Hioutuneiden menetelmiemme ja kokeneiden konsulttiemme ansiosta pystymme tuottamaan sen tehokkaasti, yllättävän vähäisillä työmäärillä, ja rahallesi syntyy vastinetta.

Siirry takaisin sivun alkuun