• Johdanto
• Sovellus tai käyttöjärjestelmä, jolle riittää pelkkä tunnistaminen (authentication) tai enintään ryhmäjäsenyys- ja perustiedot
• Sovelluksen siirtäminen käyttämään uutta LDAP-hakemistoa
• Sovelluksen rekisteröinti
• Sovelluksen konfigurointiohje

Johdanto

Usein verkkosovellukset (tai sivustot) halutaan suojata niin, että vain tietyt käyttäjät pääsevät käyttämään sovellusta. Suojaamisessa on kaksi tasoa:

• tunnistaminen (authentication): käyttäjä tunnistetaan siksi kuka hän väittää olevansa esim. pyytämällä yliopiston käyttäjätunnus ja salasana.
• valtuuttaminen (authorization): tunnistuksen lisäksi käyttäjän valtuus sovelluksen käyttöön tarkistetaan. Tällöin vain tietyt tunnistetut käyttäjät pääsevät käyttämään sovellusta ja/tai sovelluksen sisällä käyttövaltuudet vaihtelevat eri käyttäjien välillä. Valtuudet voidaan hallinnoida esimerkiksi Hero-järjestelmällä, Alma-ryhmien avulla tai sovelluksen sisäisesti.

Yllä olevat kaksi käyttötapausta on syytä erottaa, kun sovellusta ollaan suojaamassa vapaalta käytöltä.

Tarkemmat tiedot Helsingin yliopistossa käytetävistä teknisistä ratkaisuista autentikointiin ja auktorisointiin löydät sivulta Keskitetyn käyttäjätunnistuksen vaihtoehdot.

Huom. LDAP-hakemisto ei ole enää tuettu tunnistusmenetelmä uusiin web-palveluihin.

Helsingin yliopistossa on montaa eri tyyppiä olevia käyttäjätunnuksia. Näistä tärkeimmät ovat

• normaalit henkilökohtaiset käyttäjätunnukset, joita on ylivoimaisesti suurimmalla osalla käyttäjistä (käyttäjätunnus sisältää vain kirjaimia ja on muodostettu käyttäjän etu- ja/tai sukunimestä)
• kevyttunnukset vierailijoita ja ns. ulkopuolisia käyttäjiä varten (käyttäjätunnus on muotoa numero + k-kirjain + numerosarja)
• maksulliset ulkopuoliset käyttäjätunnukset (käyttäjätunnuksessa on alaviiva jossain kohdassa)
• Ylläpito- ja hallintatunnukset (käyttäjätunnuksessa on alaviiva jossain kohdassa)
• testitunnukset (käyttäjätunnuksessa on alaviiva jossain kohdassa)
• kurssi- ja konferenssitunnukset (käyttäjätunnuksessa on alaviiva jossain kohdassa ja sen perässä numerosarja)

Seuraava taulukko havainnollistaa miten edellä mainitut tekniikat ja erilaiset käyttäjätunnustyypit suhtautuvat toisiinsa.

 edellyttää että sovelluksessa voidaan määritellä rinnakkain käyttöön eri LDAP-hakemistoa / hakupolkua

Kevyttunnus-tyypillä ei ole kohdassa AD rastia, mikä siis tarkoittaa että AD:ta ei voi käyttää ko. käyttäjätunnustyypin tapauksessa tunnistamiseen tai valtuuttamiseen.

Shibboleth käyttää tällä hetkellä osin vanhaa LDAP-hakemistoa. Tämän takia se vastaa taulukossa vanhaa LDAP-hakemistoa. Myöhemmin Shibboleth siirtyy käyttämään uutta LDAP-hakemistoa. Tällöin siitä tippuu pois ne käyttäjätunnusjoukot, joita ei ole uudessa LDAP-hakemistossa.

