Child pages
  • Brukeradministrasjon, autentisering og autorisasjon
Skip to end of metadata
Go to start of metadata

Tilbake til tjenestekatalog

0. Innhold

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

2. Om brukeradminstrasjon

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.

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

4. 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åloggings-
lø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.

5. 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 sesjons-
cookie med en valid SSO-sesjon. I tilfelle nettleseren har en valid SSO-sesjon får vedkommende tilgang til den url-en vedkommende i utgangs-
punktet 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 url'en 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 generelt datautvekslingsnav 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 WebSSO-lø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.

6. Innhold i tjenesten

Tjenesten inneholder følgende deltjenester

Drift

Ordinær drift av AD
Ordinær drift av openLDAP
Ordinær drift av Kerberos
Ordinær drift av Radius
Ordinær forvaltning av BAS
Ordinæ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.

7. Begrensninger i tjenesten

Ingen utover de som naturlig følger av tjenestens funksjonsområde.

8. Kundens forpliktelser/ansvar

Kunden/kundens representanter er ansvarlig for å sørge for at data i alle kildersystemer (PAGA/FS) er oppdaterte.

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