Kladd

Om dokumentet
Dette dokumentet beskriver hva tjenesten for brukeradministrasjon, autentisering og autorisasjon er,
hvordan den er bygd opp, og hvordan den fungerer i praksis. Dokumentet er ment som grunnlag for
beslutninger vedrørende hvordan man bruker tjenesten, og som vedlegg til tjenestenivå-avtaler
(SLA) knyttet til tjenesten.
Om brukeradministrasjon
Brukeradministrasjon er basisen som er nødvendig for at autentisering og autorisasjon skal være
mulig. Brukeradministrasjon handler om hvordan man samler sammen grunnlagsdata om individer,
hvordan denne brukes for å skape elektroniske identiteter, og hvordan informasjon om disse
elektroniske identitetene blir spredt ut til de ulike systemene.
Det er i hovedsak to scenario hvor man er avhengig av brukeradministrasjon; i tilfeller hvor man
trenger tilgang til data om de ulike individene og tilfeller hvor man skal benytte de elektroniske
identitetene for autentisering og autorisasjon.
Om autentisering og autorisasjon
Ofte ser vi på autentisering (å legitimere seg) og autorisasjon (å få tilgang til) som to sider av
samme sak. Likevel må vi nyansere en del, siden et system som står for autentisering, ikke
nødvendigvis også er kapabel til å foreta autorisasjon, og omvendt.
Autentisering er at en part, i dette tilfellet brukeren, beviser ovenfor en annen part, i dette tilfellet et
IT-system, at vedkommende virkelig er den vedkommende gir seg ut for å være.
Under de fleste omstendigheter tilfredsstilles kravet til bevis i denne sammenhengen ved at
brukeren kjenner en hemmelighet som kun brukeren kan kjenne; passordet. Likevel har vi i mange
situasjoner i samfunnet behov for høyere sikkerhet på autentiseringen, og ytterligere bevis,
eksempelvis med engangspassord for BankID og pinkoder for MinID. Slike varianter kalles gjerne
for to-faktor-autentisering.
Autorisasjon er at brukeren blir gitt tilgang til konkrete beskyttede ressurser basert på et regelsett.
Dette regelsettet kan implementeres på ulike måter i en rekke ulike systemer, men det er mer
sjeldent enn vanlig at det er autentiseringssystemet som også står for autorisasjon.
Om IAM og BAS
Ved NTNU har vi til en hver tid i overkant av 52.000 aktive IT-brukere. For på en praktisk, sikker
og sporbar måte forvalte disse brukeridentitetene har man sentrale systemer på plass. En
fellesbenevning for slike identitetsforvaltningssystemer er IAM (Identity and Access Management).
Bruk av IAM-systemer for forvaltning av blant annet brukernavn og passord gir mulighet for
sentrale påloggingsløsninger. NTNU har benyttet ulike typer IAM-systemer siden begynnelsen av
90-tallet.
BAS står for Brukeradministrative Støttesystemer og er dagens IAM-system. Det er motoren som
sørger for at brukerens brukernavn og passord ligger på alle nødvendige autentiserings-systemer, og
der er oppdatert til enhver tid. BAS inneholder en database med profildata om personen som eier
brukeren, og har også en del annen informasjon som er nødvendig for at de ulike systemene skal
kunne identifisere vedkommende.
BAS kan også benyttes til å populere systemer med informasjon om individene som har
elektroniske identiteter ved NTNU.
Beskrivelse av tjenesten
WebSSO (Web Single Sign-on) via Feide
WebSSO er en tjeneste som sørger for at tilgang til ulike nettsider kan sikres på en slik måte at man
kun trenger å skrive brukernavn og passord èn gang. En slik sesjon har begrenset varighet, men rent
praktisk vil man ikke måtte autentisere seg mer enn en gang hver dag ved hjelp av denne tjenesten.
Feide er den tekniske implementasjonen av WebSSO som er i bruk ved NTNU. Feide driftes og
forvaltes av Uninett, og er en nasjonal WebSSO-løsning som benyttes på systemer som også skal
tillate innlogging for personer fra andre institusjoner i universitet- og høgskolesektoren.
Tjenesten er satt opp for å støtte høy tilgjengelighet og feiltoleranse og benytter LDAP som
støttesystem for autentisering.
Tekniske detaljer
En pålogging til en nettside (beskyttet url) foregår ved at PHP-kode kjøres på webserveren og
sjekker hvorvidt nettleseren har en sesjonscookie med en valid SSO-sesjon. I tilfelle nettleseren har
en valid SSO-sesjon får vedkommende tilgang til den url-en vedkommende i utgangspunktet
forsøkte å nå. Dette skjer sømløst og uten at brukeren merker noe til det som foregår i bakgrunnen.
Hvis nettleseren ikke har en valid SSO-sesjon blir vedkommende videresendt til et påloggingsskjema
som driftes av Feide.
Påloggings-skjema tar brukernavn og passord som innverdier. Dette blir kontrollert opp mot
innholdet i brukerdatabasen i people-greina på at.ntnu.no (LDAP), og brukerens identitet blir på
denne måten verifisert. Deretter blir en sesjonscookie satt og brukeren videresendes til den url-en
vedkommende først forsøkte å nå.
InnsidaSSO-wrapper
Alle systemer som benytter gamle InnsidaSSO bruker en url som peker til et underområde av
innsida.ntnu.no. Der brukes det PHP for å returnere valid sesjon for gamle InnsidaSSO.
Siden denne url-en også er beskyttet av Feide, vil alle gamle systemer som forsæker å nå denne urlen
gjennomgå samme runde som beskrevet ovenfor. PHP-koden som url-en peker på vil returnere
det klientkoden forventer etter en vellykket pålogging.
LDAP
LDAP benyttes i hovedsak som støttesystem for Feide, men benyttes også til andre systemer,
spesielt i tilfeller hvor man trenger større fleksibilitet enn man kan få til med den mer statiske
strukturen i AD.
LDAP benyttes også som generell datautveklsingshub mellom BAS og andre systemer som kan lese
data fra LDAP-serveren.
LDAP kan inneholde både brukere og grupper, og ved hjelp av disse håndtere både autentisering og
autorisasjon.
Tjenesten er satt opp for å støtte høy tilgjengelighet og feiltoleranse.
Tekniske detaljer
LDAP-tjenesten består av flere fysiske servere med en varierende trestruktur av dataobjekter. Her
har man fleksibilitet til å lage separate greiner med bruker- og gruppe-objekter, slik at man kan
finjustere både hvem som har mulighet til å logge seg på, og hvilke grupper vedkommende er
medlem i. Typisk vil enten mulighet for pålogging, eller også medlemsskap i grupper påvirke
hvorvidt vedkommende er autorisert til å få tilgang til ressursene som er beskyttet.
LDAP-tjenesten baserer seg på protokollversjon 3
Kerberos
Kerberos er en påloggingstjeneste som primært brukes for pålogging til UNIX-servere. Dette kan
være alt fra rene påloggings-maskiner til NTNUs sentrale epost-motor (SMTP) og andre sentrale
servere.
Kerberos er primært lagd for å støtte Single-SignOn slik at brukere ikke trenger å presentere
brukernavn og passord flere enn en gang pr sesjon.
Tjenesten er satt opp for å støtte høy tilgjengelighet og feiltoleranse.
Active Directory (AD)
AD benyttes i hovedsak til pålogging på windows-maskiner og sentral epostløsning (Exchange),
men kan lett benyttes til andre systemer i tillegg. Den brukes også som støttesystem for WebSSOløsningen
vi har i dag.
Rent teknisk er AD en sammenkobling av LDAP og Kerberos, utviklet av Microsoft, som også lager
Windows og Office. I kraft av å være en LDAP-implementasjon støtter AD både autentisering og
autorisasjon, og i kraft av å være en Kerberos-implementasjon støtter den Single-SignOn.
Tjenesten er satt opp for å støtte høy tilgjengelighet og feiltoleranse.
Tekniske detaljer
AD-tjenesten består av flere fysiske servere med en fast trestruktur av dataobjekter. Typisk vil
medlemsskap i grupper påvirke hvorvidt vedkommende er autorisert til å få tilgang til ressursene
som er beskyttet.
AD-tjenesten går på Windows Server 2008 R2.
Radius
Radius benyttes til pålogging på VPN og pålogging til det trådløse nettet Eduroam.
Tjenesten er satt opp for å støtte høy tilgjengelighet og feiltoleranse.
RSA
RSA-tjenesten er en form for to-faktor-pålogging. Med to-faktor kreves det mer enn et passord for å
bevise at man er den brukeren brukernavnet tilsier. Man må også benytte en engangskode-brikke, på
samme måte som med BankID.
Tjenesten brukes i hovedsak til pålogging på spesielt sårbare systemer med høye krav til sikkerhet.
RSA-systemet styres kun delvis av BAS/IAM.
Funksjonalitetsmatrise
Noen ganger er det enkelt å velge system for autentisering og autorisasjon. Det kan for eksempel
være at systemet man skal sette opp autentisering og autorisasjon for er lagd spesielt med tanke på
en utvalgt teknologi, og da bør man selvfølgelig benytte denne. Mange systemer er for eksempel
lagd med AD som eneste eller mest naturlige integrasjonspunkt.
Andre ganger er det ikke like enkelt. Spesielt kan det være vanskelig når mange tekonologier
støttes, og man ikke helt ser hvilke muligheter og begrensninger de ulike teknologiene har.
Denne matrisen er lagd for å gjøre det enklere å velge hvilke systemer man skal benytte i de ulike
tilfeller.
Autentisering Web SSO Autorisasjon SSO Eksterne brukere* 2-faktor
Feide JA JA NEI JA JA NEI
LDAP JA NEI JA NEI NEI NEI
AD JA NEI JA JA NEI NEI
Kerberos JA NEI NEI JA NEI NEI
Radius JA NEI NEI NEI NEI NEI
RSA JA NEI NEI NEI JA JA
* Med eksterne brukere menes at systemet kan gi tilgang til brukere uten tilknytning til NTNU.
Gjelder kun Feide.
Innhold i tjenesten
Drift av Active Directory (AD)
Ordinær drift av AD
Drift av LDAP
Ordinær drift av openLDAP
Drift av Kerberos
Ordinær drift av Kerberos
Drift av Radius
Ordinær drift av Radius
Forvaltning av BAS
Ordinær forvaltning av BAS
Forvaltning av NTNUS bruk av Feide
Ordniær forvaltning av NTNUs bruk av Feide.
Tilgang
Sørge for alle aktuelle brukere ved NTNU blir lagt i BAS med:
• bruker i LDAP slik at de kan logge seg på via Feide og LDAP.
• Bruker i kerberos-tjenesten
• Bruker i Radius-tjenesten
NTNU IT må sørge for at aktuelle brukere automatisk representeres på de respektive systemene.
Henvendelser
Brukerstøtte
Orakel er 1.linje for henvendelser.
BAS-teamet er 2. linje for henvendelser.
De respektive drifts- og forvaltningsansvarlige er 3. linje for henvendelser.
Feilhåndtering og oppgradering
De respektive drifts- og forvaltningsansvarlige er ansvarlige for feilhåndtering og oppgradering.
Begrensninger i tjenesten
Ingen utover de som naturlig følger av tjenestens funksjonsområde.
Prising
Brukeradministrasjon
Tjenesten er rammefinansiert.
Tjenestespesifikk brukeradministrasjon
Hvis en tjeneste krever tilpasninger i hvordan brukeradministrasjon gjennomføres må dette prises
isolert sett i det spesifikke tilfellet siden tilpasningene kan være av ulik kompleksitet.
Autentisering
Tjenesten er rammefinansiert
Tjenestespesifikk autentisering
Hvis en tjeneste krever tilpasninger i hvordan autentisering gjennomføres må dette prises isolert sett
i det spesifikke tilfellet siden tilpasningene kan være av ulik kompleksitet.
Autorisasjon
Tjenesten er rammefinansiert
Tjenestespesifikk autorisasjon
Hvis en tjeneste krever tilpasninger i hvordan autorisasjon gjennomføres må dette prises isolert sett
i det spesifikke tilfellet siden tilpasningene kan være av ulik kompleksitet.