On huomattava, että yliopiston käyttäjätunnustenhallintajärjestelmää ollaan uudistamassa IAM-hankkeessa ( https://wiki.helsinki.fi/display/IAMasioita ). Tässä yhteydessä kevyttunnuksille ja mahdollisesti myös testitunnuksille on tulossa korvaavat ratkaisut. Kevyttunnus tulee korvautumaan käyttäjätunnustyypillä joka vastaa nykyistä henkilökohtaista käyttäjätunnusta, mutta on valtuuksiltaan rajattu.

Sovellus tai käyttöjärjestelmä, jolle riittää pelkkä tunnistaminen (authentication) tai enintään ryhmäjäsenyys- ja perustiedot

LDAP-palvelin ldapauth.it.helsinki.fi on käytettävissä autentikointiin yliopiston sisäverkossa ilman erillistä rekisteröintiä; toivotaan kuitenkin, että käyttäjä ilmoittautuu palvelun käyttäjäksi SP-rekisterissä ja merkitsee rastin ruutuun "Käyttääkö tämä palvelu LDAPAuthia?" - palvelimien nimiä ei tarvitse merkitä, koska oletus on, että palvelinjoukot elävät. LDAPAuthia käytetään kuten ldap2015-palvelintakin, sillä erotuksella, että käyttäjistä ja käyttäjäryhmistä saadaan vain käyttöjärjestelmätason pääsynhalintaan vaadittavat tiedot; myös pelkkä autentikointi tätä kautta onnistuu. Palvelimen SSL-sertifikaatti on allekirjoitettu Terenan julkisella CA:lla, joten LDAP-asiakasohjelmisto pitää konfiguroida hyväksymään Terenan sertifikaatti.  Jos haluat käyttää Linuxin ldapsearch komentoa testaukseen, muista antaa sille -d 7 vipu, jotta näet myös mahdolliset virheilmoitukset.

Esimerkki pelkästä autentikoinnista (haetaan cubblien defaultti-basesta dc=ad,dc=helsinki,dc=fi alkaen; tätä basea ei ldapauth-palvelussa ole olemassakaan, joten Janin hausta tulee no such object; autentikointi kuitenkin onnistuu)

jjaakkol@lx8-cubbli18:~$ ldapsearch -W -x -H ldaps://ldapauth.it.helsinki.fi/ -D uid=jjaakkol,ou=people,dc=helsinki,dc=fi
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=ad,dc=helsinki,dc=fi> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object
matchedDN: dc=helsinki,dc=fi

# numResponses: 1
jjaakkol@lx8-cubbli18:~$

Esimerkki käyttäjän perus- ja ryhmäjäsenyystietojen hakemisesta anonyymisti:

jmmpelto@tuhtipyy:~$ ldapsearch -xZZH ldap://ldapauth.it.helsinki.fi:389 -b ou=people,dc=helsinki,dc=fi uid=lankka \* memberOf
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=helsinki,dc=fi> with scope subtree
# filter: uid=lankka
# requesting: * memberOf
#

# lankka, people, helsinki.fi
dn: uid=lankka,ou=people,dc=helsinki,dc=fi
uid: lankka
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: eduPerson
objectClass: schacContactLocation
objectClass: schacLinkageIdentifiers
objectClass: schacPersonalCharacteristics
objectClass: funetEduPerson
objectClass: funetEduPerson2
objectClass: hyEduPerson
objectClass: posixAccount
objectClass: sambaSamAccount
objectClass: schacEntryMetadata
objectClass: inetLocalMailRecipient
memberOf: cn=grp-a02700-all,ou=groups,dc=helsinki,dc=fi
memberOf: cn=grp-idp-test,ou=groups,dc=helsinki,dc=fi
gidNumber: 1032815
uidNumber: 1032815
givenName: Lupu
cn: Lupu Ankka
loginShell: /bin/bash
gecos: Lupu Ankka
sn: Ankka
homeDirectory: /home/lankka

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1
jmmpelto@tuhtipyy:~$

(memberOf pitää mainita erikseen, koska se on ns. tekninen attribuutti LDAPissa)

Esimerkki ryhmäobjektin tietojen hakemisesta anonyymisti:

jmmpelto@tuhtipyy:~$ ldapsearch -xZZH ldap://ldapauth.it.helsinki.fi -b ou=groups,dc=helsinki,dc=fi cn=grp-tike-testmailrouting
# extended LDIF
#
# LDAPv3
# base <ou=groups,dc=helsinki,dc=fi> with scope subtree
# filter: cn=grp-tike-testmailrouting
# requesting: ALL
#

# grp-tike-testmailrouting, groups, helsinki.fi
dn: cn=grp-tike-testmailrouting,ou=groups,dc=helsinki,dc=fi
cn: grp-tike-testmailrouting
description: To test group based LDAP mail routing
gidNumber: 4203585
uniqueMember: uid=foobaruserremove,ou=people,dc=helsinki,dc=fi
uniqueMember: uid=vmkari,ou=people,dc=helsinki,dc=fi
uniqueMember: uid=jmmpelto,ou=people,dc=helsinki,dc=fi
objectClass: top
objectClass: posixGroup
objectClass: groupOfUniqueNames
objectClass: hyPosixGroup

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1
jmmpelto@tuhtipyy:~$

(Huom ylimääräinen placeholder-jäsen foobaruserremove, joka on kaikissa ryhmissä teknisistä syistä. Siitä ei kuitenkaan sinänsä pitäisi olla harmia.)

Apache-esimerkki (ipreg .htaccess)

AuthLDAPGroupAttribute uniquemember

AuthLDAPURL ldaps://ldapauth.it.helsinki.fi:636/ou=people,dc=helsinki,dc=fi?uid
Require ldap-group cn=hy-tike-allstaff,ou=groups,dc=helsinki,dc=fi
Require ldap-group cn=grp-a02700-verkkorekisteri,ou=groups,dc=helsinki,dc=fi

Sovelluksen siirtäminen käyttämään uutta LDAP-hakemistoa

Kun sovellus siirretään käyttämään yliopiston uutta ldap2015-nimistä LDAP-hakemistoa, tarkista ja tee seuraavat asiat:

1. Tarkista, että muutamien käyttäjätunnustyyppien häviäminen ei ole sovelluksen kannalta ongelma. Jos tämä on ongelma, neuvottele tietotekniikkakeskuksen käyttäjähallinnon kanssa, miten menetellään jatkossa.
2. Tarkista, syntyykö sovellukseen henkilörekisteri ja onko rekisteriseloste tehty. Pääsääntöisesti pelkkä tunnistaminen ei synnytä henkilörekisteriä, mutta muuten sellainen voi hyvinkin syntyä. Tarvittaessa kysy Tietoturvaryhmältä lisätietoja henkilötietojen käsittelystä ja rekisteriselosteen laatimisesta.
3. Tarkista, miten käyttäjien valtuuttaminen on hoidettu. Käytetäänkö siihen jotain LDAP:sta löytyvää attribuuttia tai ryhmäjäsenyyttä. Osa attribuuteista säilyy uudessa LDAP-hakemistossa ennallaan, mutta osa katoaa. Valtuuttamisessa käytetyt ryhmät pitää jatkossa nimetä. Kysy tarvittaessa apua sovelluksen ylläpitäjältä.
4. Varmista, että sinulla on yksiköstä, tietotekniikkakeskuksesta tai toimittajalta apuna taho, joka pystyy ja osaa tehdä tarvittavat muutokset sovellukseen. Uuden LDAP-palvelun osoite on eri kuin vanhan. Lisäksi konfigurointiin tulee muitakin muutoksia (riippuen sovelluksesta).
5. Tutustu sovelluksen rekisteröintiin ja rekisteröi palvelusi LDAP-hakemiston käyttäjäksi (katso seuraava luku). Uusi LDAP-hakemisto on paljon suljetumpi kuin vanha. Syynä tähän on tietoturvan parantaminen ja käytäntöjen yhtenäistäminen suhteessa muihin edellä kuvattuihin teknisiin ratkaisuihin.
6. Jos sovellus käyttää LDAP-hakemistoa valtuuttamiseen
   1. Tutki yhdessä ylläpitäjän kanssa miten uuden palvelun ja vanhan palvelun tarjoamat tiedot eroavat. Huomatkaa, että sekä käyttäjien että ryhmien ns. pitkät DN-nimet muuttuvat, joten näitä voi joutua muuttamaan konfiguraatiossa tai pahimmillaan myös järjestelmän sisäisessä käyttäjähakemistossa. Monimutkaisemmat tapaukset kannattaa katsoa läpi yhdessä tietotekniikkakeskuksen asiantuntijoiden kanssa.
   2. Jos järjestelmä on yliopiston ydintoimintojen kannalta tärkeä tai käyttää valtuuttamiseen yhtään monimutkaisempaa tapaa, kannatta myös miettiä miten mahdollisissa pahoissa ongelmatilanteissa muutos voidaan tilapäisesti perua.
7. Tee tai pyydä sovelluksen ylläpitäjää tekemään tekniset muutokset esimerkiksi sovelluksen huoltoikkunan aikana. Tämä sisältää mm. rekisteröitymisen kautta saatavan palvelutunnuksen käyttöönoton.
8. Testaa toiminta ja tarvittaessa peruuta muutokset aiemmin tekemäsi suunnitelman mukaisesti.

Sovelluksen rekisteröinti

Ennen rekisteröintiä tutustu

• Identiteetin- ja käyttövaltuuksienhallinnan periaatteisiin https://wiki.helsinki.fi/pages/viewpage.action?pageId=149314010
• sekä LDAP-hakemiston dokumentaatioon https://wiki.helsinki.fi/display/IAMasioita/2.+LDAP-hakemisto.

Tee sovelluksen rekisteröinti uuden LDAP-hakemiston käyttäjäksi  SP-rekisterissä https://sp-registry.it.helsinki.fi (ohjeita sivulla LDAP SP-rekisteri tai englanniksi LDAP SP-Registry) . Noin 2 viikon sisällä rekisteröinnistä Tietotekniikkakeskus toimittaa palvelutunnuksen rekisteröitymisessä annettuun sähköpostiosoitteeseen. Sovellus käyttää tätä palvelutunnusta LDAP-hakemiston kanssa kommunikointiin (toisin kuin vanhassa LDAP-hakemistossa yleensä).

Rekisteröinti tulee tehdä erikseen järjestelmän kehitys-, testi- ja tuotantoympäristöjä varten, jotta niille voidaan tehdä erilliset palvelutunnukset.

Sovelluksen konfigurointiohje

Rekisteröitymisen yhteydessä on pyydetty ilmoittamaan sovelluksen palvelimien täydelliset nimet. Huolehdithan siitä, että LDAP-palvelimiin yhteyttä otetaan näitä nimiä vastaavista IP-osoitteista. Muussa tapauksessa yhteyttä ei voida muodostaa.

Ldap-palvelimen nimi on "ldap2015.it.helsinki.fi" ja siinä voi käyttää joko porttia ldap (389) (suositeltu, STARTTLS vaaditaan) tai porttia ldaps (636). LDAP-URI:t ovat siis muotoa ldap://ldap2015.it.helsinki.fi/ tai ldaps://ldap2015.it.helsinki.fi/

Tavalliset käyttäjätunnukset sijaitsevat LDAP-haarassa "ou=people,dc=helsinki,dc=fi", siis esim kasitunnus "lankka" olisi muodossa "uid=lankka,ou=people,dc=helsinki,dc:fi". Kevyttunnukset taas sijaitsevat haarassa "ou=lightaccounts,ou=people,dc=helsinki,dc=fi", siis esim. "1a23456" olisi muodossa "uid=1a234567,ou=lightaccounts,dc=helsinki,dc=fi". Jos sovelluksesi kirjautuu käyttäen käyttäjätunnusta, huolehdithan, että se päätyy oikeaan muotoon. Käyttäjätunnuksesta ei lähtökohtaisesti näe kuin pienen osan kaikista sen tiedoista, vaikka kirjautuisi tunnuksella.

Esimerkkejä konfiguraatiosta

#1 Autentikointi

Tämä on yksinkertaisin käyttötapaus. Sovelluksen tehtäväksi jää huolehtia siitä, että se ottaa yhteyttä oikeaan osoitteeseen (ldap2015.it.helsinki.fi portti ldap tai ldaps) oikeasta osoitteesta (rekisteröitäessä ilmoitettu palvelimen nimi) ja kirjautuu LDAP-palvelimelle käyttäen käyttäjätunnusta oikeassa muodossa (uid=<kasitunnus>,ou=people,dc=helsinki,dc=fi tai kevyttunnusten tapauksessa uid=<kevyttunnus>,ou=lightaccounts,ou=people,dc=helsinki,dc=fi).

HUOM! Tässä käyttötapauksessa käyttäjästä ei sovellukselle välitetä kuin hyvin kapea osajoukko sen attribuuteista, vaikka LDAP-hakemistoon kirjaudutaankin käyttäjän omalla tunnuksella! Jos haluat saada lisää attribuutteja käyttöösi, ilmoita tästä rekisteröitymisen yhteydessä. Jos sovelluksesi ei tue attribuuttien hakemista erillisellä palvelutunnuksella, on myös mahdollista lisätä sovelluksen IP-osoite luotetuksi, jolloin käyttäjätunnus saa laajemman joukon attribuutteja kirjautuessaan sovelluksesi osoitteesta. Tästä on kuitenkin sovittava erikseen; lähtökohtaisesti, jos sovelluksesi haluaa nähdä käyttäjän tietoa, sen tulee käyttää erillistä palvelutunnusta. IP-pohjainen tarkistus edellyttää myös, että sovelluksellasi on käytössään oma IP-osoite; jos samalla palvelimella (esim www-hotellissa) on useita sovelluksia, IP-osoitepohjaista tunnistusta ei voida käyttää.

#2 Ryhmäjäsenyyksien tarkistaminen

Käyttäjän ryhmäjäsenyydet näkee käyttäjän attribuutista memberOf, johon sovelluksen palvelutunnus saa pääsyn, kunhan sovellusta rekisteröitäessä on muistettu mainita, että sovellus tarvitsee pääsyn käyttäjän ryhmäjäsenyyksiin. Kyseiseen attribuuttiin pääsee käsiksi sovelluksen palvelutunnuksella (tai, jos sovellus ei kerta kaikkiaan tue erillisen palvelutunnuksen käyttöä, käyttäjän omalla tunnuksella sovelluksen IP-osoitteesta; kts. kohta 1 Autentikointi). Palvelutunnus salasanoineen on toimitettu sovelluksen vastuuhenkilölle käyttäen turvapostia.

#3 Tiettyjen käyttäjäjoukkojen synkronointi

Jos sovellus on rekisteröity synkronoimaan LDAP-hakemistosta tiettyjä käyttäjäjoukkoja tietyin attribuutein, tähän käytetään erillistä palvelutunnusta, joka on toimitettu sovelluksen vastuuhenkilölle käyttäen turvapostia. Koska synkronointipalvelutunnuksien käyttömäärärajoituksia on lievennetty, toivomme, että synkronointia enintään kerran vuorokaudessa, jottei se aiheuttaisi kohtuutonta kuormaa LDAP-palvelimille.