kartlegging av behov for sammenkopling av feide og lokale ... · sammenkopling av feide og lokale...
TRANSCRIPT
Rapport
Kartlegging av behov for
sammenkopling av Feide og lokale
innloggingsløsninger
Til
Samarbeidsrådet for Feide
Fra
Arbeidsgruppen for sammenkopling av Feide
med lokale innloggingsløsninger
Forfatter
Lars Kviteng
Dato
23.11.2017
Rapport
Side 2 av 157
Ledelsessammendrag
I perioden juni til november 2017, har en arbeidsgruppe utredet behov for sammenkopling
av Feide og lokale innloggingsløsninger hos vertsorganisasjonene. Utredningen bygger på
styrende dokumenter, en spørreundersøkelse som ble sendt til alle vertsorganisasjonene og
diskusjoner i arbeidsgruppen. Det er identifisert tre behovsområder:
• Sammenkopling av Feide med klientinnlogging, slik at brukeren automatisk logges på
Feide-tjenester etter innlogging på en administrert klient.
• Sammenkopling av Feide med innlogging som brukes på lokale tjenester, både når
innloggingen til disse tjenestene går mot lokale kataloger, skyføderasjoner, ID-porten
eller andre større ID-leverandører.
• Større fleksibilitet i samspillet mellom vertsorganisasjonene og tjenesteleverandørene
for å gi et utvidet handlingsrom for innovasjon og avanserte løsninger.
Det er identifisert flere potensielle gevinster, hvor den den viktigste er bedret
brukeropplevelse. Arbeidsgruppen peker også på at økt delegering fra Feide til
vertsorganisasjonene, vil gi større rom for innovasjon og lokale tilpasninger. Dette er
strategisk viktig for å sikre at Feide forblir en relevant og foretrukket tjeneste for
vertsorganisasjoner med avanserte behov.
Når det gjelder prioritering av nødvendige tiltak, samt vilje og evne til å gjennomføre
endringer knyttet til sammenkopling av Feide med lokale innloggingsløsninger, gir
spørreundersøkelsen en indikasjon på at det ligger i området middels til lavt. Behovene er
også ulike, slik at det vanskelig å finne løsningsalternativer som har oppslutning hos alle.
Arbeidsgruppen anbefaler å gå videre med arbeidet for sammenkobling av Feide med
lokale innloggingsløsninger, og at tiltakene spisses i forhold til to grupper av
vertsorganisjoner:
Organisasjoner som ønsker fleksibilitet og stor grad av lokale tilpasningsmuligheter.
De har høy teknisk kompetanse, og økonomisk spillerom. Et aktuelt løsningsalternativ for
disse, er å delegere autentiseringen fra Feide (som proxy) til lokale løsninger hos verts-
organisasjonene. Dette vil løse mange av de identifiserte behovene og brukstilfellene, men
medfører kostnader både sentralt og lokalt.
Organisasjoner som ønsker enkelhet, forutsigbarhet og størst mulig grad av sentralisering.
For disse ligger det potensielt store gevinster i å utnytte de eksisterende funksjoner i Feide
i større grad. Særlig gjelder dette muligheten til å presentere lokale innloggingsløsninger
som en tjeneste (revers proxy) og klientinnlogging med web-SSO. Økt bruk av disse
mulighetene kan oppnås ved å utforme veiledningsmateriell og kurs, men det bør også
settes av ressurser til kartlegging og testing av nye brukstilfeller.
Rapport
Side 3 av 157
Sammendrag
Denne rapporten utreder behov for sammenkopling av Feide og lokale innloggingsløsninger
hos vertsorganisasjonene. Arbeidet ble gjennomført i perioden juni til november 2017 av
en gruppe etablert av UNINETT. Oppdraget har bakgrunn i flere henvendelser fra
medlemmene i Feide-føderasjonen og saksinnmeldinger både fra prioriteringsrådet i Feide
for grunnopplæringen og prioriteringsrådet for mellomvare i høyere utdanning.
Arbeidsgruppens sammensetning representerte de ulike typene av vertsorganisasjoner i
Feide-føderasjonen, samt UNINETT. I tillegg ble det hentet inn en ekstern prosessleder.
Følgende personer var en del av arbeidsgruppen ved avslutningen av arbeidet:
• Mathias Meisfjordskar, Universitetet i Oslo
• Kent Overholdt, NTNU
• Arne Grevskott, Nord universitet
• Karl Magnus Storfjord, IKT Agder
• Per Hovde, BIBSYS
• Bernt Rygg, Oslo kommune
• Lars Kviteng, UNINETT
• Snorre Løvås, UNINETT
• Annette Grande Furset, UNINETT
• Jørgen Longva, Fundator
Mandatet for arbeidet var å legge frem en velbegrunnet anbefaling på om det bør gjøres et
videre arbeid på området ut fra:
• Innhentede faktiske behov fra ulike brukergrupper i sektoren.
• Kartlagte brukstilfeller.
• Kartlagt interesse for å ta i bruk en slik integrasjon på kort/lengre sikt.
• Kartlagte administrative og tekniske muligheter og utfordringer.
• Kartlagte gevinster og kostnader.
• Kartlagte konsekvenser for policy, ansvarsforhold og økonomi.
Rapport
Side 4 av 157
Behovskartleggingen, analysen og anbefalingene i rapporten bygger på flere informasjons-
kilder, herunder styrende dokumenter for hvordan Feide-føderasjonen styres og opereres,
en spørreundersøkelse som ble sendt til alle vertsorganisasjonene og diskusjoner i
arbeidsgruppen.
Spørreundersøkelsen ble brukt for å hente inn informasjon fra en størst mulig bredde av
vertsorganisasjoner. Den inneholdt to konkrete eksempler på situasjoner hvor
sammenkopling av Feide med lokale innloggingsløsninger kunne gi forbedringer. Videre
kartla den hvilke lokale løsninger ble brukt for klientinnlogging og tjenesteinnlogging. Til
sist, var det tatt med spørsmål om hvorvidt vertsorganisasjonene har evne og vilje til å
finansiere og gjennomføre nødvendige endringer, både de som må gjennomføres lokalt og
de som må gjennomføres sentralt. Vi fikk svar som representerte 39 % av vertsorganisa-
sjonene.
Ut fra arbeidsgruppens diskusjoner og tilbakemeldingene fra spørreundersøkelsen, er
følgende behovsområder identifisert:
• Sammenkopling av Feide med klientinnlogging, slik at brukeren automatisk logges på
Feide-tjenester etter innlogging på en administrert klient.
• Sammenkopling av Feide med innlogging som brukes på lokale tjenester, både når
innloggingen til disse tjenestene går mot lokale kataloger, skyføderasjoner, ID-porten
eller andre større ID-leverandører.
• Større fleksibilitet i samspillet mellom vertsorganisasjonene og tjenesteleverandørene
for å gi et utvidet handlingsrom for innovasjon og avanserte løsninger.
For hvert av disse behovsområdene, har det blitt identifisert et antall underliggende
brukstilfeller. Brukstilfellene for de første to områdene er definert ut fra hvilke lokale
løsninger som er i bruk. For det første behovsområdet, sammenkopling av Feide med
klientinnlogging, er følgende løsninger i bruk lokalt hos vertsorganisasjonene:
På klientsiden dominerer administrerte Windows-PC-er, men det er også en vesentlig andel
utstyr av andre typer. Det er også mange klienter som ikke er administrert.
3%
4%
17%
76%
Google Directory med kopling mot Feide
Google Directory
Azure AD
Lokal Microsoft AD
Rapport
Side 5 av 157
For det andre behovsområdet, sammenkopling av Feide med lokale løsninger for tjeneste-
innlogging, oppga vertsorganisasjonene at følgende løsninger ble brukt:
For det tredje behovsområdet, større handlingsrom for lokal innovasjon og avanserte
løsninger, har arbeidsgruppen identifisert følgende eksempler på brukstilfeller:
• Avansert lokal login.
• Tilpasset login per tjeneste.
• Bedre brukeropplevelse for brukergrupper i randsonen av utdanningssektoren.
• Lokal styring av Attribute Release Policy.
Eksemplene er foreløpige, og generelt er behovet høyere løsningsmessig fleksibilitet. Før
man går videre med tiltak, må brukestilfellene konkretiseres og detaljeres.
Kartleggingen har identifisert flere potensielle gevinster som kan oppnås ved sammen-
kopling av Feide med lokale innloggingsløsninger. Beskrivelsen av gevinstene er gjort på en
strukturert måte, slik at de kan brukes for prioritering av tiltak og detaljeres videre i
senere prosjektforslag. De fleste av gevinstmulighetene er indirekte eller langsiktige,
strategiske gevinster:
• Bedret brukeropplevelse. Gevinsten oppstår blant gjennom en mer intuitiv bruker-
opplevelse, at brukeren slipper å skrive inn brukernavn og passord flere ganger og bedre
synkronisering av passord.
• Mindre behov for brukerstøtte. Den reduserte arbeidsmengden kommer av færre
brukerhenvendelser om separat pålogging til Feide og lokale tjenester. Det sparte
arbeidet knyttes primært til de lokale IKT-organisasjonene, men sekundært også til
grupper som lærere og forelesere, fordi de får disse spørsmålene direkte fra elever og
studenter. Det er usikkert hvor stort potensiale som ligger i gevinstområdet, fordi
utgangspunktet er at det er få henvendelser om brukerstøtte knyttet til Feide.
2%
3%
8%
9%
12%
14%
51%
Facebook/Twitter/annen social login
Google Directory
BankId
MinId
Azure AD
Lokal ADFS
Lokal Microsoft AD
Rapport
Side 6 av 157
• Potensielt bedret sikkerhet. Sikkerhetsgevinsten ligger i at lokale innloggingsløsninger i
enkelte tilfeller kan være mer avanserte enn Feides innloggingsløsning. På den motsatte
siden, har vi også argumenter for at sikkerheten kan bli forverret av en sammenkopling,
fordi man automatisk blir logget på tjenester man ikke nødvendigvis har intensjon om å
bruke.
• Bedret omdømme. Effekten antas å være på de enkelte vertsorganisasjonenes
omdømme. Den kommer som en følge av en bedre brukeropplevelse, og eventuelt
gjennom færre sikkerhetshendelser. Feides omdømme hos vertsorganisasjoner og
tjenesteleverandører kan påvirkes positivt.
• Økt handlingsrom. Gjennom større grad av delegering av funksjonalitet fra Feide til
vertsorganisasjonene, vil det bli større rom for innovasjon og lokale tilpasninger. Feide
vil dermed fortsatt være en relevant og foretrukket tjeneste for vertsorganisasjoner
med avanserte behov. I tillegg til å dekke disse organisasjonenes behov, vil dette også
være med på å unngå fragmentering.
Ut fra resultatet av spørreundersøkelsen, var oppfatningen fra vertsorganisasjonene at det
dominerende gevinstområdet var bedret brukeropplevelse. Dernest er det relativt jevnt
mellom effektivisering, bedret sikkerhet og bedret omdømme. Det siste gevinstområdet,
økt handlingsrom, ble ikke tatt inn i spørreundersøkelsen, men er fremmet av arbeids-
gruppens medlemmer.
Når det gjelder interesse for å ta i bruk nye løsninger for sammenkopling av Feide med
lokale innloggingsløsninger, var også dette et tema i spørreundersøkelsen. I analysen av
svarene, er det usikkerhet knyttet til de 61 % som ikke svarte. Det er antatt at disse har en
mer passiv holdning til behovet enn de som har svart, men det er vanskelig å vite i hvilken
grad. Det derfor er valgt å beregne et intervall, hvor den ene ytterkanten er scenarioet
hvor alle ikke-respondenter er negative, og andre ytterkanten er scenarioet hvor ikke-
respondentene har samme fordeling som de som svarte. Resultatet var:
• Mellom 8,9 % og 23,3 % av vertsorganisasjonene mener at det bør gis høy prioritet å
sammenkople klientinnlogging med Feide. Blant universiteter og fylkeskommuner er det
uttrykt et høyere behov for å sammenkople klientinnlogging med Feide enn hos øvrige
vertsorganisasjoner.
• Mellom 8,2 % og 21,2 % av vertsorganisasjonene mener at det bør gis høy prioritet å
sammenkople Feide og andre innloggingsløsninger.
Med hensyn til vilje og evne til å gjennomføre endringer, er det flere som uttrykker svak
investeringsvilje enn de som uttrykker sterk investeringsvilje. Dette gjelder både
investeringer som må gjøres lokalt hos vertsorganisasjonene og økninger i tilknytnings-
avgiften som følge av tiltak hos Feide sentralt.
Rapport
Side 7 av 157
Arbeidsgruppen har lagt ned et vesentlig arbeid i å kartlegge løsningsalternativer. De kan
kombineres og utfylle hverandre, og har større eller mindre relevans for ulike typer av
vertsorganisasjoner. Her er en overordnet beskrivelse av alternativene:
1. Mesh: En løsning hvor vertsorganisasjonen har sin egen innloggingstjeneste og stor
frihet i samhandlingen med tjenesteleverandørene. Den sentrale administrasjonen av
Feide reduseres i ytterste konsekvens til et standardiserings- og rapporteringsorgan.
Tre underalternativer er beskrevet, med ulik grad av sentral støtte. To av alternativene
innebærer at det etableres en klassisk mesh, mens et siste alternativ etablerer en
hybrid mesh, hvor Feide sentralt håndterer noe av kompleksiteten gjennom sentrale
støttesystemer. Mesh-alternativet vil løse behovene best, men har store konsekvenser
både sentralt og lokalt. Varianten med klassisk mesh vil ha uhåndterbare konsekvenser
både for tjenesteleverandører og vertsorganisasjoner. Dette vil eventuelt kunne
håndteres gjennom en hybrid mesh, men her er det nødvendig med mer utredning.
2. Proxy: Under denne arkitekturen delegeres selve autentiseringstjenesten til
vertsorganisasjonen, men Feide vil fortsatt håndtere det meste av kommunikasjonen
med tjenesteleverandørene. Denne løsningen gir større frihetsgrad for vertsorganisa-
sjonene til å tilby egne innloggingsbilder og -metoder, samt en sømløs overgang til
lokale tjenester. Den gir imidlertid noe mindre fleksibilitet enn mesh-alternativet.
Alternativet løser de fleste behovsområdene. Det har middels konsekvenser når det
gjelder kostnader, og vil medføre arbeid både for Feide sentralt og lokalt for de
institusjonene som velger å ta dette i bruk. Tjenesteleverandørene påvirkes. Merk at
det er en del policyavklaringer som må gjøres.
3. Kerberos: Dette alternativet løser samhandling med klientinnlogging basert på
Kerberos, for eksempel administrerte Windows PC-er. Det har middels konsekvenser for
kostnader.
4. Revers proxy for tjenester: Allerede i dag, er det mulig for vertsorganisasjoner å oppnå
sømløs pålogging ved å presentere sin lokale innloggingsløsning som en tjeneste i
Feide. Dette løser behovet med sammenkobling av Feide-tjenester med lokale
tjenester og skytjenester som Microsofts Azure AD og Googles økosystem. Det vil
imidlertid ikke kunne koble sammen klientinnlogging med Feide-innlogging i alle
situasjoner. Alternativet har lave konsekvenser når det gjelder kostnader, men har en
del implikasjoner for ansvarsforhold og policy som må håndteres.
5. Klientinnlogging med web-SSO: Også dette alternativet er delvis tilgjengelig i dag.
Dette gjelder klienter som bruker innlogging gjennom skyløsninger, og erstatter
Kerberos-alternativet for disse scenarioene. Teknologien fungerer i dag for klienter i
Googles økosystem. Vi ser tendensene også på Microsoft-siden, og dette er
forhåpentligvis på plass om få år. Alternativet har samme konsekvenser som forrige
alternativ.
Rapport
Side 8 av 157
Arbeidsgruppen anser det som viktig å videreutvikle Feide slik at det også i fremtiden er
utdanningssektorens foretrukne løsning for sikker identifisering. Strategisk og i forhold til
Feides omdømme, anbefaler arbeidsgruppen derfor å gå videre med arbeidet for
sammenkobling av Feide med lokale innloggingsløsninger.
Kartleggingsarbeidet har vist at vertsorganisasjonene i Feide kan deles inn i to grupper,
både i forhold til behov for endring og forutsetninger for å håndtere endringer. På den ene
siden, har vi organisasjoner som ønsker fleksibilitet og stor grad av lokale tilpasnings-
muligheter. Disse organisasjonene har høy teknisk kompetanse, og større økonomisk
spillerom. På den andre siden, har vi organisasjoner som ønsker enkelhet og forutsig-
barhet, samt størst mulig grad av sentralisering. Disse organisasjonene har mindre teknisk
kompetanse og lite økonomiske ressurser.
Arbeidsgruppen anbefaler følgende videre arbeid:
• Løsningsalternativ 4 Revers proxy for tjenester og løsningsalternativ 5 Klientinnlogging
med web-SSO, er i stor grad mulige å ta i bruk av vertsorganisasjonene allerede i dag.
Arbeidsgruppen anbefaler at disse alternativene videreutvikles. En stor del av dette vil
bestå i å utforme veiledningsmateriell og dokumentasjon, men det bør også settes av
ressurser til kartlegging og testing av nye muligheter. For eksempel, kan klienter i Azure
AD løse utfordringen med klientinnlogging mot Feide-innlogging. Det ligger potensielt
store gevinster i å utnytte de mulighetene som ligger i disse alternativene, og dersom
UNINETT og Senter for IKT i utdanningen samtidig bruker ressurser på videre testing av
fremtidige muligheter vil dette komme sektoren til gode. I tillegg til veiledning og
testing, bør det vurderes å utarbeide og gjennomføre kurs i å utnytte de muligheter som
ligger i alternativ 4 og 5. Arbeid med veiledning og kurs kan i tillegg bringe oss nærmere
behovshavere, og gjennom det spisse en kravspesifikasjon for videre arbeid.
• Løsningsalternativ 2 Proxy, vil dekke mange av de mer avanserte organisasjonenes
behov, og arbeidsgruppen anbefaler at dette alternativet videreføres. Det bør opprettes
en arbeidsgruppe som spesifiserer nærmere hvordan dette implementeres. Herunder
inngår hvilke endringer dette vil ha for policy, ansvarsforhold, økonomi og finansiering.
På et senere tidspunkt, kan det vurderes om man skal gå videre fra proxy-alternativet, og
etablere en hybrid mesh-arkitektur. Her er det en del usikkerheter som må avklares i
forhold til hvordan en backend-mesh mot vertsorganisasjonene kan settes opp.
Kerberos-alternativet bør ikke tas videre: sammenkopling med klientinnlogging er bedre og
mer brukervennlig dekket av andre løsningsalternativer.
Rapport
Side 9 av 157
Innhold
1 Innledning....................................................................................... 11
1.1 Bakgrunn .......................................................................................... 11
1.2 Metode og aktiviteter .......................................................................... 12
1.3 Dokumentreferanser ............................................................................ 12
1.4 Begrepsliste ...................................................................................... 13
2 Informasjonsinnhenting ...................................................................... 17
2.1 Innledning ........................................................................................ 17
2.2 Dokumenter ...................................................................................... 17
2.3 Spørreundersøkelse sendt til vertsorganisasjonene ....................................... 19
2.4 Arbeidsgruppen .................................................................................. 22
3 Løsningsalternativer .......................................................................... 26
3.1 Oppsummering ................................................................................... 26
3.2 Diskusjon ......................................................................................... 27
4 Gevinster ........................................................................................ 30
4.1 Innledning ........................................................................................ 30
4.2 Gevinsttyper ..................................................................................... 30
4.3 Beskrivelse av gevinster ........................................................................ 32
4.4 Gevinst: bedret brukeropplevelse ............................................................ 32
4.5 Gevinst: mindre behov for brukerstøtte .................................................... 34
4.6 Gevinst: potensielt bedret sikkerhet ........................................................ 35
4.7 Gevinst: bedret omdømme .................................................................... 36
4.8 Gevinst: økt handlingsrom ..................................................................... 37
5 Diskusjon ........................................................................................ 39
5.1 Innledning ........................................................................................ 39
5.2 Behov .............................................................................................. 39
5.3 Brukstilfeller ..................................................................................... 40
5.4 Muligheter ........................................................................................ 43
5.5 Kostnader, ansvarsforhold og policy ......................................................... 45
5.6 Gevinster ......................................................................................... 46
5.7 Interesse .......................................................................................... 47
5.8 Andre forhold .................................................................................... 48
6 Anbefaling ...................................................................................... 49
Rapport
Side 10 av 157
Vedlegg 1: Resultater fra spørreundersøkelsen ................................................. 51
V.1.1 Innledning ........................................................................................ 51
V.1.2 Utforming ......................................................................................... 51
V.1.3 Distribusjon ...................................................................................... 52
V.1.4 Svarprosent....................................................................................... 52
V.1.5 Feilmarginer ..................................................................................... 54
V.1.6 Funn: behov for sammenkopling av klientinnlogging med Feide ........................ 56
V.1.7 Funn: behov for sammenkopling av Feide og andre innloggingsløsninger ............. 61
V.1.8 Funn: andre scenarioer ........................................................................ 65
V.1.9 Funn: type utstyr ................................................................................ 66
V.1.10 Funn: lokal katalog for klientinnlogging for ansatte ...................................... 68
V.1.11 Funn: type lokale innloggingsløsninger ...................................................... 69
V.1.12 Funn: gevinster .................................................................................. 70
V.1.13 Funn: finansiering og gjennomføringskapasitet ............................................ 72
V.1.14 Funn: andre tilbakemeldinger ................................................................ 75
Vedlegg 2: Spørsmålene i spørreundersøkelsen ................................................. 76
Vedlegg 3: Svar på spørsmål om andre scenarioer.............................................. 87
Vedlegg 4: Svar på spørsmål om andre tilbakemeldinger ..................................... 89
Vedlegg 5: Løsningsalternativer .................................................................... 91
V.5.1 Dagens føderasjon .............................................................................. 91
V.5.2 Alternativ 1: Mesh............................................................................... 99
V.5.3 Alternativ 2: Proxy ............................................................................ 113
V.5.4 Alternativ 3: Kerberos ........................................................................ 125
V.5.5 Alternativ 4: Revers proxy for tjenester .................................................. 138
V.5.6 Alternativ 5: Klientinnlogging med web-SSO ............................................. 148
Rapport
Side 11 av 157
1 Innledning
1.1 Bakgrunn
Med bakgrunn i formelle og uformelle henvendelser fra grunnopplæringen og høyere
utdanning, etablerte UNINETT sommeren 2017 en arbeidsgruppe som skulle kartlegge
behov for sammenkopling av Feide og lokale innloggingsløsninger. Invitasjon til deltakelse i
arbeidsgruppen gikk ut til vertsorganisasjoner i Feide gjennom omtale på UNINETTs
nettsider og fagdager, gjennom prioriteringsrådet for Feide i grunnopplæringen,
prioriteringsrådet for mellomvare i høyere utdanning, samt direkte fra UNINETT og Senter
for IKT i utdanningen.
De formelle henvendelsene har kommet fra prioriteringsrådet for Feide i
grunnopplæringen, samt prioriteringsrådet for mellomvare i høyere utdanning. Fra
prioriteringsrådet for Feide i grunnopplæringen kom henvendelsen i mars 2015, med
følgende bakgrunn og forslag til innstilling:
• Bakgrunn: Fylkeskommunene har mange brukere som ikke hører til skole og som dermed
ikke har Feide-konto. De har også applikasjoner som ikke hører til skole og som dermed
ikke er Feide-tilpasset. Dette har ført til at fylkeskommunene har etablert lokale SSO-
løsninger for å kunne tilby SSO for alle sine brukere. Dette fører igjen til at vi sitter
med to SSO-løsninger som ikke snakker sammen.
• Forslag på innstilling til Samarbeidsrådet for Feide: Prioriteringsrådet for
grunnopplæringen ønsker at Samarbeidsrådet nedsetter en gruppe som kan kartlegge
løsninger på denne problemstillingen. Prioriteringsrådet bidrar gjerne inn i dette
arbeidet. Prioriteringsrådet for grunnopplæringen ønsker at Samarbeidsrådet prioriterer
å finne en løsning på utfordringen med sameksistens mellom lokal SSO og Feide.
Prioriteringsrådet for mellomvare i høyere utdanning kom med følgende innspill i mars
2017:
• Universitetet i Oslo (UiO) har i dag lokal autentisering på web for å ivareta behov som i
dag ikke dekkes av Feide. Hovedgrunnen til at UiO har sin egen autentiseringstjeneste
er at sammenknytning mellom lokal SSO og nasjonal SSO mangler i Feide.
Prioriteringsrådet mener at en slik løsning vil gi en vesentlig forenkling av sluttbrukerne
sin hverdag, og ber UNINETT prioritere og intensivere dette arbeidet.
Rapport
Side 12 av 157
Arbeidsgruppen for behovskartleggingen ble gitt følgende mandat:
• Innhente faktiske behov fra ulike brukergrupper i sektoren.
• Kartlegge brukstilfeller.
• Kartlegge interesse for å ta i bruk en slik integrasjon på kort/lengre sikt.
• Kartlegge administrative og tekniske muligheter og utfordringer.
• Kartlegge gevinster og kostnader.
• Kartlegge hvilke konsekvenser etterspurte endringer kan komme til å få for policy,
ansvarsforhold og økonomi.
Basert på kartleggingen, skulle gruppen komme med en velbegrunnet anbefaling på om det
bør gjøres et videre arbeid på området. Dette dokumentet oppsummerer resultatene fra
arbeidsgruppen og dens anbefaling.
1.2 Metode og aktiviteter
Leveransen er utformet gjennom følgende aktiviteter:
• Informasjonsinnhenting gjennom brukerundersøkelse, møter i arbeidsgruppen, online
skjema for innspill til gevinster og kostnader og dokumentasjon.
• Sammenstilling og analyse av innhentet informasjon.
• Vurdering av løsningsalternativer opp mot uttrykte behov, mulige gevinster og
konsekvenser for kostnader, policy og ansvarsforhold.
• Gjennomgang av analyse og anbefalinger i arbeidsgruppen.
• Utrapportering gjennom denne rapporten og presentasjon i samarbeidsrådet for Feide.
1.3 Dokumentreferanser
Dokumenttittel Dato
Generell Feide-arkitektur 2008-11
Feides systemarkitektur 2011-01
Veileder: gevinstrealisering, DFØ 2014-10
Rapport
Side 13 av 157
1.4 Begrepsliste
Active Directory (AD) Microsofts programvare for å organisere, administrere og
kontrollere brukere, ressurser (printere, maskiner) og tilhørende
rettigheter. Den brukes både til autentisering og autorisering. AD
installeres og brukes internt for en organisasjon. Microsoft tilbyr
også AD som en skytjeneste: Azure AD. AD støtter LDAP og
Kerberos. Den brukes også som lokal domenekontroller og utfører
tjenester som utdeling av IP-adresser, distribusjon av
programvareoppdateringer til klienter og lignende.
Active Directory
Federation Services
(ADFS)
Microsofts programvare for å håndtere føderering og SSO på tvers
av virksomheter. Den støtter blant annet SAML-protokollen.
Attribute release
policy
Kontrakt som beskriver og håndhever hvilke attributter/infor-
masjonselementer som kan overføres fra en vertsorganisasjon til
en tjeneste ved innlogging.
Attributt En egenskap som kan assosieres med et objekt, for eksempel
etternavnet til en person. Attributtet er identifisert ved et
attributtnavn, og har en attributtverdi for hvert objekt. Et
attributt kan være obligatorisk eller valgfri for en gitt klasse
objekter, for eksempel er etternavn obligatorisk for en person,
mens mellomnavn er valgfritt. Det kan være tillatt med flere
verdier av et attributt for samme objekt, for eksempel kan en
person ha flere fornavn. Attributtverdien kan være sammensatt,
for eksempel kan en adresse bestå av gatenavn, husnummer,
postnummer og sted. Attributtnavn, tillatte verdier, om verdien
kan repeteres osv. spesifiseres i et skjema.
Autentisering Å bekrefte at en person er den vedkommende utgir seg for å
være. En vanlig metode er kontroll av brukernavn med
tilhørende passord, som i Feide. Andre metoder kan være basert
på for eksempel engangspassord, digitale sertifikater eller
fingeravtrykklesere.
Rapport
Side 14 av 157
Autentiseringspunkt I Feide: tjeneste som verifiserer at autentiseringsfaktorene som
benyttes er korrekte for brukeren som logger inn. Typisk vil
dette være en sjekk av at kombinasjonen brukernavn og passord
er korrekt, men kan også knyttes til andre
autentiseringsfaktorer.
Autorisasjon Den adgang en bruker har til informasjon eller tjenester hos en
tjenestetilbyder. “Å autorisere” brukes både om å tildele en
bruker adgang, og om å identifisere en brukers adgangs-
rettigheter. Autorisering forutsetter normalt at brukeren er
autentisert. Feide tilbyr autentisering, men overlater til
tjenestene å gjøre autorisering basert på denne autentiseringen.
Identitetstjeneste Feides tjeneste for å levere informasjon om vilkårlig Feide-
bruker til en tjenesteleverandør. Dette kan avlaste tjenesten for
å selv administrere informasjon knyttet til den enkelte bruker.
Feide realiserer identitetstjenesten ved å innhente data fra en
LDAP-katalog hos vertsorganisasjonen brukeren tilhører. Feide
har egen kontrakt med hver enkelt tjeneste om hvilke attributter
tjenesten skal få tilgang til. Denne informasjonen utleveres fra
Feides innloggingsløsning, Moria, ved vellykket innlogging
(autentisering).
Identity Provider (IdP) Tjeneste som tilbyr autentisering og identitetsinformasjon til
andre tjenester.
Innloggingstjeneste Tjeneste som tilbyr innlogging for sluttbrukere som kan
gjenbrukes av andre tjenester. I Feide, og andre SAML2-
føderasjoner, realisert med en Identity Provider (IdP)
Kerberos En autentiseringsprotokoll mye brukt mellom klienter og servere,
for eksempel mellom et Active Directory og klientene koblet til
dette.
Kryssføderering Sammenkobling av Feide med annen autentiseringstjeneste.
Tilbyr Feide-brukere tilgang til tjenester fra andre føderasjoner
eller tilbyr brukere fra andre føderasjoner tilgang til
fellestjenester.
Rapport
Side 15 av 157
LDAP Forkortelse for: Lightweight Directory Access Protocol.
Katalogsystem for registrering av og tilgang til vilkårlig
informasjon om personer, institusjoner, fysiske objekter osv. Kan
også brukes for eksempel for lagring av brukerens passord. Data i
en LDAP-katalog er beskrevet i et skjema som definerer hvilken
informasjon som blir lagret i katalogen. LDAP er protokollen som
brukes for å registrere eller hente informasjon i katalogen.
OAuth En protokoll for å gi kontrollert tilgang til ressurser.
OpenID, OpenID
Connect
En protokoll for autentisering av brukere. Ofte brukt sammen
med OAuth. I dag benyttes OpenID Connect/OAuth 2.0 mye på
forbrukertjenester, mens SAML2 er mer virksomhetsorientert.
SAML Forkortelse for: Security Assertion Markup Language. En standard
utviklet av OASIS for utveksling av informasjon som angår
brukerens identitet og andre attributter mellom en
autentiseringstjener og en tjenesteleverandør. SAML 2.0
benyttes i Feide.
Service Provider (SP) Sluttbrukertjeneste i en SAML2-føderasjon som benytter
føderasjonens innloggingstjeneste(r) for autentisering og
uthenting av informasjon om brukere.
Single sign-on (SSO) En innlogging som lar en bruker få benytte flere uavhengige
tjenester, som alle krever autentisering, uten å behøve å gå
gjennom en eksplisitt autentiseringsprosedyre for hver tjeneste
så lenge en tiltrodd autentiseringstjeneste som Feide eller
tilsvarende kan verifisere brukerens autentisitet.
Tjenesteleverandør En organisasjon som yter tjenester til personer i
utdanningssektoren, og benytter Feide for autentisering. En
tjenesteleverandør må ha en avtale med Feide, og er derfor en
Feide-organisasjon (som også kan opptre som vertsorganisasjon
for Feide-brukere).
Rapport
Side 16 av 157
Vertsorganisasjon Utdanningsorganisasjon som har tatt i bruk Feide og tildelt
Feide-navn til sine elever, studenter, ansatte og andre
tilknyttede personer. En gitt institusjon kan opptre både som
vertsorganisasjon og som tjenesteleverandør; for eksempel kan
et universitet både være vertsorganisasjon for sine studenter, og
samtidig tilby elektroniske læringsressurser til studentene. I
Feide behandles disse to funksjonene uavhengig av hverandre,
også når samme institusjon tilbyr begge funksjoner.
Rapport
Side 17 av 157
2 Informasjonsinnhenting
2.1 Innledning
Evalueringen bygger på følgende informasjonskilder:
• Dokumentasjon som oppfattes som førende for hvordan Feide-føderasjonen styres og
opereres.
• En brukerundersøkelse sendt til alle vertsorganisasjoner hvor vi fikk 193 svar.
• Innspill fra en arbeidsgruppe bestående av representanter fra ulike typer
vertsorganisjoner (Universitetet i Oslo, NTNU, Nord universitet, IKT Agder, BIBSYS, Oslo
kommune), UNINETT og en rådgiver fra konsulentselskapet Fundator.
De følgende delkapitlene gjengir funn og konklusjoner som arbeidsgruppen har trukket ut
fra disse kildene.
2.2 Dokumenter
2.2.1 Samarbeidsrådet for Feide
Feides besluttende organ er Samarbeidsrådet. Samarbeidsrådet skal besta av minst fire
medlemmer fra UNINETT og Senter for IKT i utdanningen, med minst to medlemmer fra
hver av de to samarbeidspartnerne. Medlemmene utpekes for to år av gangen.
Kunnskapsdepartementet kan utnevne observatører.
Gjennom Samarbeidsrådet for Feide skal partene opprettholde Feide som en trygg og
enhetlig løsning for sikker identifisering for sektoren og ivareta det nødvendige langsiktige
perspektivet. Rådets mål er a sikre visjon, stabilitet, internasjonal harmonisering og
forutsigbarhet for Feide-arbeidet. Rådet har ansvar for framdrift og styring av aktiviteten i
Feide. Dette inkluderer blant annet:
• Utarbeidelse av strategi for Feide
• Utarbeidelse av overordnet policy for Feide
• Regelmessig økonomioppfølging
Rapport
Side 18 av 157
• Samarbeidsrelasjoner med tilsvarende aktivitet i og utenfor offentlig sektor, nasjonalt
og internasjonalt
• Rammer for aktiviteter innenfor forskning og utvikling (FoU) og drift
2.2.2 Prioriteringsråd
UNINETTs prioriteringsråd for mellomvare i universitets- og høgskolesektoren og
prioriteringsrådet for Feide i grunnopplæringen er begge forslagsfremmende og rådgivende
overfor det besluttende Feide samarbeidsråd.
2.2.3 Høringer i Feide
Høringsrunder i Feide bør prinsipielt foretas som åpne høringer etter følgende mal:
1. Endringsforslag/dokument utformes
2. Forslag som skal ut på høring må først vedtas i samarbeidsrådet. (De to nevnte
prioriteringsrådene vil gjennom innkallingspapirer og saksgrunnlag gjøres kjent med at
ny høring vil komme.)
3. Selve høringen gjennomføres ved:
• Annonsering på websider
• Utsending til berettigede (hos både vertsorganisasjoner og tjenesteleverandører)
• Høringslister som er åpne for interesserte å melde seg på
• Utsending til prioriteringsråd
4. Det forventes svar fra prioriteringsrådene, og gis totalt en minimumsperiode på 30
dager for innmelding av høringssvar (gjelder alle).
Dersom det ikke kommer inn svar på høringen, og prioriteringsrådene støtter forslaget som
er ute på høring, er endring/dokument direkte godkjent.
Rapport
Side 19 av 157
Dersom høringssvar framkommer må:
1. Svar sammenstilles av Feide
2. Prioriteringsrådene gis 14 dager på å gi en uttalelse på kommentarer som framkommer
3. Bearbeide nytt forslag, basert på tilbakemeldinger
4. Gjennomføre nytt vedtak i Feide Samarbeidsråd (godkjenne, avvise eller resultere i ny
høringsrunde)
Resultatet av denne prosessen annonseres på web og i aktuelle e-postlister.
2.3 Spørreundersøkelse sendt til vertsorganisasjonene
2.3.1 Hensikt, utsendelse og svarprosent
For å kartlegge bredden i behovene ble det sendt ut en spørreundersøkelse til
vertsorganisasjonene. Den inneholdt to konkrete scenarioer og spørsmål om hvilke
løsninger som var i bruk for klientinnlogging og tjenesteinnlogging. Videre testet den ut
kostnadssensitivitet og lokal gjennomføringsevne.
Brukerundersøkelsen ble sendt ut til e-postlistene for administratorer (1262 mottakere) og
tekniske kontakter (565 mottakere) for alle vertsorganisasjoner i Feide-føderasjonen. Det
er noe overlapp mellom listene.
Vi fikk 193 svar på spørreundersøkelsen, og svarene representerer 39 % av de 503
vertsorganisasjonene i Feide. Grafen under viser oppsummert svarprosent per
organisasjonstype:
Rapport
Side 20 av 157
Et sentralt spørsmål er hvorvidt svarene fra disse 39 % er representative for de øvrige 61 %.
I utgangspunktet er svarprosenten god nok dersom man kunne antatt at meningene blant
de som svarte er de samme som de som ikke svarte, men for noen av spørsmålene er det
grunn til å anta at de som ikke svarte har en mer passiv holdning til behovene for
sammenkopling enn de som tok seg bryet å svare.
2.3.2 Oppsummering av funn
Mellom 8,9 % og 23,3 % av vertsorganisasjonene mener at det bør gis høy prioritet å
sammenkople klientinnlogging med Feide. Blant universiteter og fylkeskommuner er det
uttrykt et høyere behov for å sammenkople klientinnlogging med Feide enn hos øvrige
vertsorganisasjoner.
Mellom 8,2 % og 21,2 % av vertsorganisasjonene mener at det bør gis høy prioritet å
sammenkople Feide og andre innloggingsløsninger.
Vi ser at administrerte Windows-PC-er dominerer. Det er imidlertid også en vesentlig
mengde utstyr av andre typer, og det er mye utstyr som ikke er administrert.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
UniversitetFylkeskom
muneAnnen Høgskole Kommune
Privatskoleeier
Totalt
Svarprosent 82% 61% 54% 39% 37% 36% 39%
Rapport
Side 21 av 157
Lokal katalog for klientinnlogging:
Type lokale innloggingsløsninger:
3%
4%
17%
76%
Google Directory med kopling mot Feide
Google Directory
Azure AD
Lokal Microsoft AD
2%
3%
8%
9%
12%
14%
51%
Facebook/Twitter/annen social login
Google Directory
BankId
MinId
Azure AD
Lokal ADFS
Lokal Microsoft AD
Rapport
Side 22 av 157
Det dominerende gevinstområdet for begge scenarioer er bedret brukeropplevelse. Dernest
er det relativt jevnt mellom effektivisering, bedret sikkerhet og bedret omdømme. Det er
få vertsorganisasjoner som avviser at det er gevinster knyttet til sammenkopling av Feide
med lokale innloggingsløsninger.
Det er flere som uttrykker svak investeringsvilje enn de som uttrykker sterk
investeringsvilje. Videre er det ingenting som tyder på at investeringsviljen har
sammenheng med prioriteringen av behovet for sammenkopling av Feide med lokale
innloggingsløsninger
2.4 Arbeidsgruppen
2.4.1 Hensikt
Hensikten med arbeidet i gruppen var å:
• Innhente faktiske behov fra ulike brukergrupper i sektoren.
• Kartlegge brukstilfeller.
• Kartlegge interesse for å ta i bruk en slik integrasjon på kort/lengre sikt.
• Kartlegge administrative og tekniske muligheter og utfordringer.
• Kartlegge gevinster og kostnader.
• Kartlegge hvilke konsekvenser etterspurte endringer kan komme til å få for policy,
ansvarsforhold og økonomi.
2.4.2 Sammensetning
Arbeidsgruppen som ledet utarbeidelsen av behovskartleggingen ble satt sammen av
personer som representerte de ulike typene av vertsorganisasjoner i Feide-føderasjonen,
samt sentrale personer fra UNINETT med både administrativ og teknisk bakgrunn. I tillegg
ble det hentet inn en ekstern rådgiver fra konsulentselskapet Fundator i rollen som
prosessleder.
Følgende personer var en del av arbeidsgruppen ved avslutningen av arbeidet:
• Mathias Meisfjordskar, Universitetet i Oslo
• Kent Overholdt, NTNU
Rapport
Side 23 av 157
• Arne Grevskott, Nord universitet
• Karl Magnus Storfjord, IKT Agder
• Per Hovde, BIBSYS
• Bernt Rygg, Oslo kommune
• Lars Kviteng, UNINETT
• Snorre Løvås, UNINETT
• Annette Grande Furset, UNINETT
• Jørgen Longva, Fundator
2.4.3 Arbeidsform
Arbeidsgruppen gjennomførte tre møter:
• Arbeidsmøte 1, Hell, 28. august 2017: Informasjonsutveksling
o UNINETT presenterte overordnede løsningsscenarioer
o Institusjonene presenterte behov
o UNINETT delte ut noen hjemmeoppgaver til vertsorganisasjonene knyttet til
nærmere beskrivelse av behov, gevinster og kostnader
o UNINETT presenterte utkast til spørreundersøkelse
• Arbeidsmøte 2, Værnes, 19. oktober 2017: Utforming av anbefalinger
o UNINETT presenterte resultatene fra spørreundersøkelsen
o UNINETT presenterte utkast til sluttrapport
o Detaljering av gevinster
o Diskusjon om anbefalinger
• Arbeidsmøte 3, videomøte, 7. november 2017: Ferdigstille anbefalinger
o UNINETT presenterte utkast av sluttrapporten
o Diskusjon om justeringer til sluttrapporten
UNINETTs deltakere gjennomførte ukentlige statusmøter, noen ganger oftere, for å
diskutere funn, koordinere planlegging av arbeidsmøter, fremdrift på dokumentproduksjon
og avstemme at gruppens arbeid var i tråd med arbeidsgruppens mandat.
Rapport
Side 24 av 157
2.4.4 Oppsummering fra arbeidsmøtene
Arbeidsmøte 1, 28. august 2017:
• Diskusjonen avdekker at det er et stort spenn i behovene mellom de ulike typene
organisasjoner, slik som store universiteter, mindre universiteter og høyskoler,
fylkeskommuner og kommuner. I tillegg kommer behovene til BIBSYS som er spesielle,
fordi de i denne sammenheng representerer et konsortium på 90 biblioteker.
• Arbeidsgruppen er samlet om at man må videreføre Feides suksess som en standardisert
løsning både for tjenesteleverandører og vertsorganisasjoner.
• Det ble tidlig klart at temaet er aktuelt, og at det representerer en reell
problemstilling som ønskes løst. Samtidig ble det klart at det ikke gis høyeste prioritet.
Dette er i tråd med funnene fra spørreundersøkelsen.
• Universitetet i Oslo (UiO) fremmet et forslag om et modularisert Feide: en arkitektur
hvor man balanserer fordelene ved dagens sentraliserte modell, med fleksibilitet til å
støtte mer avansert funksjonalitet for de organisasjonene som ønsker (og håndterer)
det. Spesielt er det ønske om at Feide kan fremstå som en mesh for tjeneste-
leverandører og at det tillates mer transparens og kontekst i dialogen mellom
vertsorganisasjon og tjenesteleverandør. UNINETT og UiO har hatt oppfølgingsmøter for
å sikre at disse forslagene har blitt ivaretatt i beskrivelsene og anbefalingene i denne
rapporten. Se blant annet omtalen av front-mesh og migrasjonsveien fra proxy-
arkitektur til dobbelt mesh-arkitektur, i kapitlet om mulige løsningsalternativer.
• Arbeidsgruppen ble utfordret til å beskrive gevinster og kostnader knyttet til
sammenkopling av Feide og lokale innloggingsløsninger. Det ble raskt identifisert
gevinster som ble beskrevet på overordnet nivå, men det viste seg vanskelig å fylle ut
flere detaljer. Dette bør være et fokusområde i det videre arbeidet med gjennomføring
av valgte løsningsalternativer.
Arbeidsmøte 2, 19. oktober 2017:
• Gjennom fleksibel/modulær delegering av funksjonalitet fra Feide sentralt til lokale
løsninger hos vertsorganisasjonene, vil man oppnå et større handlingsrom for
innovasjon og lokale tilpasninger. Dette er et eget gevinstområde. Realiseringen av
dette må ikke gå på bekostning av Feides nåværende suksess som en løsning som er
enkel å ta i bruk, har stor utbredelse og er kostnadseffektiv for de verts-
organisasjonene som ikke har behov utover standard funksjonalitet.
• Arbeidsgruppen har gått langt i å beskrive ulike løsningsalternativer. Det er nødvendig
å oppsummere disse i forhold til behov, kostnader og konsekvenser slik at det blir mulig
for beslutningstakere å forstå de strategiske konsekvensene av ulike veivalg.
Rapport
Side 25 av 157
• I det videre arbeidet med anbefalinger, er det et skille mellom behovene hos
vertsorganisasjoner som har standard behov og liten kapasitet til å gjøre lokale
tilpasninger kontra de som har en større portefølje av tjenester og en stor vilje og evne
til å utvikle avanserte løsninger. For den første gruppen må Feide gå foran i å utvikle
de sentrale løsningene, mens den andre gruppen har behov for større grad av
delegering av funksjonalitet og ansvar.
Arbeidsmøte 3, 7. november 2017:
• Flere detaljer bør flyttes til vedlegg, spesielt oppsummeringen av spørreundersøkelsen.
• Alternativ 1 endrer navn fra «full mesh» til «mesh». Det må fremgå tydelig at det her
ligger to underalternativer: en klassisk mesh hvor det er direkte kopling mellom
vertsorganisasjoner og tjenesteleverandører, og en hybrid mesh hvor Feide sentralt
simulerer mesh-arkitektur både mot tjenesteleverandører (front-mesh) og verts-
organisasjoner (backend-mesh). Det må fremgå at hybrid mesh er et mer aktuelt
alternativ enn en klassisk mesh.
• I tillegg kom det en del andre kommentarer på mer detaljert nivå, som er innarbeidet i
sluttrapporten.
Rapport
Side 26 av 157
3 Løsningsalternativer
3.1 Oppsummering
Arbeidsgruppen har beskrevet fem mulige løsningsalternativer for sammenkopling av Feide
med lokale innloggingsløsninger. Kanskje kunne ordet løsningselementer vært mer
beskrivende, for det understrekes at alternativene ikke er gjensidig utelukkende. Tvert
imot er det høyst sannsynlig at den beste løsningen vil bestå av kombinasjoner av de ulike
løsningsalternativene. Videre vil de aktuelle kombinasjonene av løsninger ikke være like
for alle vertsorganisasjoner. De fem alternativene er:
1. Mesh: En løsning hvor vertsorganisasjonen har sin egen innloggingstjeneste og stor
frihet i samhandlingen med tjenesteleverandørene. Den sentrale administrasjonen
reduseres i ytterste konsekvens til et standardiserings- og rapporteringsorgan. Tre
underalternativer er beskrevet, med ulik grad av sentral støtte. To av alternativene
innebærer at det etableres en klassisk mesh, mens et siste alternativ etablerer en
hybrid mesh hvor Feide sentralt håndterer noe av kompleksiteten gjennom sentrale
støttesystemer.
2. Proxy: Under denne arkitekturen delegeres selve autentiseringstjenesten til
vertsorganisasjonen, men Feide vil fortsatt håndtere det meste av kommunikasjonen
med tjenesteleverandørene. Denne løsningen gir større frihetsgrad for
vertsorganisasjonene til å tilby egne innloggingsbilder og -metoder, samt en sømløs
overgang til lokale tjenester. Den gir noe mindre frihet enn mesh-alternativet.
3. Kerberos: Dette alternativet løser samhandling med klientinnlogging basert på
Kerberos, for eksempel administrerte Windows PC-er.
4. Revers proxy for tjenester: Allerede i dag, er det mulig for vertsorganisasjoner å oppnå
sømløs pålogging, ved å presentere sin lokale innloggingsløsning som en tjeneste i
Feide. Dette løser behovet med sammenkobling av Feide-tjenester med lokale
tjenester og skytjenester som Microsofts Azure AD og Googles økosystem. Det vil
imidlertid ikke kunne koble sammen klientinnlogging med Feide-innlogging i alle
situasjoner.
5. Klientinnlogging med web-SSO: Alternativet er allerede delvis tilgjengelig i dag og
gjelder klienter som bruker innlogging gjennom skyløsninger, og erstatter Kerberos-
alternativet for disse scenarioene. Teknologien fungerer i dag for klienter i Googles
økosystem. Vi ser tendensene også på Microsoft-siden, og dette er forhåpentligvis på
plass om få år.
Rapport
Side 27 av 157
I vedlegg 5 er det laget en beskrivelse av dagens føderasjon og hvert løsningsalternativ.
Hvert alternativ er presentert med tekniske sammenkoplinger, eksempler på innloggings-
flyter, hvordan vi ser for oss at en slik løsning vil påvirke kostnader og fordeling av
oppgaver, sentralt i UNINETT og lokalt hos vertsorganisasjonene.
Vi har identifisert syv kostnadsområder, og for hvert av disse har vi en kort, overordnet
tekstlig beskrivelse samt en tabell som detaljerer bildet. De syv kostnadsområdene er:
• Føderasjonen som helhet, tillitsnettverk og policy
• Support til sluttbrukere og aktører i føderasjonen
• Datakvalitet ved vertsorganisasjon
• Innloggingstjeneste for web
• Sterk autentisering av brukere
• Statistikk til vertsorganisasjoner, tjenesteleverandører og føderasjonen som helhet
• Funksjonalitet dagens føderasjon gir til Dataporten
For å komplettere implikasjonene, har vi også overordnet beskrevet hvordan vi ser for oss
at en slik løsning vil påvirke kontrakter og ansvarsforhold, policyer rundt informasjons-
modell samt betalingsmodell.
Kostnader og påvirkning på policyer er tett knyttet til de ulike løsningsalternativene.
Tilsvarende gjelder ikke for de mulige gevinstene. Disse er derfor beskrevet i et eget
hovedkapittel på tvers av løsningsalternativene.
3.2 Diskusjon
For vertsorganisasjoner og tjenester som ikke har et ønske om – eller evne til å
gjennomføre - større endringer, kan man oppnå mye gjennom en bedre utnyttelse av
dagens løsninger. Mange av ønskene som har kommet frem, vil dekkes gjennom en
kombinasjon av alternativ 4 Revers proxy for tjenester, og 5 Klientinnlogging med web-
SSO, som bygger på funksjonalitet som allerede er tilgjengelig i Feide. Aktualiteten og
nytten av disse alternativene forsterkes også av den økte bruken av skytjenester koblet til
Microsofts og Googles skyøkosystemer og dermed færre lokale tjenester hos mange.
Det viktigste behovet som ikke kan dekkes med alternativ 4 Revers proxy for tjenester og 5
Klientinnlogging med web-SSO, er sømløs innlogging for klienter som er knyttet til et lokalt
domene. For denne funksjonaliteten må føderasjonen over på alternativ 3 Kerberos, eller
de to alternativene som kopler Feide mot en lokal IdP: alternativ 2 Proxy, eller alternativ
1 Mesh.
Rapport
Side 28 av 157
Kerberos-alternativet er hovedsakelig en spesialløsning for vertsorganisasjoner med
klienter i et Microsoft AD. Det finnes andre Kerberos-løsninger, men i all hovedsak er det
her snakk om å la brukeren gjenbruke innloggingen på klienten i et AD også mot Feide-
føderasjonen. Det er uavklart hvordan sterk autentisering vil fungere i dette alternativet,
noe som må utforskes videre før en eventuell implementering. Resten av føderasjonen vil
fungere som i dag.
I alternativ 2 Proxy, flyttes innloggingsfunksjonalitet fra den sentrale innloggingstjenesten
over til lokale innloggingstjenester ved de vertsorganisasjonene som ønsker det. Med en
lokal innloggingsløsning, vil vertsorganisasjonen kunne knytte sammen lokale tjenester og
klientinnlogging mot AD inn i samme single sign-on domene som Feide. Feide-føderasjonen
vil fremstå som én tjeneste i den lokale føderasjonen. Vertsorganisasjonen vil kunne tilby
forskjellige metoder for sterk autentisering etter lokale behov. For de vertsorganisa-
sjonene som ikke ønsker en lokal innloggingstjeneste, vil de kunne fortsette som i dag.
Behovet for å støtte tjenester som forventer mesh-arkitektur, gjerne internasjonale
tjenester og skytjenester, kan løses uten å etablere en klassisk mesh. Dette gjøres ved å la
Feide fremstå som en mesh for tjenesteleverandørene, på «fremsiden». Vi kaller denne
teknikken for front-mesh. Konsekvensen er at dette kravet også kan løses for de øvrige
løsningsalternativene. Feide har allerede i dag et pilotsystem for front-mesh som kan
benyttes. Fokuset i piloten har vært å støtte Microsofts skyøkosystem gjennom Azure AD,
men er tenkt utvidet til alle tjenester. Dette støttesystemet kan med videreutvikling
støtte alle tjenester og gjøre det relativt enkelt for vertsorganisasjoner å ta disse i bruk.
Dette har vært planlagt som en videreutvikling uavhengig av arbeidet med å se på en
sammenkobling mot lokal SSO.
Med den varianten av alternativ 1 Mesh hvor man realiserer en klassisk mesh med få
sentrale støttesystemer, bryter man sterkt med dagens føderasjon. Sannsynligvis kan de
som ikke ønsker en lokal innloggingstjeneste kunne fortsette som i dag med dagens
sentrale innloggingstjeneste som en av mange innloggingstjenester i en mesh. Tjenester på
den andre siden vil sannsynligvis bli berørt enten de ønsker det eller ikke. De må tilpasse
seg en mesh-arkitektur der vertsorganisasjoner har forskjellige innloggingstjenester. Noen
er på felles innloggingstjenester som dagens sentrale og kanskje noen nye samarbeid, mens
andre er på egne innloggingstjenester. Det kan bygges noen nye støttesystemer som kan
hjelpe tjenester noe, for eksempel en tjeneste for organisasjonsvalg som kan brukes av
tjenester som ønsker det.
Den andre varianten av alternativ 1 Mesh hvor man etablerer en hybrid mesh, kan ses på
som en videreutvikling av proxy-alternativet. For tjenesteleverandørene vil føderasjonen
fremstå som en mesh ved hjelp av en front-mesh med tilhørende støttesystemer. For
vertsorganisasjonene bruker man en lignende teknikk som front-mesh: en backend-mesh.
Gjennom en slik videreutvikling, vil hver tjeneste i Feide-føderasjonen fremstå som egne
tjenester for den lokale innloggingstjenesten. Dette gjør det mulig med større tilpasninger
Rapport
Side 29 av 157
lokalt for de forskjellige tjenestene i føderasjonen. Fordelene med en hybrid mesh er at
det er mulig å avlaste noe av kompleksiteten i mange-til-mange-forholdet mellom
vertsorganisasjoner og tjenesteleverandører i sentrale støttetjenester. Backend-mesh har
en del uavklarte momenter rundt sesjonshåndtering, hvilken informasjon som kan
mellomlagres på det sentrale systemet og så videre. Dette må utforskes videre før en
eventuell implementering.
Rapport
Side 30 av 157
4 Gevinster
4.1 Innledning
En sentral del av en behovskartlegging er å formulere hvilke gevinster en kan oppnå
gjennom å realisere de ulike behovene. Dette gjør man blant annet for å sikre at de
foreslåtte endringene har forretningsmessig forankring. Merk at forretningsmessig
forankring handler om mer enn å begrunne tiltak med direkte økonomiske gevinster på kort
sikt: de forretningsmessige begrunnelsene kan i stor grad også ligge i mer langsiktige,
strategiske fordeler.
Gjennom å formulere gevinster, ønsker man å skape bevissthet om hvilke kvaliteter som
må ivaretas for å sikre at endringer faktisk resulterer i de verdiene man håper å oppnå.
Uten denne bevisstheten kan gjennomføringsprosjektet uforvarende endre funksjonaliteten
slik at gevinstene uteblir.
En annen viktig fordel med fokus på gevinster, er å bruke det ved prioritering mellom
løsningsalternativer eller løpende forenklinger som kan gjøres med samme utfall for
gevinstbildet.
Til sist, er gode gevinstbekrivelser en forutsetning for systematisk gevinstrealisering etter
at et prosjekt har levert de nødvendige endringene. For å ta ut gevinstene som er
tilrettelagt gjennom teknologiske endringer, kreves endringer i rutiner, organisasjon,
opplæring og så videre. Dette er et arbeid som må gjøres over tid, og som krever
ledelsesoppfølging.
4.2 Gevinsttyper
Som nevnt i innledningen, er gevinster ikke nødvendigvis knyttet til direkte økonomiske
gevinster. Mange endringer gjennomføres for å oppnå langsiktige endringer, og de er ofte
viktigere å fokusere på enn kortsiktige gevinster. Langsiktige gevinster er gjerne knyttet til
strategiske mål, og de er vanskelige å kvantifisere og måle. Like fullt, bør man forsøke å
detaljere og konkretisere slike gevinster så langt det lar seg gjøre.
Rapport
Side 31 av 157
Vi skiller mellom tre typer gevinster: direkte budsjettmessige gevinster, indirekte
budsjettmessige gevinster og kvalitative gevinster. Den følgende tabellen gir en nærmere
detaljering av disse tre gevinsttypene:
Direkte budsjett-
messige gevinster
• Reduserte eller unngåtte investeringer
• Reduserte eller unngåtte driftskostnader
• Andre reduserte eller unngåtte utgifter
• Økte inntekter på eksisterende tjenester
• Nye inntektskilder gjennom nye tjenester
Indirekte budsjett-
messige gevinster
• Mer effektive arbeidsprosesser (reduserte timeverk)
• Færre henvendelser, saker eller klager (reduserte timeverk)
Kvalitative gevinster
• Bedre tjenestekvalitet
• Økt brukertilfredshet
• Bedre omdømme
• Mer tilgjengelige tjenester
• Reduserte brukerkostnader
• Økt sikkerhet/færre sikkerhetsbrudd
• Mulighet for nye tjenester
Arbeidsgruppen har benyttet dette rammeverket for kategorisering av de konkrete
gevinstene som er funnet for sammenkopling av Feide med lokale innloggingsløsninger.
Mange av gevinstene knyttet til sammenkopling av Feide med lokale innloggingsløsninger er
indirekte budsjettmessige gevinster eller kvalitative gevinster.
Det understrekes igjen at arbeid med konkretisering av gevinster ikke innebærer at man
utelukker eller vanskeliggjør rettferdiggjøring av endringer som ikke direkte kan måles.
Tvert imot, vil konkretisering av kvalitative gevinster gjøre det lettere å sikre at man
jobber med langsiktige initiativer, fordi man har bygget opp en klar argumentasjon som
underbygger hvorfor man gjennomfører endringene. Ved å detaljere gevinstbildet, senkes
risikoen for at store endringsprosjekter kommer ut av kurs.
Rapport
Side 32 av 157
4.3 Beskrivelse av gevinster
Vi har valgt en mal for gevinstbeskrivelser basert på DFØs veileder for gevinstrealisering.
I veilederen inngår følgende punkter i beskrivelsen av gevinster i en gevinstplan:
1. Beskrivelse: Få frem hva gevinsten består i. Hva er den forretningsmessige verdien?
2. Gevinsttype: Direkte budsjetteffekt X. Indirekte budsjetteffekt Y. Kvalitativ effekt Z.
3. Målsetninger: Hva anses for å være ønsket nivå for å si at gevinstene er realisert?
4. Triggere: Hva skal til for å utløse gevinsten? Henvis gjerne til scenarioer.
5. Interessenter: Hvem er interessert i endringen? Hvem påvirkes av endringen?
6. Indikatorer: Hvordan kan man observere gevinsten?
7. Måleparametere: Hvordan kan man omsette indikatorene i måleparametere? Ikke alle
måleparametere har kroneverdi, og ikke alle har tallverdier.
8. Baseline: Hva er dagens nivå?
9. Periodisering/milepæler: Hva er tidslinjen for realisering av gevinsten?
10. Ansvarlig: Hvem er ansvarlig for at gevinstene oppnås?
Siden vi nå er i en tidlig fase, har vi valgt å beskrive de første fem punktene i listen, og
bare på et overordnet nivå. Man må fylle på med flere detaljer på de første fem punktene
og komplettere på et senere stadium. Listen bør være komplett før man beslutter
gjennomføring av konkrete prosjekter.
4.4 Gevinst: bedret brukeropplevelse
Både gjennom spørreundersøkelsen og diskusjonene i arbeidsgruppen, ble en bedre
brukeropplevelse fremholdt som en viktig fordel ved sammenkopling av Feide med lokale
innloggingsløsninger. Det gjaldt både for klientinnlogging og lokale tjenester. Mer konkret,
pekes det på at:
• Brukeren slipper å skrive inn brukernavn og passord flere ganger.
• Innloggingstjenesten blir mer intuitiv, mer konsistent og mindre forvirrende. Et
eksempel fra Oslo kommune er at Office365-brukerne vil slippe å velge mellom lokal
innlogging (synkronisert gjennom SDS) og Feide.
• For Office365 er det ikke mulig å dele dyplenker på tvers av innloggingsmetoder.
• Sammenkopling gjør det mulig å lage sammensatte tjenester (mashup) på tvers av
Feide-tjenester og lokale tjenester.
Rapport
Side 33 av 157
• Brukeren slipper å forholde seg til ulike passord for lokale tjenester og Feide-tjenester.
Her må det legges til at dette ikke automatisk løses sammenkopling mellom Feide og
lokale innloggingstjenester – det er helt avhengig av løsningsalternativet som velges og
at det er en velfungerende lokal synkronisering av passord. Videre er det mulig å gjøre
dette i dag gjennom å synkronisere LDAP-katalogen som er koplet mot Feide lokal AD
(eller tilsvarende). Det er imidlertid riktig å si at gjennom sammenkopling, så vil det
oftere være slik at passord er synkronisert, slik at dette er en potensiell gevinst.
• Prosessen med passordbytte blir mer intuitiv. Dersom et lokalt passord har løpt ut og
brukeren forsøker å logge på en Feide-tjeneste, er det i dag ingen entydig beskjed til
brukeren om at innloggingen feilet på grunn av passordutløp. Dette blir det mulig å gi
under noen av løsningsalternativene som er beksrevet.
Gevinstene ved sammenkopling er ikke mulig å oppnå i alle scenarioer. Så langt har vi
identifisert følgende situasjoner:
• Sammenkopling med klientinnlogging er avgrenset til klienter hvor innloggingen er
koplet til en lokal innloggingstjeneste som vertsorganisasjonen har kontroll med. Det
gjelder ikke de fleste private PC-er eller mobiltelefoner. Dette kan imidlertid omfatte
innloggingsløsninger fra skyleverandører som Google og Microsoft, for eksempel
administrerte Chromebook-er.
• Siden ulike tjenester kan kreve ulike sikkerhetsnivåer, vil brukeren allikevel måtte inn
med ekstra identifikasjon i tilfeller hvor den eksisterende innloggingen ikke
tilfredsstiller kravene ved bruk av en tjeneste. Dette gjelder både ved sammenkopling
med klientinnlogging og med andre innloggingsløsninger. Hvis brukeren har logget inn på
en klient med én-faktor autentisering og ønsker å bruke en tjeneste som krever to-
faktor autentisering, vil brukeren måtte gjennom en ekstra autentisering.
Vi nevner også en mulig negativ innvirkning på brukeropplevelsen ved sammenkopling av
Feide med lokale innloggingsløsninger: når en bruker blir automatisk logget inn på en
Feide-tjeneste basert på klientinnloggingen, blir organisasjonsvalget gjort automatisk. Hvis
brukeren ønsker å logge inn på en Feide-tjeneste med en annen organisasjonstilknytning,
blir dette vanskelig. Dette scenarioet oppstår antagelig relativt sjeldent.
Rapport
Side 34 av 157
Gevinsttype Kvalitativ gevinst.
Målsetninger Sømløs pålogging til Feide-tjenester fra de mest brukte
klienttypene når brukeren autentiseres mot en lokalt kontrollert
innloggingsløsning.
Sømløs pålogging mellom Feide-tjenester og lokale tjenester.
Synkronisering av passord og god veiledning til brukerne ved
passordutløp.
Triggere Sammenkopling av Feide med lokale innloggingsløsninger for
klienter slik at Feide kan gjenbruke klientsesjonen uten å spørre
om brukernavn og passord gitt at klientsesjonen har riktig
sikkerhetsnivå i forhold til tjenestens krav.
Interessenter Sluttbrukere.
Feide-føderasjonen er indirekte interessenter, men det
overlapper med egen gevinst for bedret omdømme.
4.5 Gevinst: mindre behov for brukerstøtte
Det nest mest nevnte gevinstområdet, er redusert arbeidsmengde knyttet til brukerstøtte.
Vi vurderer at det i størst grad gir gevinster lokalt og i mindre grad sentralt, med mindre
man tar steget helt ut i en klassisk mesh-arkitektur. For dette gevinstområdet er det stor
forskjell mellom de ulike løsningsalternativene og hvordan de realiseres.
Den reduserte arbeidsmengden kommer av færre brukerhenvendelser om separat pålogging
til Feide og lokale tjenester: Hvilken pålogging skal brukes til hvilken tjeneste? Hvorfor er
det slik? Hvilket brukernavn og hvilket passord skal jeg bruke? Hvor skifter jeg passord?
Det sparte arbeidet ligger primært hos de lokale IKT-organisasjonene, men sekundært også
til grupper som lærere og forelesere fordi de får disse spørsmålene direkte fra elever og
studenter. Man kan også nevne den innsatsen som gjøres proaktivt, gjennom utarbeidelse
av informasjonsmateriell og veiledere.
Det er usikkert hvor stort potensiale for innsparinger som ligger i gevinstområdet. Fra
arbeidsgruppen er det kommentert at antall henvendelser i dag ikke er stort: det er en lav
baseline. Henvendelsene kommer oftest ved oppstart av nytt semester og ved
nyansettelser. Det bør gjøres en nærmere undersøkelse av baseline før man tar inn dette
som en gevinst i et prosjektforslag.
Rapport
Side 35 av 157
Gevinsttype Indirekte budsjettmessig gevinst.
Målsetninger Redusert antall henvendelser til førstelinje brukerstøtte hos
vertsorganisasjonene og dermed frigjort arbeidstid som kan
omdisponeres til andre formål eller omsettes i reduserte
lønnskostnader.
I en videre analyse, bør det hentes inn konkrete tall på antall
henvendelser knyttet til slike saker i dag (baseline) og vurderes
hvor mange som kan unngås. Videre bør det vurderes hvilke
kostnadsbesparelser dette kan omsettes i.
Triggere Sømløs pålogging til Feide dersom brukeren er pålogget klient
med identitet utstedt av vertsorganisasjonen eller allerede er
pålogget en lokal tjeneste medfører at brukerne ikke kontakter
lokal brukerstøtte med spørsmål om brukernavn, passord eller
andre spørsmål om innlogging til Feide.
Interessenter IKT-avdelingene hos vertsorganisasjonene.
Andre ansatte som får brukerhenvendelser hos vertsorganisa-
sjonene, for eksempel lærere.
4.6 Gevinst: potensielt bedret sikkerhet
I spørreundersøkelsen, har flere vertsorganisasjoner indikert at de mener at en
sammenkopling av Feide med lokale innloggingsløsninger gir bedret sikkerhet. Vi har
dessverre ikke spurt om noen begrunnelse for dette.
Arbeidsgruppen har identifisert følgende, mulige sikkerhetsgevinster:
• Enkelte vertsorganisasjoner har mulighet til å implementere mer avanserte og
tilpassede innloggingsløsninger enn Feide har mulighet til. Feide må ta hensyn til hele
føderasjonens behov, men den enkelte vertsorganisasjon har flere frihetsgrader. Det
nevnes for eksempel at universitetssamarbeidet BOTT i sitt felles IAM-arbeid ser på
løsninger basert på fjerde- og femtegenerasjons sikkerhetsløsninger.
• Det blir enklere å ta i bruk eksisterende, lokale løsninger for to-faktor autentisering.
• Det muliggjør single logout mellom Feide-tjenester og lokale tjenester.
Rapport
Side 36 av 157
På den motsatte siden, har arbeidsgruppens medlemmer tatt opp at sikkerheten også kan
bli forverret av en sammenkopling, fordi sikkerhetskonteksten blir større. Man får
automatisk tilgang til flere tjenester – inkludert tjenester man ikke nødvendigvis har
intensjon om å bruke. Skaden blir dermed større dersom den lokale identiteten blir
kompromittert eller dersom man forlater klienten uten skjermlås. Det nevnes også at det
ikke er uvanlig at elever låner hverandres klienter.
Gevinsttype Kvalitativ gevinst.
Målsetninger Færre sikkerhetsbrudd hvor man får tilgang til Feide-innloggede
tjenester uten gyldig autorisasjon.
Triggere Delegering av autentiseringssteget til lokale innloggingsløsninger.
Interessenter Sluttbrukere.
Vertsorganisasjonene, som endelig ansvarlige for sikkerheten
innenfor sitt domene.
UNINETT, som ansvarlige for den sentrale delen av
sikkerhetskjeden.
Tjenesteleverandører, som ansvarlige for sikkerheten knyttet til
sine tjenester.
4.7 Gevinst: bedret omdømme
Både respondentene i spørreundersøkelsen og arbeidsgruppen vurderte at omdømmet til
de enkelte vertsorganisasjonene ville bli bedre ved en sammenkopling av Feide med lokale
innloggingsløsninger. Dette har sammenheng med en bedre brukeropplevelse, og eventuelt
gjennom færre sikkerhetshendelser. Når brukerne får færre innloggingsløsninger å forholde
seg til, blir det mindre kompleksitet og færre frustrasjoner når man ikke finner ut av
hvordan man skal få tilgang til nødvendige tjenester i hverdagen.
Indirekte kan omdømmet til Feide sett fra brukernes perspektiv bedres ved at det blir
mindre negativ oppmerksomhet ved problemer med tilgang, men samtidig vil mer bruk av
lokale innloggingsløsninger medføre at Feide blir mindre synlig og dermed mindre kjent.
Omdømmet til innloggingsløsninger er, som andre mellomvareløsninger, mest drevet av
fraværet av frustrasjoner og fraværet av sikkerhetshendelser: jo mindre man ser til dem,
jo bedre.
Rapport
Side 37 av 157
Brukerne er en viktig interessentgruppe, men for Feide er også omdømmet blant
vertsorganisasjonene i føderasjonen og tjenesteleverandørene viktig. Bruken av Feide
drives av at tjenesteleverandører og vertsorganisasjoner finner hverandre gjennom
standardiserte og gode løsninger. Da ønsker tjenesteleverandører å ta det ekstra arbeidet
med å tilby Feide-innlogging og at vertsorganisasjonene jobber aktivt med å fremme
innlogging med Feide. Det er derfor viktig at Feide fortsetter å utvikle seg til å støtte
sentrale brukstilfeller og at organisasjonen rundt Feide sentralt er lyttende og
omstillingsdyktig.
Gevinsttype Kvalitativ gevinst.
Målsetninger En mer positiv oppfatning av vertsorganisasjonenes evne til å
tilby digitale tjenester som både er sikre og tilgjengelige. Det
kan vurderes om det skal gjøres konkrete målinger gjennom
spørreundersøkelser eller referansegrupper, men man må være
oppmerksom på at endringene i det digitale landskapet er så
store at det er vanskelig å identifisere en konkret effekt av dette
tiltaket.
En positiv oppfatning av Feide-føderasjonen sett fra
vertsorganisjoner og tjenesteleverandører.
Triggere Bedre brukeropplevelse og eventuelt færre sikkerhetshendelser.
En Feide-tjeneste som støtter sentrale brukstilfeller.
Interessenter Vertsorganisasjonene.
UNINETT.
4.8 Gevinst: økt handlingsrom
Gjennom større grad av delegering av funksjonalitet fra Feide til vertsorganisasjoner som
ønsker det, vil det bli større rom for innovasjon og lokale tilpasninger. Feide vil dermed
fortsette å være en relevant og foretrukket tjeneste også for vertsorganisasjoner med
avanserte behov. I tillegg til å dekke disse organisasjonenes behov, vil dette også være
med på å unngå fragmentering.
Denne gevinsten er beskrevet av arbeidsgruppen, men er ikke testet ut gjennom
spørreundersøkelsen. Det skyldes at gevinsten ikke ble formulert før etter at
spørreundersøkelsen var sendt ut. Uansett ville det vært vanskelig å teste ut dette
gevinstområdet uten en mer inngående introduksjon.
Rapport
Side 38 av 157
Gevinsttype Kvalitativ gevinst
Målsetninger Et modularisert Feide som tilbyr fleksibilitet til avanserte
behovshavere samtidig som det ikke undergraver fordelene i
dagens Feide ved å være en kostnadseffektiv og enkel tjeneste å
ta i bruk.
Triggere Delegering av funksjonalitet til vertsorganisasjoner som ønsker
det slik at de kan utvide med lokale tilpasninger.
Interessenter Vertsorganisjoner med avanserte behov.
Rapport
Side 39 av 157
5 Diskusjon
5.1 Innledning
Arbeidsgruppens oppgave var å:
• Innhente faktiske behov fra ulike brukergrupper i sektoren.
• Kartlegge brukstilfeller.
• Kartlegge interesse for å ta i bruk en slik integrasjon på kort/lengre sikt.
• Kartlegge administrative og tekniske muligheter og utfordringer.
• Kartlegge gevinster og kostnader.
• Kartlegge hvilke konsekvenser etterspurte endringer kan komme til å få for policy,
ansvarsforhold og økonomi.
Basert på denne, skulle gruppen komme med en velbegrunnet anbefaling om hvorvidt det
bør gjøres et videre arbeid på området. Dette kapittelet diskuterer funnene som er gjort
opp mot punktene over. Det neste kapittelet trekker diskusjonen sammen i en anbefaling.
5.2 Behov
Behovene ble identifisert og diskutert gjennom møter i arbeidsgruppen og spørre-
undersøkelsen som ble sendt ut til vertsorganisasjonene.
Arbeidsgruppen representerte de ulike typene av vertsorganisasjoner i Feide-føderasjonen:
universiteter, høyskoler, fylkeskommuner, kommuner og andre organisasjoner. I tillegg
deltok sentrale personer fra UNINETT.
Spørreundersøkelsen ble sendt ut til alle administratorer og tekniske kontakter for de 503
vertsorganisasjonene. Vi mottok svar som representerte 39 % av vertsorganisasjonene,
hovedsakelig fra personer med rollen administrator. Dette er en god svarprosent for en slik
undersøkelse, men det er allikevel vanskelig å trekke presise konklusjoner fra den. For
eksempel er det nærliggende å tro at de som ikke har svart har en mer passiv holdning til
behovet for sammenkopling av Feide med lokale innloggingsløsninger enn de som har svart.
Selv med slike forbehold, har vi mange funn vi kan bygge videre på fra spørre-
undersøkelsen.
Rapport
Side 40 av 157
Basert på arbeidsgruppens diskusjoner og tilbakemeldingene fra spørreundersøkelsen, har
vi identifisert følgende behovsområder:
• Sammenkopling av Feide med klientinnlogging, slik at brukeren automatisk logges på
Feide-tjenester etter innlogging på en administrert klient.
• Sammenkopling av Feide med innlogging som brukes på lokale tjenester, både når
innloggingen for disse tjenestene går mot lokale kataloger, skyføderasjoner, ID-porten
eller andre større ID-leverandører.
• Større fleksibilitet i samspillet mellom vertsorganisasjonene og tjenesteleverandørene
for å gi et utvidet handlingsrom for innovasjon og avanserte løsninger.
Generelt har det vært en utfordring å gjennomføre en behovskartlegging knyttet til et
såpass teknologisk og lite synlig tema som sammenkopling av innloggingsløsninger. For de
fleste er dette funksjonalitet «under panseret». Det har vært mulig å formulere scenarioer
og hente inn tilbakemeldinger på de to første behovsområdene over. Det siste behov-
sområdet, større handlingsrom, har det kun vært mulig å behandle innen arbeidsgruppen.
5.3 Brukstilfeller
Gjennom spørreundersøkelsen fikk vi en oversikt over hvilke løsninger som brukes lokalt,
både når det gjelder klientinnlogging og lokale tjenester. Dette gir et godt utgangspunkt
for å definere brukstilfeller for de første to behovene.
Rapport
Side 41 av 157
For sammenkopling med klientinnlogging, defineres brukstilfellene først og fremst av
hvilke kataloger klientene autentiseres mot. Basert på svarene fra spørreundersøkelsen,
fant vi at følgende løsninger er mest utbredt:
Brukstilfellene kan ytterligere brytes ned i ulike typer utstyr slik som Windows PC, Mac,
iPad og så videre, men dette detaljnivået er ikke relevant for diskusjonen og
anbefalingene i denne rapporten.
3%
4%
17%
76%
Google Directory med kopling mot Feide
Google Directory
Azure AD
Lokal Microsoft AD
Rapport
Side 42 av 157
For sammenkopling av Feide med lokale tjenester, kan brukstilfellene knyttes opp mot
tilsvarende kataloger som brukes for de tjenestene. Fra spørreundersøkelsen fant vi at
følgende kataloger var mest vanlige:
Når det gjelder behovet for større handlingsrom for lokal innovasjon og avanserte
løsninger, så er brukstilfellene primært identifisert gjennom diskusjonene i arbeids-
gruppen. Noe er også understøttet av tilbakemeldingene fra fritekstfeltene i
spørreundersøkelsen. Vi har identifisert følgende brukstilfeller:
• Avansert lokal login. Feide må forholde seg til behovene til føderasjonen som helhet og
kan i begrenset grad gjøre spesialtilpasninger for den enkelte vertsorganisasjon. For
vertsorganisasjoner som har spesifikke behov eller som ønsker å ligge helt i front av
teknologiutviklingen, vil en delegering av autentiseringsfunksjonaliteten gjøre det mulig
å tilby mer avansert funksjonalitet, slik som fjerde- eller femtegenerasjons
sikkerhetsløsninger.
• Tilpasset login per tjeneste. Gjennom mer nyansert informasjonsutveksling mellom
Feide og vertsorganisasjonenes ID infrastruktur, kan de lokale innloggingsløsninger få
mer kontekst. Dette kan omsettes i en bedre brukeropplevelse.
2%
3%
8%
9%
12%
14%
51%
Facebook/Twitter/annen social login
Google Directory
BankId
MinId
Azure AD
Lokal ADFS
Lokal Microsoft AD
Rapport
Side 43 av 157
• Bedre brukeropplevelse for brukergrupper i randsonen av utdanningssektoren.
Eksempler på dette er ansatte ved universitetssykehusene. Vertsorganisasjonene har
større muligheter for å lage helhetlige løsninger for disse enn Feide sentralt.
• Lokal Attribute Release Policy. Dagens Feide har ingen mulighet for å støtte ulik
Attribute Release Policy for kombinasjonen av tjeneste og vertsorganisasjon.
• Løsningsmessig fleksibilitet. Det ligger i naturen til dette behovsområdet at bruks-
tilfellene ikke kan defineres endelig. Dette generelle brukstilfellet dekker alle de
innovasjonsmulighetene som ligger i at de lokale løsningene får delegert mer
informasjon og funksjonalitet fra den sentrale løsningen.
5.4 Muligheter
Arbeidsgruppen har lagt ned et vesentlig arbeid i å kartlegge løsningsalternativer,
herunder en beskrivelse av hvilke muligheter vi ser og utfordringer knyttet til hver av dem,
se kapittel 3 og tilhørende vedlegg. Det er altså fem løsningsalternativer:
1. Mesh
2. Proxy
3. Kerberos
4. Revers proxy for tjenester
5. Klientinnlogging med web-SSO
Løsningsalternativene er ikke gjensidig utelukkende: de utfyller hverandre og kan
kombineres. Gjennom arbeidet med løsningsalternativene har vi fått en god forståelse av
hvordan de understøtter de ulike behovene og løsningsalternativene og mulige veier
videre. En viktig innsikt er at alle løsningsalternativene har ulike fordeler og ulemper for
Feide sentralt og de ulike typene vertsorganisasjoner: det er sannsynlig at det videre
arbeidet vil følge flere parallelle spor.
I dette kapittelet vil vi ikke gå detaljert inn i de fem løsningsalternativene. I stedet
oppsummerer tabellen hvordan de ulike løsningsalternativene dekker de identifiserte
behovene og brukstilfellene:
Rapport
Side 44 av 157
Behov 1 Mesh 2 Proxy 3 Kerberos 4 Revers proxy
5 Klient-innlogging med web-SSO
Sammenkopling av Feide med klientinnlogging
AD Ja Ja Ja Nei Nei
Azure AD Ja Ja Nei Nei Nei1
GCDS Ja Ja Nei Nei Ja2
Sammenkopling av Feide med login for lokale tjenester
AD Ja Ja Ja Nei Nei
ADFS Ja Ja Ja Ja Ja
Azure AD Ja Ja Ja Ja Ja
GCDS Ja Ja Nei Ja Ja
ID-porten Ja Ja Nei Nei Nei
BankID Ja Ja Nei Nei Nei
Social login Ja Ja Nei Nei Nei
Økt handlingsrom for lokal innovasjon og tjenesteutvikling
Avansert lokal
login
Ja Ja Nei Som i dag Som i dag
Tilpasset login
per tjeneste
Ja Ja, med «on
behalf of»
Nei Nei Nei
Lokal Attribute
Release Policy
Ja Nei Nei Nei Nei
Brukere i
randsonen
Ja Ja Delvis Nei Nei
Løsningsmessig
fleksibilitet
Stor
fleksibilitet
Noe større
fleksibilitet
enn i dag
Som i dag Som i dag Som i dag
Merk at tabellen over kun fokuserer på mulighetene. Selv om alternativ 1 gir de største
mulighetene, følger det med store konsekvenser for kostnader, ansvarshold og policy.
1 I skrivende stund har ‘Azure joined’-klienter akkurat kommet og det er uavklart om disse vil kunne benytte Feide-innlogging direkte.
2 For Chromebooks.
Rapport
Side 45 av 157
5.5 Kostnader, ansvarsforhold og policy
De ulike løsningsalternativene har svært ulike konsekvenser for kostnader, ansvarsforhold
og policy. Dette er gjennomgått på prinsipielt nivå i kapittel 3 og tilhørende vedlegg. Selv
på dette nivået blir det mange detaljer, og tabellen under gir derfor en oppsummering av
konsekvensene.
Verdier som benyttes er lav, middels og høy for å antyde størrelsesorden.
Konsekvens 1 Mesh 2 Proxy 3 Kerberos 4 Revers proxy
5 Klient-innlogging med web-SSO
Kostnader
Sentralt Klassisk mesh:
lav
Hybrid mesh:
høy
Middels-Høy Middels-Høy Middels Middels
Lokalt Klassisk mesh:
høy
Hybrid mesh:
høy
Middels Lav-Middels Lav Lav
Ansvarsforhold
Sentralt Lav Middels Høy Høy Høy
Lokalt Høy Middels Lav Lav Lav
Policy
Sentralt Middels Høy Høy Høy Høy
Lokalt Middels Lav Lav Lav Lav
Alternativ 1 Mesh har store konsekvenser både sentralt og lokalt. En klassisk mesh vil ha
uhåndterbare konsekvenser både for tjenesteleverandører og vertsorganisasjoner. Dette vil
kunne avlastes gjennom en hybrid mesh, hvor Feide sentralt håndterer noe av
kompleksiteten gjennom sentrale støttesystemer.
Alternativ 2 Proxy har middels konsekvenser når det gjelder kostnader, og vil medføre
arbeid både for Feide sentralt og lokalt for de institusjonene som velger å ta dette i bruk.
Det påvirker ikke tjenesteleverandørene. Merk at det er en del policyavklaringer som må
gjøres.
Alternativ 3 Kerberos har også middels konsekvenser for kostnader.
Rapport
Side 46 av 157
Alternativ 4 Revers proxy for tjenester og alternativ 5 Klientinnlogging med web-SSO har
lave konsekvenser når det gjelder kostnader, men har en del konsekvenser for
ansvarsforhold og policy som må håndteres.
5.6 Gevinster
Vi har identifisert fem gevinstområder:
• Bedret brukeropplevelse. Gevinsten oppstår gjennom en mer intuitiv brukeropplevelse,
at brukeren slipper å skrive inn brukernavn og passord flere ganger og bedre
synkronisering av passord.
• Mindre behov for brukerstøtte. Den reduserte arbeidsmengden kommer av færre
brukerhenvendelser om separat pålogging til Feide og lokale tjenester. Det sparte
arbeidet knyttes primært til de lokale IKT-organisasjonene, men sekundært også til
grupper som lærere og forelesere fordi de får disse spørsmålene direkte fra elever og
studenter. Det er usikkert hvor stort potensiale som ligger i gevinstområdet fordi
utgangspunktet er at det er få henvendelser om brukerstøtte knyttet til Feide.
• Potensielt bedret sikkerhet. Sikkerhetsgevinsten ligger i at lokale innloggingsløsninger i
enkelte tilfeller kan være mer avanserte enn Feides innloggingsløsning. På den motsatte
siden har vi også argumenter for at sikkerheten kan bli forverret av en sammenkopling,
fordi man automatisk blir logget på tjenester man ikke nødvendigvis har intensjon om å
bruke.
• Bedret omdømme. Effekten antas å være på de enkelte vertsorganisasjonenes
omdømme. Den kommer som en følge av en bedre brukeropplevelse, og eventuelt
gjennom færre sikkerhetshendelser. Feides omdømme hos vertsorganisasjoner og
tjenesteleverandører kan påvirkes positivt.
• Økt handlingsrom. Gjennom større grad av delegering av funksjonalitet fra Feide til
vertsorganisasjonene, vil det bli større rom for innovasjon og lokale tilpasninger. Feide
vil dermed fortsatt være en relevant og foretrukket tjeneste for vertsorganisasjoner
med avanserte behov. I tillegg til å dekke disse organisasjonenes behov, vil dette også
være med på å unngå fragmentering.
Kartleggingen viser at det er flere potensielle gevinster som kan oppnås, men hvorvidt man
oppnår gevinstene – og med hvilket nivå de oppnås – er helt avhengig av hvordan tiltakene
utformes og gjennomføres. Gevinstene vil også være ulike for Feide sentralt og de enkelte
vertsorganisasjonene. Kartleggingen i denne rapporten er et godt utgangspunkt for
diskusjonen om hvilke tiltak som skal prioriteres samt den konkretiseringen som bør gjøres
i utformingen av senere prosjektforslag. Gode gevinstbekrivelser er en viktig del av
prioritering, godkjenning, oppfølging og innføring av endringer.
Rapport
Side 47 av 157
5.7 Interesse
Arbeidsgruppen har kartlagt interessen for å ta i bruk sammenkopling av Feide med lokale
innloggingsløsninger ut fra tre vinklinger:
• Prioritering av behov.
• Vilje og evne til å finansiere og gjennomføre lokale investeringer.
• Vilje og evne til å finansiere sentrale investeringer.
Som tidligere beskrevet, har vi identifisert tre behovsområder: sammenkopling med
klientpålogging, sammenkopling med lokale tjenester og økt handlingsrom.
For de to første behovsområdene, har vi støtte i spørreundersøkelsen gjennom konkrete
spørsmål om hvilken prioritet vertsorganisasjonene setter på behovet for sammenkopling.
Med noen forbehold om usikkerhetsmarginer som er omtalt tidligere i rapporten, vil vi
oppsummere funnene som følger:
• Mellom 8,9 % og 23,3 % av vertsorganisasjonene mener at det bør gis høy prioritet å
sammenkople klientinnlogging med Feide.
• Mellom 8,2 % og 21,2 % av vertsorganisasjonene mener at det bør gis høy prioritet å
sammenkople Feide og andre innloggingsløsninger.
• I motsetning til tilfellet for scenarioet for sammenkopling av klientinnlogging med
Feide, ser vi ikke at universiteter og fylkeskommuner prioriterer sammenkopling og
Feide med lokale innloggingsløsninger markant høyere enn resten av vertsorganisa-
sjonene. Det er noe høyere for universitetene, men ikke i samme grad.
Når det gjelder prioritering av behovet for økt handlingsrom, så har vi ikke noen
kvantitative funn fra spørreundersøkelsen. Her bør det gjøres en videre konkretisering av
behovene på prosjektbasis, i samarbeid med de vertsorganisasjonene som fremmer
behovene.
I spørreundersøkelsen spurte vi også om investeringsvilje. Svarene fra spørreundersøkelsen
viste ingen større forskjell mellom viljen og evnen til å investere lokalt versus sentralt.
Resultatene viser at det er under middels investeringsvilje: det er flere som uttrykker svak
investeringsvilje enn de som uttrykker sterk investeringsvilje. Dette er i samsvar med
svarene på prioritering. Imidlertid ser vi at det ikke er noen korrelasjon mellom de som
mener at dette skal prioriteres høyt og tilsvarende vilje til investering.
Rapport
Side 48 av 157
5.8 Andre forhold
Dataporten benytter Feide til autentisering av brukere i sektoren og er avhengig av en
fungerende Feide-føderasjon for å kunne tilby sine tjenester. Sammen omtales Feide og
Dataporten nå gjerne som «Feide 2.0» og ses i sammenheng.
Avhengig av hvordan føderasjonen videreutvikles, må kanskje en del av funksjonaliteten i
Dataporten endres. Autentisering vil fungere som før uavhengig av alternativene vi
beskriver, men funksjonalitet rundt API-er for person- og gruppeinformasjon, inkludert
personsøk, må endres for mesh- og proxy-alternativene.
Rapport
Side 49 av 157
6 Anbefaling
Arbeidsgruppen anser det som viktig å videreutvikle Feide slik at det også i fremtiden er
utdanningssektorens foretrukne løsning for sikker identifisering. Strategisk og i forhold til
Feides omdømme, anbefaler arbeidsgruppen derfor å gå videre med arbeidet for
sammenkobling av Feide med lokale innloggingsløsninger.
Kartleggingsarbeidet har vist at vertsorganisasjonene i Feide kan deles inn i to grupper,
både i forhold til behov for endring og forutsetninger for å håndtere endringer. På den ene
siden, har vi organisasjoner som ønsker fleksibilitet og stor grad av lokale tilpasnings-
muligheter. Disse organisasjonene har høy teknisk kompetanse, og større økonomisk
spillerom. På den andre siden, har vi organisasjoner som ønsker enkelhet og forutsig-
barhet, samt størst mulig grad av sentralisering. Disse organisasjonene har mindre teknisk
kompetanse og lite økonomiske ressurser.
Arbeidsgruppen anbefaler følgende videre arbeid:
• Løsningsalternativ 4 Revers proxy for tjenester og løsningsalternativ 5 Klientinnlogging
med web-SSO, er i stor grad mulige å ta i bruk av vertsorganisasjonene allerede i dag.
Arbeidsgruppen anbefaler at disse alternativene videreutvikles. En stor del av dette vil
bestå i å utforme veiledningsmateriell og dokumentasjon, men det bør også settes av
ressurser til kartlegging og testing av nye muligheter. For eksempel, kan klienter i Azure
AD løse utfordringen med klientinnlogging mot Feide-innlogging. Det ligger potensielt
store gevinster i å utnytte de mulighetene som ligger i disse alternativene, og dersom
UNINETT og Senter for IKT i utdanningen samtidig bruker ressurser på videre testing av
fremtidige muligheter vil dette komme sektoren til gode. I tillegg til veiledning og
testing, bør det vurderes å utarbeide og gjennomføre kurs i å utnytte de muligheter som
ligger i alternativ 4 og 5. Arbeid med veiledning og kurs kan i tillegg bringe oss nærmere
behovshavere, og gjennom det spisse en kravspesifikasjon for videre arbeid.
• Løsningsalternativ 2 Proxy, vil dekke mange av de mer avanserte organisasjonenes
behov, og arbeidsgruppen anbefaler at dette alternativet videreføres. Det bør opprettes
en arbeidsgruppe som spesifiserer nærmere hvordan dette implementeres. Herunder
inngår hvilke endringer dette vil ha for policy, ansvarsforhold, økonomi og finansiering.
Rapport
Side 50 av 157
Følgende alternativer anbefales ikke på det nåværende tidspunkt:
• Løsningsalternativ 1 Mesh, basert på en klassisk mesh-arkitektur, er fra arbeidsgruppen
ansett for å være en uhåndterlig endring av Feides arkitektur fra dagens situasjon. Et
fåtall vertsorganisasjoner har kompetanse og kapasitet til å endre seg slik dette
alternativet krever. I tillegg, vil det medføre endringer hos samtlige tjeneste-
leverandører, som også antas å ha begrenset kompetanse, kapasitet og vilje. Alternativ
1 med klassisk mesh anbefales derfor ikke nå.
• Løsningsalternativ 1 Mesh, basert på en hybrid mesh-arkitektur, kan være aktuelt å
vurdere som et neste steg etter at proxy-alternativet er etablert. Her er det en del
usikkerheter som må avklares i forhold til hvordan backend-mesh mot vertsorganisa-
sjonene kan settes opp.
• Løsningsalternativ 3 Kerberos bør ikke tas videre. Dette alternativet er bedre dekket av
proxy-løsningen, eventuelt en mesh. Kerberos kan koples sammen med lokale
innloggingstjenester på en bedre og mer brukervennlig måte enn den den sentrale
innloggingsløsningen i Feide.
Rapport
Side 51 av 157
Vedlegg 1: Resultater fra
spørreundersøkelsen
V.1.1 Innledning
Som et ledd i å undersøke bredden i behovene og for å forstå behovet for sammenkopling
av Feide med lokale innloggingsløsninger, ble det utarbeidet en spørreundersøkelse.
Den ble utformet ut fra følgende målsetninger:
• Sjekke ut identifiserte scenarioer og hente inn noe tilleggsinformasjon slik som hvilket
utstyr som brukes og hvilke lokale påloggingsløsninger som er i bruk.
• Fange opp om det er noen utbredte bruksscenarioer vi ikke har identifisert.
• Teste ut kostnadssensitivitet og gjennomføringsevne.
V.1.2 Utforming
Spørreundersøkelsen ble utarbeidet av UNINETTs deltakere i arbeidsgruppen og de øvrige
medlemmene fikk anledning til å gi tilbakemeldinger på utformingen. Undersøkelsen besto
av følgende seksjoner:
• Hvem er du? Spørsmål for å plassere respondenten i forhold til organisasjonstype
(universitet, høyskole, fylkeskommune, kommune, privat skoleeier eller annen) og rolle,
samt hente inn kontaktinformasjon for eventuell oppfølging. Vi spurte om
organisasjonstype for å få mulighet for krysstabulering. Det er et viktig verktøy for å
kunne kartlegge variasjoner i behov mellom organisasjonstyper.
• Scenario: Sammenkopling av klientinnlogging og Feide-pålogging. Behov, gevinster, type
utstyr, type intern katalog.
• Scenario: Sammenkopling av Feide-pålogging og andre innloggingsløsninger. Behov,
gevinster, type utstyr, type lokale innloggingsløsninger.
• Andre scenarioer. For å fange opp scenarioer vi ikke har tenkt på.
• Finansiering og gjennomføringskapasitet. For å kartlegge hvorvidt vertsorganisasjonene
vil finansiere endringer og om de har lokal kapasitet til å følge opp endringer som
medfører at de må tilpasse egne systemer og rutiner.
Rapport
Side 52 av 157
• Annet. Åpen post for å fange opp tilbakemeldinger som faller utenfor skjemaet.
Se vedlegg 2 for en komplett gjengivelse av spørreundersøkelsen med spørsmålene og
svaralternativene som ble gitt.
V.1.3 Distribusjon
En god svarprosent er viktig for å få kunne trekke gode konklusjoner fra undersøkelsen med
så liten feilmargin som mulig. Følgende tiltak ble gjort for å sikre høy svarprosent:
• Undersøkelsen ble gjort så kort som mulig for at flest mulig skulle ta seg tid til å svare.
• Undersøkelsen ble utstyrt med logo og en tilpasset URL slik at den ikke skulle bli avvist
som svindel, men fremstå som offisiell.
• Undersøkelsen ble annonsert på UNINETTs nettsider.
• E-posten som ble sendt ut med lenken til undersøkelsen var adressert fra Lars Kviteng,
tjenesteansvarlig for Feide hos UNINETT.
• Vi sendte ut en generell påminnelse en uke etter første utsendelse.
• Vi sendte en særskilt purring til fylkeskommuner og universiteter, fordi disse har
særskilte behov som vi ønsket å fange opp.
Spørreundersøkelsen ble annonsert på UNINETTs nettsider 4. september, og sendt ut til e-
postlistene for administratorer (1262 mottakere) og tekniske kontakter (565 mottakere) for
alle vertsorganisasjoner i Feide-føderasjonen. Det er noe overlapp mellom listene.
Svarfristen ble satt til fredag 15. september. Den generelle påminnelsen ble sendt ut
mandag 11. september og den særskilte purringen ble sendt tirsdag 19. september.
Undersøkelsen ble lukket for mottak av svar den 22. september.
V.1.4 Svarprosent
Det er 503 vertsorganisasjoner i Feide:
Type Antall
Fylkeskommune 18
Høgskole 41
Kommune 384
Privat skoleeier 36
Universitet 11
Rapport
Side 53 av 157
Type Antall
Annen 13
Totalt 503
Vi fikk 193 svar på spørreundersøkelsen. Av disse hadde 15 organisasjoner svart to ganger
og en organisasjon tre ganger. 32 organisasjoner inngår i seks ulike kommunesamarbeid. I
tillegg kommer BIBSYS, som representerer i overkant av 90 biblioteker. Hvis vi ser bort fra
BIBSYS, men inkluderer kommunesamarbeidene, så er 198 av de 503 organisasjonene
representert minst en gang i et svar til spørreundersøkelsen. Vi legger altså til grunn at
svarprosenten er 198/503 = 39 %.
Grafen under viser oppsummert svarprosent per organisasjonstype:
Vi har altså ingen organisasjonstyper med signifikant lavere svarprosent enn totalen.
Årsaken til at den høye svarprosenten for universiteter, fylkeskommuner og andre
organisasjonstyper ikke trekker snittet mer opp er at kommunene utgjør 75 % av alle
vertsorganisasjoner.
En kunne utvidet analysen med å vekte i forhold til størrelsen på vertsorganisasjonene
målt etter antall brukere, antall innlogginger eller annet. Vi har ikke prioritert dette, men
har ingen indikasjoner på at det er spesielle skjevheter som tyder på at vi har overvekt av
svar fra små vertsorganisjoner eller omvendt.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
UniversitetFylkeskom
muneAnnen Høgskole Kommune
Privatskoleeier
Totalt
Svarprosent 82% 61% 54% 39% 37% 36% 39%
Rapport
Side 54 av 157
Tabellen under viser hvilken rolle respondentene oppga at de hadde:
Det er altså i hovedsak personer i rollen administrator som har svart. I gruppen av andre,
er det noen som har oppgitt at de er både administrator og teknisk kontakt.
V.1.5 Feilmarginer
Svarene fra spørreundersøkelsen representerer 39 % av vertsorganisasjonene. Et viktig
spørsmål er dermed hvordan de 61 % som ikke er representert ville påvirket utfallet. En
vanlig måte å tilnærme seg dette, er å beregne en statistisk feilmargin med utgangspunkt i
at de innkomne svarene er representative for de som ikke har svart.
Rapport
Side 55 av 157
Formelen for beregning av feilmargin med 95 % konfidensnivå er:
± 1,96 · √50 % · (1 − 50 %)
√𝑢𝑡𝑣𝑎𝑙𝑔· √
𝑝𝑜𝑝𝑢𝑙𝑎𝑠𝑗𝑜𝑛 − 𝑢𝑡𝑣𝑎𝑙𝑔
𝑝𝑜𝑝𝑢𝑙𝑎𝑠𝑗𝑜𝑛 − 1
𝑝𝑜𝑝𝑢𝑙𝑎𝑠𝑗𝑜𝑛 = 𝑎𝑛𝑡𝑎𝑙𝑙𝑒𝑡 𝑖 𝑔𝑟𝑢𝑝𝑝𝑒𝑛
𝑢𝑡𝑣𝑎𝑙𝑔 = 𝑎𝑛𝑡𝑎𝑙𝑙 𝑠𝑣𝑎𝑟 𝑓𝑟𝑎 𝑔𝑟𝑢𝑝𝑝𝑒𝑛
Dersom spørreundersøkelsen hadde hatt et perfekt, randomisert utvalg, ville en svarandel
på 198 av 503 gitt en feilmargin på +/- 5,4 % med 95 % konfidens.
Leddet 50 % · (1 – 50 %) uttrykker at de personene som ikke har svart vil balansere om
samme gjennomsnitt som de som har svart.
Feilmarginen gjelder for lineære skalaer. Det vil si at dersom man stiller et spørsmål hvor
respondentene blir bedt om å rangere noe på en skala fra 0 til 10, og gjennomsnittet av
innkomne svar er 5,00, så er det 95 % sikkert at hvis man hadde spurt alle, så ville
resultatet vært mellom 4,46 og 5,54. I vår spørreundersøkelse, var mange av spørsmålene
ikke orientert langs en lineær skala. For disse spørsmålene gir feilmarginen en viss
indikasjon på hvor pålitelige resultatene er, men kan ikke benyttes kvantitativt.
Hvis man bryter ned dette i de ulike typene organisasjoner, har vi følgende feilmarginer:
Gruppe Feilmargin med 95 % konfidens
Universitet ± 13,9 %
Fylkeskommune ± 18,4 %
Annen ± 25,2 %
Høgskole ± 19,1 %
Kommune ± 6,5 %
Privat skoleeier ± 21,7 %
Merk at selv om 82 % av universitetene har svart og bare 37 % av kommunene, så er
feilmarginen lavere for kommunene. Dette skyldes at det kreves lavere andel svar i en stor
populasjon for å få lav feilmargin.
Det er et meget viktig forbehold når det gjelder beregningen av feilmarginene i målingene,
og det gjelder spørsmålet om representativitet. Beregningene av feilmargin er basert på at
de som ikke har svart mener det samme som gruppen som har svart. Når
spørreundersøkelsen er sendt ut slik den er, vil denne antagelsen ikke nødvendigvis
stemme på grunn av selvseleksjon. Respondentene velger selv om de svarer, og det er få
sanksjoner eller ulemper med å la være å svare. Årsaker til manglende svar kan være:
Rapport
Side 56 av 157
• Temaet oppfattes som irrelevant.
• Ingen endring ønskes, og det oppfattes som bortkastet tid å svare.
• Spørsmålene eller premissene for spørsmålene ble ikke forstått.
• Man tror noen andre i samme organisasjon svarer.
• Spørreundersøkelsen ble glemt.
Noen av årsakene åpner for at det kan være systematiske skjevheter i feilmarginen, fordi
det kan være sammenheng mellom manglende svar og enkelte svaralternativer. Feil-
marginen vil dermed øke, og den vil gjøre det systematisk i en bestemt retning. Det vil
være nødvendig å trekke inn dette i analysen, ved å gjøre a priori slutninger om
meningene til de som ikke svarer.
V.1.6 Funn: behov for sammenkopling av
klientinnlogging med Feide
Vertsorganisasjonene fikk presentert følgende scenario:
En forsker, lærer eller administrativt ansatt benytter både tjenester med Feide-
pålogging, for eksempel Blackboard, og tjenester med lokal pålogging, for eksempel
innkjøpsløsningen Basware IP. Når den ansatte har logget på sin klient, skal det være
sømløs innlogging til begge typer tjenester basert på klientinnloggingen.
Med klient menes en stasjonær eller bærbar datamaskin. I denne sammenhengen er det
snakk om utstyr hvor brukeren logger på med en bruker som er utlevert av din
organisasjon.
Et eget scenario dekker bruk av tjenester fra utstyr uten klientinnlogging med bruker
fra din organisasjon, for eksempel fra bærbar PC som en ansatt eier selv.
De fikk følgende svaralternativer:
• Ja, det må løses og gis høy prioritet
• Ja, det burde løses, men bør gis lav prioritet
• Nei, det er mindre viktig og bør ikke prioriteres
• Nei, vi har allerede løst dette
• Nei, for vi har ikke klientinnlogging
• Annet
Rapport
Side 57 av 157
Svarene fordelte seg som følger blant respondentene:
Vi fikk følgende tekstlige kommentarer:
• Antar sikkerhetsvurdering ville gjøre at vi ikke aktiverte dette
• Azure AD vurderes også for klientinnlogging
• Dagens løsning for å sy dette sammen er jo kostbar. Vil dette på noen måte kunne
tvinge frem fri alternativer, så hadde man jo vært positiv til dette, men frykter vel at
det er litt for sterke kommersielle aktører her.
• Hvordan vil dette henge sammen med 2-faktor-autentisering ift personopplysninger?
• I dagens løsning må alle våre ca. 100.000 sluttbrukere skrive samme brukernavn og
passord 2 ganger (klientpålogging og deretter FEIDE-pålogging) for å nå FEIDE-ressurser.
Dette oppleves som unødvendig. Utdanningsetaten har 2 separate AD'er med delvis
overlappende brukermasse, hvorav det ene er koplet mot FEIDE.
Rapport
Side 58 av 157
• Kun et ytterst fåtall hos oss har Windows i AD. Scenarioet er nyttig i organisasjoner som
er fully managed - hvis sømløs pålogging virker.
• Levert og administrerrt av ROR IKT
• Pga kommunesamarbeidet har de ansatte forskjellig påloggingsdetaljer lokalt og i felles
FEIDE.
• Savner veiledning på dette området.
• Støtte for Microsoft Passport / Windows Hello
• Vi er i prosess med flytting til Azure AD. SSO for ansatte til alle Feide-tjenester kan
være et sikkerhetsproblem mht lærerpc-er ute i undervisningsrom.
• Vi har fulldigitalisert identitetsforvaltning i hele kommunen. AD og Feide-kontoer er for
skolene 100 % synkronisert. Ett brukernavn og passord - SSO.
• Vi har ikke opplevd problemer med dette. Alle ansatte og elever logger på Chromebook
og feidekontoer i en og samme operasjon. Noen feideinlogginger krever at en oppgir
brukernavn og passord, mens andre slipper oss gjennom fordi vi allerede er innlogget
• Vi tilhører samarbeidet i eKommune Sunnmøre og følger det oppsettet de har.
• Økt integrering gir økt press på tofaktor, som kan oppleves plundrete
Følgende tabell gjengir samme informasjon som kakediagrammet, men viser også andelen
hensyntatt de vertsorganisasjonene som ikke har svart:
Svaralternativ Antall Andel av
besvarte
Andel av alle
vertsorganisasj
oner
Ja, det må løses og gis høy prioritet 45 23,3 % 8,9 %
Ja, det burde løses, men bør gis lav
prioritet
66 34,2 % 13,1 %
Nei, det er mindre viktig og bør ikke
prioriteres
27 14,0 % 5,4 %
Nei, vi har allerede løst dette 37 19,2 % 7,4 %
Nei, for vi har ikke klientinnlogging 7 3,6 % 1,4 %
Annet 11 5,7 % 2,2 %
Ikke svart 310
61,6 %
Sum 503 100,0 % 100,0 %
I gruppen «annet» finner vi svar som tilsvarer prioritet fra lav og nedover: ingen svar
knyttes til gruppen av de som mener at det bør gis høy prioritet.
Rapport
Side 59 av 157
Med referanse til kapittelet om beregning av feilmarginer, må det vurderes hvordan
gruppen av de som ikke har svart ville påvirket sluttresultatet. Det er nærliggende å tro at
de som ikke har svart har en mer passiv holdning til behovet enn de som har svart, og at
andelen av de som mener at dette bør gis høy prioritet er lavere blant alle vertsorganisa-
sjoner enn de som har svart. Tabellen angir en nedre skranke for dette ved å vise
svarandelen sett opp mot alle vertsorganisasjoner. Hvis alle de som ikke har svart vil velge
et annet alternativ enn «ja, det må løses og gis høy prioritet», så blir totalen 8,9 %. Siden
det er lite sannsynlig at det er høyere andel enn 23,3 % blant de som ikke har svart som
mener at behovet bør gis høy prioritet, er denne prosenten mest sannsynlig også en øvre
skranke. Vi mener derfor at det er gyldig å konkludere som følger:
Mellom 8,9 % og 23,3 % av vertsorganisasjonene mener at det bør gis høy prioritet å
sammenkople klientinnlogging med Feide.
De følgende tabellene viser nedbrytning av svarene per type vertsorganisasjon. Her
fremgår det også hva som er oppgitt under svaralternativ «annet».
Kommune 128 Andel
Ja, det burde løses, men bør gis lav prioritet 42 32,8 %
Nei, vi har allerede løst dette 33 25,8 %
Ja, det må løses og gis høy prioritet 27 21,1 %
Nei, det er mindre viktig og bør ikke prioriteres 14 10,9 %
Nei, for vi har ikke klientinnlogging 5 3,9 %
Har en løsning. Ønsker noe bedre 1 0,8 %
Vi logger oss på med FEIDE i Fronter, her har vi en FEIDE portal
som tar oss til andre FEIDE innlogginger som Salaby og Conexus, vi
kommer da rett inn ved å trykke på FEIDE ikonet.
1 0,8 %
Har ikke registrert så my da vi er helt ny i feide 1 0,8 %
Vår AD erknytta saman med vår Feide-katalog. Sjølv om vi ikkje
har SSO, er brukarnamn og passord likt.
1 0,8 %
Nei, de logger inn via skoleportal uavhengig av klient 1 0,8 %
Er løst med manuelt oppsett 1 0,8 %
Litt usikker på hva jeg skal svare 1 0,8 %
Rapport
Side 60 av 157
Høgskole 18 Andel
Ja, det burde løses, men bør gis lav prioritet 6 33,3 %
Nei, det er mindre viktig og bør ikke prioriteres 5 27,8 %
Ja, det må løses og gis høy prioritet 4 22,2 %
Nei, for vi har ikke klientinnlogging 1 5,6 %
Vi bruker separat innlogging, men anser ikke det som et problem 1 5,6 %
manglende nivå: Ja det bør løses. 1 5,6 %
Privat skoleeier 15 Andel
Nei, det er mindre viktig og bør ikke prioriteres 5 33,3 %
Ja, det burde løses, men bør gis lav prioritet 4 26,7 %
Ja, det må løses og gis høy prioritet 4 26,7 %
Nei, vi har allerede løst dette 2 13,3 %
Fylkeskommune 14 Andel
Ja, det burde løses, men bør gis lav prioritet 6 42,9 %
Ja, det må løses og gis høy prioritet 5 35,7 %
Bør utredes og vurderes i forhold til sikkerhet. Dete kan jo ha noen
negative konsekvenser.
1 7,1 %
Nei, vi har allerede løst dette 1 7,1 %
Nei, det er mindre viktig og bør ikke prioriteres 1 7,1 %
Universitet 11 Andel
Ja, det burde løses, men bør gis lav prioritet 5 45,5 %
Ja, det må løses og gis høy prioritet 4 36,4 %
Nei, vi har allerede løst dette 1 9,1 %
Nei, det er mindre viktig og bør ikke prioriteres 1 9,1 %
Annen 7 Andel
Ja, det burde løses, men bør gis lav prioritet 3 42,9 %
Nei, for vi har ikke klientinnlogging 1 14,3 %
Vi har problemer, men vi bruker Feide-hotell med obligatorisk
lagring av personnummer hos UiT og da blir det problematisk med
single sign on for hele organisasjonen, for da må alle samtykke i at
person-ID'en blir lagret eksternt.
1 14,3 %
Ja, det må løses og gis høy prioritet 1 14,3 %
Nei, det er mindre viktig og bør ikke prioriteres 1 14,3 %
Rapport
Side 61 av 157
Vi ser at andelen som mener at dette bør gis høy prioritet er høyere enn gjennomsnittet
blant universiteter og fylkeskommuner og dels private skoleeiere. Siden svarprosenten er
såpass høy for universiteter fylkeskommuner, er resultatet også mindre påvirket av
gruppen som ikke har svart. Altså:
Blant universiteter og fylkeskommuner er det uttrykt et høyere behov for å
sammenkople klientinnlogging med Feide enn hos øvrige vertsorganisasjoner.
V.1.7 Funn: behov for sammenkopling av Feide og
andre innloggingsløsninger
Vertsorganisasjonene fikk presentert følgende scenario:
En elev eller student bruker egen datamaskin og logger på en tjeneste med Feide, for
eksempel Fronter. Hvis brukeren ønsker å bruke en tjeneste med lokal pålogging, for
eksempel din organisasjons intranett, så skal innlogging skje sømløst.
De fikk følgende svaralternativer:
• Ja, det må løses og gis høy prioritet
• Ja, det burde løses, men bør gis lav prioritet
• Nei, det er mindre viktig og bør ikke prioriteres
• Nei, for alle våre tjenester har Feide-pålogging
• Nei, for vi har allerede løst dette
• Annet
Rapport
Side 62 av 157
Svarene fordelte seg som følger blant respondentene:
Vi fikk følgende tekstlige kommentarer:
• AD og LDAP er ikke veldig relevant, da UiO har styringsregler som sier at disse ikke skal
brukes.
• Azure AD vurderes for klientinnlogging. ADFS benyttes sammen med FEIDE i O365
• Benytter ikke Feide mot Fronter
• Burde nok ha laget egne Feide-tjenester for noe lokale webpålogginger, men ting tar
tid. Gode lenker til eksempel implementasjon er bra.
• Det hadde vært veldig fint om Feide ble en løsning for hele kommunal sektor - ikke bare
for oppvekst.
• Elever har ingen sentral innloggingsløsning, men kun lokal innlogging.
Rapport
Side 63 av 157
• Feide og AD er 100 % synkronisert
• Foresatte benytter Id-porten når de logger seg inn i Meldeboka / LMS
• Levert og administrert av ROR IKT
• Så lenge passordet er synkronisert, gjør det ikke noe at det er egen pålogging
• Vi følger eKommune Sunnmøre sitt oppsett.
• Vi har fjernet AD for elever. Elever bruker bare Chromebook i dag
Følgende tabell gjengir samme informasjon som kakediagrammet, men viser også andelen
hensyntatt de vertsorganisasjonene som ikke har svart:
Svaralternativ Antall Andel av
besvarte
Andel av alle
vertsorga-
nisasjoner
Ja, det må løses og gis høy prioritet 41 21,2 % 8,2 %
Ja, det burde løses, men bør gis lav prioritet 57 29,5 % 11,3 %
Nei, det er mindre viktig og bør ikke prioriteres 35 18,1 % 7,0 %
Nei, for alle våre tjenester har Feide-pålogging 24 12,4 % 4,8 %
Nei, for vi har allerede løst dette 21 10,9 % 4,2 %
Annet 15 7,8 % 3,0 %
Ikke svart 310
61,6 %
Svarene i kategorien «annet» er tilbakemeldinger som tilsvarer prioritet fra lav og nedover:
ingen svar knyttes til gruppen av de som mener at det bør gis høy prioritet.
På samme måte som for tilsvarende spørsmål om sammenkopling av klientinnlogging med
Feide, er det også her nærliggende å tro at de som ikke har svart har en mer passiv
holdning til behovet enn de som har svart. Vi bruker dermed intervallet mellom de to siste
kolonnene i tabellen over på samme måte, og konkluderer:
Mellom 8,2 % og 21,2 % av vertsorganisasjonene mener at det bør gis høy prioritet å
sammenkople Feide og andre innloggingsløsninger.
Rapport
Side 64 av 157
De følgende tabellene viser nedbrytning av svarene per type vertsorganisasjon. Her
fremgår det også hva som er oppgitt under svaralternativ «annet».
Kommune 128 Andel
Ja, det burde løses, men bør gis lav prioritet 33 25,8 %
Ja, det må løses og gis høy prioritet 29 22,7 %
Nei, det er mindre viktig og bør ikke prioriteres 20 15,6 %
Nei, for alle våre tjenester har Feide-pålogging 19 14,8 %
Nei, for vi har allerede løst dette 16 12,5 %
Vi er på god veg til å få alle ressursane våre Feide-basert. 1 0,8 %
For lisensieringen sin del, er det et krav om at lokale tjenester gjøres
fra maskiner eid av oss. Ser ikke at man kan løse dette uten å bryte MS
lisenser rundt CAL lisensieringen. Denne er ganske mye mer
problematisk en det folk er klar over. Så er skolen i all sak usercal
lisensiert, men dette stemmer ofte ikke for resten av brukerne. I et
stordriftsøyemed blir dette derfor vanskelig.
1 0,8 %
Jf forrige spm 1 0,8 %
Er litt usikker på hva som skjer hos elevene.. 1 0,8 %
Har ikke Feidepålogging 1 0,8 %
På enkelte tjeneste ja, andre ikke 1 0,8 %
Ja men det er admin tjenester i et annet domene 1 0,8 %
SSO når de ikke er i kommunalt nettverk 1 0,8 %
Alle våre tjenester har Feide-pålogging, med unntak av webmail.
Snarveier ligger samlet ett sted.
1 0,8 %
Elevene vår bruker iPad og disse er organisert i Airwatch, eleven logger
seg på FEIDE i appen eller i nettleseren
1 0,8 %
Elevene bruker ikke egen datamaskin, de har datamaskiner på skolen 1 0,8 %
Høgskole 18 Andel
Ja, det burde løses, men bør gis lav prioritet 8 44,4 %
Nei, det er mindre viktig og bør ikke prioriteres 5 27,8 %
Ja, det må løses og gis høy prioritet 3 16,7 %
Nei, for alle våre tjenester har Feide-pålogging 2 11,1 %
Privat skoleeier 15
Nei, det er mindre viktig og bør ikke prioriteres 6 40,0 %
Nei, for vi har allerede løst dette 3 20,0 %
Ja, det burde løses, men bør gis lav prioritet 3 20,0 %
Ja, det må løses og gis høy prioritet 2 13,3 %
Nei, for alle våre tjenester har Feide-pålogging 1 6,7 %
Rapport
Side 65 av 157
I motsetning til tilfellet for scenarioet for sammenkopling av klientinnlogging med Feide,
ser vi ikke at universiteter og fylkeskommuner prioriterer sammenkopling og Feide med
lokale innloggingsløsninger markant høyere enn resten av vertsorganisasjonene. Det er noe
høyere for universitetene, men ikke i samme grad.
V.1.8 Funn: andre scenarioer
Se vedlegg 3 for en gjengivelse av svarene på spørsmålet om det er andre scenarioer hvor
det er behov for sammenkopling av Feide med lokale innloggingsløsninger. Mange av
tilbakemeldingene gjelder detaljeringer innenfor de scenarioene som allerede er gjengitt,
men følgende scenarioer kommenteres spesielt:
Bruk av Feide for
innlogging på
trådløsnett for
elever
For de som har en portal med web-innlogging til trådløst nett kan
portalen integreres med Feide. For ren Radius-autentisering
anbefales eduroam.
Fylkeskommune 14 Andel
Ja, det burde løses, men bør gis lav prioritet 6 42,9 %
Ja, det må løses og gis høy prioritet 3 21,4 %
Nei, det er mindre viktig og bør ikke prioriteres 2 14,3 %
Elevene har i dag ingen lokale tjenester bortsett fra wifi innlogging. 1 7,1 %
Nei, for vi har allerede løst dette 1 7,1 %
Nei, for alle våre tjenester har Feide-pålogging 1 7,1 %
Universitet 11 Andel
Ja, det burde løses, men bør gis lav prioritet 5 45,5 %
Ja, det må løses og gis høy prioritet 3 27,3 %
Få eksempler, og de kan feide-ifiseres 1 9,1 %
Nei, for vi har allerede løst dette 1 9,1 %
Nei, for alle våre tjenester har Feide-pålogging 1 9,1 %
Annen 7 Andel
Nei, det er mindre viktig og bør ikke prioriteres 2 28,6 %
Ja, det burde løses, men bør gis lav prioritet 2 28,6 %
Vi har ingen studenter 1 14,3 %
Har ikke elever/studenter 1 14,3 %
Ja, det må løses og gis høy prioritet 1 14,3 %
Rapport
Side 66 av 157
Lokale
engangspassord
(TOTP)
Med løsningsalternativ 1 Mesh og 2 Proxy vil dette kunne brukes
så lenge de lokale TOTP-løsningene kobles til lokal IdP. For å
støtte lokale TOTP-løsninger i dagens arkitektur, må Feide
videreutvikle den sentrale løsningen for sterk autentisering.
Kameraovervåkning,
adgangskontroll,
Wordpress og print
Slike integrasjoner støttes dersom det finnes et tilgjengelig web-
grensesnitt.
Logge seg inn i
Canvas på tvers av
institusjoner
Dette er fullt mulig i dag. Feide legger ingen begrensninger, men
forutsetter lokal bruker i Canvas-instans.
Office 365 lokalt Pålogging til «tykk» Office-klient er mulig i dag. Azure AD kan
enten kobles til Feides SSO-domene eller til lokalt SSO-domene.
Dette vil fungere også under alle løsningsalternativene som
skisseres senere i dokumentet. Om single sign-on vil være mulig
avhenger av hvordan brukerens nettleser og Office-klienten
samhandler om sesjoner. Normen i dag er at single sign-on
mellom disse ikke vil fungere. Dette ligger utenfor Feides
kontroll.
Office 365 online Dette scenariet er løst av mange organisasjoner, enten ved å
koble Azure AD eller ADFS med Feide.
V.1.9 Funn: type utstyr
Vi spurte vertsorganisasjonene hvilken type utstyr som er i bruk av ansatte, og i hvilken
grad utstyret er administrert.
Rapport
Side 67 av 157
Vi stilte samme spørsmål om utstyr for studenter/elever:
Vi ser at administrerte Windows-PC-er dominerer. Det er imidlertid også en vesentlig
mengde utstyr av andre typer, og det er mye utstyr som ikke er administrert.
Rapport
Side 68 av 157
V.1.10 Funn: lokal katalog for klientinnlogging for
ansatte
Vi spurte hvilken type lokale kataloger som brukes for klientinnlogging for ansatte.
Respondentene kunne angi flere alternativer, for eksempel hvis de bruker både lokal
Microsoft AD og Google Directory.
Vi ser at lokal Microsoft AD dominerer bildet og at en del har begynt å flytte ut til Azure
AD. Google Directory brukes også noe. I tillegg har vi fått følgende tilbakemeldinger under
svaralternativ «andre»:
• Adm av DotNet Internals
• ADFS
• Egen LDAP
• Fronter, Socrative m.fl.
• Lightspeed mot Feide-LDAP
• Visma flyt skole
• Cerebrum
• Samba
3%
4%
17%
76%
Google Directory med kopling mot Feide
Google Directory
Azure AD
Lokal Microsoft AD
Rapport
Side 69 av 157
V.1.11 Funn: type lokale innloggingsløsninger
Vi spurte hvilke innloggingsløsninger til tjenester som brukes utenom Feide. På samme
måte som for klientinnlogging, kunne respondentene angi flere alternativer. Vi fikk
følgende svar:
På samme måte som for klientinnlogging, er det lokal Microsoft AD som dominerer bildet.
MinId og BankId har også en viss utbredelse. Noen få har tatt i bruk social login. Under
svaralternativ «andre», fikk vi følgende svar:
• Weblogin (egen IdP, SAML2)
• Fronter, Socrative m.fl.
• LDAP
• OpenLDAP
• Office 365
• ADFS hos UiO
• Innlogginger fra innholdsleverandører (ofte utenlandske)
2%
3%
8%
9%
12%
14%
51%
Facebook/Twitter/annen social login
Google Directory
BankId
MinId
Azure AD
Lokal ADFS
Lokal Microsoft AD
Rapport
Side 70 av 157
• Identum
• Lokale hasher i databaser
• Egenutviklede løsninger
• PIN til studweb første gang
• Lokal supportweb, Lyderia
• NetIQ Access Manager (IDP)
V.1.12 Funn: gevinster
Vi spurte vertsorganisasjonene om hvilke gevinster de vil oppnå om man kopler sammen
Feide med lokale innloggingsløsninger. Respondentene kunne velge flere alternativer. Vi
fikk følgende svar:
I tillegg fikk vi følgende innspill til gevinster under svaralternativ «andre»:
• Jeg er usikker på sikkerheten når mange tjenester skal inn på samme pålogging. Vi
mangler foreløpig en tofaktor-pålogging, noe som bedrer sikkerheten, men kan gi noe
dårligere brukeropplevelse.
4%
5%
7%
12%
13%
19%
40%
Vi ser ingen direkte eller indirekte gevinster idette scenarioet
Ingen, for vi har allerede løst dette
Bedre omdømme for din organisasjon
Mindre arbeid for administrasjonen
Bedret sikkerhet
Mindre arbeid for IKT-avdelingen(e)
Bedre brukeropplevelse for de ansatte
Rapport
Side 71 av 157
• Vi har i stor grad løst dette. Løsningen er avhengig av konnektorer, så alle systemer er
ikke inne.
• Pålogging vil bli enklare dersom brukaren kan gå direkte inn på Feide-tenester etter
pålogging til AD
• Bedre brukeropplevelse for elevene.
• En tidstyv mindre
• Mindre sikkerhet
Tilsvarende spurte vi om hvilke gevinster vertsorganisasjonene mente man kunne få ved å
kople sammen Feide med andre innloggingsløsninger. Vi fikk følgende svar:
Andre gevinster:
• Vi har i hovedsak løst dette med samme brukernavn/passord til ulike tjenester. AD
styrer.
• Sparte SMS-utgifter eksisterende påloggingsløsninger.
4%
5%
7%
10%
10%
10%
14%
14%
27%
Vi ser ingen direkte eller indirekte gevinster idette scenarioet
Ingen, for vi har allerede løst dette
Bedre omdømme for din organisasjon
Bedret sikkerhet
Mindre arbeid for administrasjonen
Mindre arbeid for administrasjonen påskolene/universitetet/høyskolen
Mindre arbeid for lærere/forelesere
Mindre arbeid for IKT-organisasjonen sentralti din organisasjon
Bedre brukeropplevelse forelevene/studentene
Rapport
Side 72 av 157
Det dominerende gevinstområdet for begge scenarioer er bedret brukeropplevelse.
Dernest er det relativt jevnt mellom effektivisering, bedret sikkerhet og bedret
omdømme. Det er få vertsorganisasjoner som avviser at det er gevinster knyttet til
sammenkopling av Feide med lokale innloggingsløsninger.
V.1.13 Funn: finansiering og gjennomføringskapasitet
Vi ønsket å undersøke i hvilken grad vertsorganisasjonene vurderer at de har evne til å
håndtere løsningsalternativer som krever endringer lokalt. Følgende spørsmål ble stilt i
spørreundersøkelsen:
Dersom man velger et løsningsalternativ som krever lokale investeringer i IKT-
løsninger eller IKT-driftsorganisasjon: i hvilken grad har din organisasjon
tilgjengelige midler, kompetanse og kapasitet til slike endringer? Tenk på dette i
forhold til budsjettet for 2019.
Vi fikk følgende svar:
Vi ser at gjennomsnittet ligger under 3,0 for alle typer vertsorganisasjoner, unntatt for
fylkeskommuner. Andelen som har valgt 2 er mer enn dobbelt så høy som de som har valgt
4. Ingen har angitt at de har mye midler, tilgjengelig kompetanse og høy kapasitet.
Svar Totalt Universitet Fylkes-
kommune
Høgskole Kommune Privat
skoleeier
Annen
1 9 % 30 % 0 % 11 % 8 % 8 % 14 %
2 34 % 30 % 27 % 44 % 37 % 15 % 14 %
3 42 % 20 % 18 % 33 % 45 % 54 % 57 %
4 15 % 20 % 55 % 11 % 10 % 23 % 14 %
5 0 % 0 % 0 % 0 % 0 % 0 % 0 %
Snitt 2,6 2,3 3,3 2,4 2,6 2,9 2,7
Rapport
Side 73 av 157
Tilsvarende undersøkte vi viljen til å betale mer for den sentrale Feide-leveransen fra
UNINETT:
Noen løsningsalternativer vil medføre økte kostnader sentralt og dermed økt
tilknytningsavgift til Feide. I hvilken grad vil din organisasjon være villig til å
betale mer for å knytte sammen Feide med lokale påloggingsløsninger?
Vi fikk følgende svar:
Vi ser igjen den samme fordelingen som svarene på tilsvarende spørsmål om lokale
ressurser med en vekting mot svaralternativer under 3 i forhold til svaralternativer over 3.
En hypotese kan være at investeringsviljen er høyere for vertsorganisasjoner som uttrykker
ønske om at det prioriteres høyt å løse problemer med sammenkopling av lokale
innloggingsløsninger med Feide. Vi har to scenarioer hvor vi har undersøkt prioritet:
• Sammenkopling med klientinnlogging
• Sammenkopling med andre innloggingsløsninger
For å undersøke hypotesen, har vi oversatt svarene på disse spørsmålene til tall, hvor 1
tilsvarer høy prioritet, 2 tilsvarer lav prioritet og 3 tilsvarer ingen prioritet eller at det ikke
anses å være et problem. Vi forventer da en negativ korrelering. Her er resultatene av
krysskoplingen mellom de to scenarioene med spørsmålene om henholdsvis lokale og
sentrale investeringer:
Svar Totalt Universitet Fylkeskom
mune
Høgskole Kommune Privat
skoleeier
Annen
1 10 % 14 % 0 % 6 % 12 % 14 % 0 %
2 36 % 14 % 0 % 50 % 36 % 50 % 40 %
3 42 % 71 % 75 % 39 % 39 % 29 % 50 %
4 12 % 0 % 25 % 6 % 13 % 7 % 10 %
5 0 % 0 % 0 % 0 % 0 % 0 % 0 %
Snitt 2,6 2,6 3,3 2,4 2,5 2,3 2,7
Rapport
Side 74 av 157
Vi ser at for alle fire varianter er det - som forventet – en svak negativ korrelering mellom
investeringsvilje og prioritet, r. Kvadratet av korreleringskoeffisienten, r2, uttrykker
graden av forklaringsevne. Den høyeste sammenhengen er for prioritet av sammenkopling
med klientinnlogging og viljen til å investere mer i Feide sentralt med 3,7 %. Det kunne
vært gjennomført en formell hypotesetest, men med så lave verdier for r2 er det åpenbart
at det ikke er noen korrelasjon. Dette betyr ikke nødvendigvis at det ikke finnes noen
årsakssammenheng, men vi har altså ikke avdekket noen sammenheng gjennom denne
spørreundersøkelsen.
r -0,037 r -0,193
r2 0,001 r2 0,037
Prioritet Prioritet
Vurdering 1 2 3 Totalt Vurdering 1 2 3 Totalt
1 3 6 8 17 1 2 5 12 19
2 16 23 24 63 2 12 23 32 67
3 17 25 36 78 3 25 28 26 79
4 7 12 8 27 4 5 11 7 23
5 0 0 0 0 5 0 0 0 0
Blank 2 3 3 8 Blank 1 2 2 5
Totalt 45 69 79 193 Totalt 45 69 79 193
Lokale investeringer vs sammenkopling
med klientinnlogging
Sentrale investeringer vs sammenkopling
med klientinnlogging
r -0,014 r -0,116
r2 0,000 r2 0,013
Prioritet Prioritet
Vurdering 1 2 3 Totalt Vurdering 1 2 3 Totalt
1 1 5 11 17 1 2 6 11 19
2 19 19 25 63 2 13 15 39 67
3 13 22 43 78 3 21 27 31 79
4 7 8 12 27 4 4 8 11 23
5 0 0 0 0 5 0 0 0 0
Blank 1 4 3 8 Blank 1 2 2 5
Totalt 41 58 94 193 Totalt 41 58 94 193
Lokale investeringer vs sammenkopling
med lokale innloggingsløsninger
Sentrale investeringer vs sammenkopling
med lokale innloggingsløsninger
Rapport
Side 75 av 157
Konklusjonen fra disse spørsmålene i spørreundersøkelsen er at det er flere som
uttrykker svak investeringsvilje enn de som uttrykker sterk investeringsvilje. Videre er
det ingenting som tyder på at investeringsviljen har sammenheng med prioriteringen av
behovet for sammenkopling av Feide med lokale innloggingsløsninger
V.1.14 Funn: andre tilbakemeldinger
En del tilbakemeldinger peker på at det var vanskelig å besvare spørreundersøkelsen og at
man savnet en finere granulering av svaralternativer. Vi tar kun videre konklusjoner fra
spørreundersøkelsen som synes tydelige og som er støttet opp av andre kilder.
Vi fikk en tilbakemelding som melder at sammenkopling er negativt prioritert: at en slik
sammenkopling vil føre til merarbeid. Spørreundersøkelsen hadde ingen kategori for å
fange opp dette, så det er vanskelig å vite hvor mange andre som har denne oppfatningen.
Vi er glade for tilbakemeldingene fra de respondentene som takket for at dette arbeidet er
påstartet!
Se vedlegg 4 for en gjengivelse av svarene vi fikk på spørsmålet om det var andre
tilbakemeldinger til oss.
Rapport
Side 76 av 157
Vedlegg 2: Spørsmålene i
spørreundersøkelsen
Rapport
Side 77 av 157
Rapport
Side 78 av 157
Rapport
Side 79 av 157
Rapport
Side 80 av 157
Rapport
Side 81 av 157
Rapport
Side 82 av 157
Rapport
Side 83 av 157
Rapport
Side 84 av 157
Rapport
Side 85 av 157
Rapport
Side 86 av 157
Rapport
Side 87 av 157
Vedlegg 3: Svar på spørsmål om
andre scenarioer
Vi stilte spørsmålet: «Er det andre bruksscenarioer hvor dere savner sammenkopling av
Feide med lokale innloggingsløsninger?». Punktlistene under gjengir tilbakemeldingene vi
fikk, rensket for svarene «nei» og «vet ikke».
Universiteter
• Brukeren er logget på en webtjeneste med lokal innlogging og blir sendt til en til
tjeneste som bruker FEIDE/Dataporten. Ønsker minimal friksjon.
• Der vi har lokal innlogging er det normalt med vilje at web SSO ikke virker
Fylkeskommuner
• Elever og ansatte logger inn på Wifi via Radius. Ansatte gjør dette sømløst da de har AD-
pålogging på PC og Wifi bruker samme brukernavn for innlogging. Elever mangler dette
og må logge på Wifi manuelt. Fylkeskommunen har valgt å ikke bruke AD for elever slik
at vi ikke ser noen løsning på dette.
• Innlogging til lokal printløsning for elever med maskiner utenfor AD.
• Støtte lokale TOTP løsninger
Høgskoler
• Kryssfederering mellom FEIDE og lokal IDP
• Lms, inventarsystem, rombooking, contempus, kameraovervåking, adgangskontroll
systemer, SAP(?)
• Office 365
• På et litt høyere nivå. Å kunne logge seg inn i td Canvas på tvers av institusjoner. Døme:
kommunale feideinstitusjoner logger seg inn i våres canvas.
Kommuner
• Ansatte kan ikke logge inn med feide på kommunens system. De må huske både feide og
kommuneinnlogging. Det vanlige er å bruke chromebook til skolearbeid og windowsPC til
kommunerelatert arbeid. Men det er også mulig å bruke Citrix fra Chromebook for å
Rapport
Side 88 av 157
logge på kommunens intranett. Dette er en utfordring vi gjerne skulle løst på en enklere
måte.
• Automatisk innlogging i lokal Office-programvare (mot Office 365 konto)
• Fagsystemer og webapplikasjoner utenfor oppvekst-sektoren. For eksempel helse og
omsorg.
• Feide kontoer for øvrige ansatte i kommunen
• Feide mot Office online viste seg for oss å ikke være rett frem. Det brukes derfor ADFS,
men når elevene har få beskjed om å bruke Feide over alt, så blir dette knotete. Det er
også litt knotete på en den del brukerflater.
• Grue vil gjerne ha feide-pålogging i Fronter www.fronter.com/hedmarkgs
• It’s learning
• Kommunen kjøper ikke tjenester som ikke er Feide-kompatible.
• Lærere bør kunne få sømløs tilgang til lokale tjenester (for eksempel sak/arkiv, ERP, og
lignende) når de er innlogget med sterk feide.
• Mot læringsplatformen It's learning
• Mot voksenopplæringens fagsystem (Visma Flyktning) som lærerne benytter
• Spes ped. programvare som ikke har en egen nettløsning med FEIDE-pålogging.
• Vi bruker i dag Fronter to AD for elever, men bytter nok til en annen løsning.
• Vi har problemer med å få nye brukere inn på Feide
• Vi ser det som en fordel at elevene / lærere kan få SSO til Feide-tjenester etter at de
har logget seg inn på sin Google-konto/ Chromebook.
• Visma Flyt, linker i Zokrates
Private skoleeiere
• Mot div. wordpress-siter
• Vi har noen skjemaer på en wordpress platform, hadde vært interesang å kunne ha
feide pålogging for å kunne få tilgang på skjema hvor en del felter kan bli auto fullført
med bruker infoen
Andre organisasjonstyper
• Generelt er det ønskelig at når en ansatt eller student logger seg på pc/mac som
domenebruker på internt nett, har hun samtidig SSO til nettbaserte tjenester som
BIBSYS Oria.
Rapport
Side 89 av 157
Vedlegg 4: Svar på spørsmål om
andre tilbakemeldinger
Vi stilte spørsmålet: «Har dere andre tilbakemeldinger til oss?». Punktlistene under gjengir
tilbakemeldingene vi fikk.
Universiteter
• Jeg er tekniker og kan egentlig ikke si noe om vi (UIT) har midler til dette. Siden jeg
måtte svare på dette for å komme videre i dette skjemaet, valgt jeg noe som var midt
på treet.
• Vi har mer fokus på utvidet federering enn kobling til lokale tjenester
Fylkeskommuner
• Hva med å tilby FEIDE som skytjeneste? Det begynner å bli utdatert med alle
installasjonene som står rundt omkring.
• Svarene i denne undersøkelsen er basert på situasjonen i Nord-Trøndelag
fylkeskommune. Fra 1.1.2018 vil Nord- og Sør-Trøndelag slå seg sammen til Trøndelag
fylkeskommune.
• Vanskelig å svare på vegne av alle fagområder i vår organisasjon. Det kan være at
utdanningssjef samt våre folk på klientdrift og AD ville svart annerledes.
Høgskoler
• idp.feide.no - når kommer IPv6?
Kommuner
• Alle oppsett som vedkommer FEIDE og pålogging blir styrt av eKommune Sunnmøre, der
IKT avd i Ålesund kommune er sentral.
• Dette var en for vanskelig undersøkelse for en «vanlig» administrator. Blir for teknisk,
men har prøvd så godt jeg kunne.
• Effekten av SSO FEIDE og andre ikke-FEIDE-tjenester er overvurdert og fører til mer
kluss og arbeid enn gevinst. Effekten av FEIDE er best om tjenesten direkte støtter
FEIDE.
Rapport
Side 90 av 157
• Feide er en suksess i skole-Norge. Kanskje eneste IKT-prosjekt vi syns har lyktes fullt ut.
• Finnes det noe planer om å integrere FEIDE med ID-porten?
• Intet spesielt. Tjenesten fungerer fint.
• Kunne heller sett for meg en løsning Microsoft Office365 identitet, erstatter Feide, eller
at Feide integreres med Azure AD, og alle maskinene er Azure AD joinede isteden for
meldt inn i lokalt AD domene, jeg trur vel det er den veien dette går..
• Skulle gjerne gradere svaralternativene fra 1-10 skala for å at det dekker svarene godt
nok, spesielt de 2 siste spørsmålene.
• Takk for at dere jobber med dette! Ta gjerne kontakt om noe er uklart!
• Ved innføring av Feide, løftet vi prosjektet opp til fulldigitalisert identitetsforvaltning i
for alle ansatte i kommunen og for elever i skolen. Løsningen ivaretar singel-sign-
on/simplified-sing-on
• Vi er en forvalter av løsningene til kommunene. Vår økonomi til slike ting er styrt av hva
kommunene ønsker å bruke pengene på. Vi har i utgangspunktet ikke slike midler.
• Ønsker kontakt for evt. å kunne få en løsning med Feide som identitetsforvalter for hele
organisasjonen
Rapport
Side 91 av 157
Vedlegg 5: Løsningsalternativer
V.5.1 Dagens føderasjon
Beskrivelse
Dagens føderasjon består av en sentral innloggingstjeneste (SAML IdP) med
autentiseringspunkter (Feide-kataloger) ute ved hver vertsorganisasjon.
Innloggingstjenesten lar brukeren velge hvilken vertsorganisasjon han kommer fra. Dette
huskes i nettleseren for bruk ved senere innlogginger på tjenester. Innloggingstjenesten gir
så brukeren en webflyt for å autentisere seg med brukernavn, passord og eventuelt sterk
autentisering med engangskode. Det lokale autentiseringspunktet, Feide-katalogen,
verifiserer at passordet er korrekt, brukeren finnes og er aktiv og holder på
personopplysningene som sendes videre til tjenestene.
All innlogging gjøres på den sentrale innloggingstjenesten, mens brukerstatus og
oppbevaring av personopplysninger gjøres ved hver vertsorganisasjon i Feide-katalogen.
Ved innlogging på den sentrale tjenesten sjekkes passordet brukeren skriver inn ved å
logge på den lokale brukerkatalogen og personopplysninger om brukeren hentes ut og
returneres til den sentrale innloggingstjenesten.
Alle tjenester som er med i føderasjonen integrerer seg med den samme sentrale
innloggingstjenesten, og hver vertsorganisasjon kobler seg opp til innloggingstjenesten på
lik måte. Tjenesten er lagt opp til å være forutsigbar for alle aktører og samme
funksjonalitet presenteres til alle tjenester og alle vertsorganisasjoner.
Lik funksjonalitet til alle gir begrensninger i lokale tilpassinger, både på tjeneste- og
vertsorganisasjonssiden. For eksempel er det i dag ikke mulig å koble andre lokale
autentiseringsløsninger inn i føderasjonen, sterk autentisering er begrenset til de
metodene som leveres sentralt og lignende.
Disse begrensningene er en av årsakene til at denne behovskartleggingen ble startet.
Utfordringen er å finne balansen mellom en forutsigbar løsning og spesifikke behov som er
vanskelige å løse innenfor dagens rammer.
Rapport
Side 92 av 157
Tekniske sammenkoplinger
Figuren viser et bilde av sammenhengen mellom tjenester (SP 1, SP 2 og så videre), Feides
innloggingstjeneste (nøkkelhullet) og vertsorganisasjonene (org A, org B og så videre):
• Alle tjenester integrerer seg med et punkt for å nå alle vertsorganisasjoner. Protokollen
som benyttes mellom tjenester og innloggingstjenester kan brukes på mange måter og
det er variasjoner. Innloggingstjenesten støtter en del variasjoner i hvordan en tjeneste
kommuniserer og tilpasser seg disse. Om en tjeneste kommuniserer på en måte som
innloggingstjenesten ikke støtter må vanligvis tjenesten tilpasse seg føderasjonen. I
enkelte tilfeller der det er hensiktsmessig tilpasses føderasjonen tjenesten og
funksjonaliteten gjøres tilgjengelig for alle tjenester.
• Alle vertsorganisasjoner kobler seg til innloggingstjenesten på samme måte, med en
lokal brukerkatalog. Det er satt krav til hvilken informasjon som skal være tilgjengelig
for tjenester og som vertsorganisasjonen må påse er i den lokale katalogen.
SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP 7
Org A Org B Org DOrg C
550 Feide-tjenester og 1700 eduGAIN-tjenester
503 vertsorganisasjoner
17700+
sammen-
koblinger
Rapport
Side 93 av 157
• All administrasjon av hvilke tjenester som skal være åpne for hvilke vertsorganisasjoner
gjøres i en sentral tjeneste, gjennom selvbetjening for tjenesteleverandører og
vertsorganisasjoner i Feides kundeportal. Hver tjeneste får utlevert samme informasjon
om en bruker uavhengig av hvilken organisasjon brukeren kommer fra, så fremt
informasjonen finnes i den lokale brukerkatalogen.
Hvis vi ser dette fra synspunktet til en vertsorganisasjon, ser bildet slik ut:
• Feide er som regel en av flere autentiseringsløsninger som benyttes ved en
vertsorganisasjon. Brukernavn og passord er ofte synkronisert mellom
autentiseringsløsningene, men de henger ikke sammen i ett single sign-on domene.
Dette medfører for eksempel at selv om en bruker har logget inn på en klient (laptop
el.l.) må han logge inn på nytt i Feide når han går til en Feide-tjeneste.
• De aller fleste har et lokalt AD som klienter autentiserer mot. Tradisjonelle
klientapplikasjoner gjenbruker gjerne denne autentiseringen.
• For Feide-føderasjonen har vertsorganisasjonen en Feide-katalog som benyttes av
innloggingstjenesten.
SP 1 SP 3 SP 4 SP 7
Org D
K 1
K 2
Lokal
SP 1
Lokal
SP 2 Lokal
SP 3
SAML2 – org profil
SP 2 SP 5 SP 6
Rapport
Side 94 av 157
• Enkelte vertsorganisasjoner, gjerne større organisasjoner, har i dag også en ’lokal
føderasjon’ der de plasserer lokale webtjenester som benyttes i organisasjonen. Dette
kan være egenutviklede tjenester eller tjenester de kjøper hos leverandører,
skytjenester og lignende.
Sett fra en tjeneste, ser bildet slik ut:
• Uavhengig av hvilke vertsorganisasjoner som skal benytte tjenesten integreres tjenesten
med et punkt for autentisering. Teknisk sammenkobling mellom tjenesten og en
vertsorganisasjon gjøres i Feides kundeportal med gjensidig åpning mellom tjenesten og
organisasjonen.
• Hvilken informasjon som blir utlevert til tjenesten er avtalt og satt på den sentrale
innloggingstjenesten og er lik for alle vertsorganisasjoner.
• Det er i dag ikke mulig for en tjeneste å be om annen informasjon for gitte
vertsorganisasjoner, og det er ikke mulig for en vertsorganisasjon å reservere seg fra å
sende gitte informasjonselementer til tjenesten.
SP 1
Org A Org B Org DOrg C
Rapport
Side 95 av 157
Eksempel på innloggingsflyt fra utstyr med klientinnlogging
Et eksempel på flyten ved bruk av en Feide-tjeneste fra utstyr hvor brukeren logger inn på
klient, som er i et AD-domene, med bruker utlevert av vertsorganisasjonen:
Steg:
1. Brukeren logger på sin lokale PC
2. Innloggingen valideres av AD og det opprettes en Kerberos-sesjon
3. Brukeren benytter en Feide-tjeneste
4. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
5. Feide spør om organisasjonstilknytning, om dette ikke er valgt tidligere i Feide
6. Feide spør om brukernavn og passord
Rapport
Side 96 av 157
7. Innloggingen valideres mot vertsorganisasjonens Feide-katalog
8. Feide returnerer avtalt informasjon om brukeren til tjenesten
9. Brukeren har tilgang til tjenesten
Dagens flyt har altså ingen sømløs pålogging mellom innlogging på klienten og Feide-
tjenesten. Den lokale organisasjonen har som regel en synkronisering av brukernavn og
passord mellom AD (blå trekant i figuren) og Feide-katalogen (rød database i figuren), men
det er ingen kopling som gjør at Kerberos-sesjonen kan gjenbrukes: brukeren må oppgi
brukernavn og passord på nytt ved innlogging på første Feide-tjeneste.
Eksempel på innloggingsflyt fra eget utstyr
Et eksempel på flyten ved bruk av en Feide-tjeneste fra eget utstyr er som følger:
Rapport
Side 97 av 157
Steg:
1. Brukeren benytter en Feide-tjeneste
2. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
3. Feide spør om organisasjonstilknytning, om dette ikke er valgt tidligere i Feide
4. Feide spør om brukernavn og passord
5. Innloggingen valideres mot vertsorganisasjonens Feide-katalog
6. Feide returnerer avtalt informasjon om brukeren til tjenesten
7. Brukeren har tilgang til tjenesten
I dette tilfellet er ikke klienten som brukeren benytter medlem av et AD-domene og det er
ikke noen Kerberos-sesjon inne i bildet.
Rapport
Side 98 av 157
Eksempel på innloggingsflyt på neste Feide-tjeneste
Et eksempel på flyten ved bruk av neste Feide-tjeneste:
Steg:
1. Brukeren benytter neste Feide-tjeneste
2. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
3. Brukeren har allerede en autentisert Feide-sesjon
4. Feide returnerer avtalt informasjon om brukeren til tjenesten
5. Brukeren har tilgang til tjenesten
Rapport
Side 99 av 157
Uavhengig av om brukeren er på en klient med eller uten AD-tilknytning så vil innlogging
på neste Feide-tjeneste foregå gjennom single sign-on og brukeren slipper å velge
organisasjon og å autentisere seg.
V.5.2 Alternativ 1: Mesh
Beskrivelse
En klassisk mesh-føderasjon er i sin reneste form en policyføderasjon med et par
støttetjenester. Hver vertsorganisasjon har sin egen innloggingstjeneste. Hver tjenestene
vil integrere seg med hver av sine kunders innloggingstjeneste.
Mesteparten av avtaler, tekniske løsninger, drift og support ligger hos den enkelte
vertsorganisasjon og tjenesteleverandør.
De sentralt driftede støttetjenestene er gjerne statistikkaggregering på føderasjonsnivå og
en ’oppslagstjeneste’ som gjør det lettere for tjenester og vertsorganisasjoner å finne
hverandre.
Mange utdanningsføderasjoner har denne formen, for eksempel Storbritannias UK
Federation og USAs InCommon. På grunn av disse store brukermassene er det mange
internasjonale tjenester som forventer dette oppsettet.
En full overgang til en slik føderasjon vil medføre at alle tjenester og vertsorganisasjoner
må endre sine tekniske løsninger.
Med større sentrale grep vil det være mulig å lage hjelpesystemer som gjør det lettere for
tjenester og vertsorganisasjoner å integrere seg. Avhengig av ønsket funksjonalitet og
ressurstilgang kan føderasjonen være alt fra en ren policyføderasjon til å ha et sentralt
punkt slik som i dag, der all kommunikasjon går gjennom, men som logisk er en klassisk
mesh der alle kommuniserer med alle.
Under viser vi tre forskjellige tekniske sammenkoblinger, men flere varianter er mulig.
Rapport
Side 100 av 157
Tekniske sammenkoplinger
Figuren viser et bilde av sammenhengen i en klassisk mesh-føderasjon:
• Alle tjenester integrerer seg med innloggingstjenesten til sine kunder. Spesielle behov
utover det som er føderasjonens SAML2-profil i hvordan tjenesten og kundens
innloggingstjeneste skal kommunisere avtales mellom tjenesteleverandør og kunde.
• Alle vertsorganisasjoner har sin egen innloggingstjeneste som tjenester integrerer seg
med.
• Tjenester og vertsorganisasjoner avtaler sammenkobling seg imellom, og avtaler hvilke
informasjonselementer som skal utleveres til tjenesten.
SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP 7
550 Feide-tjenester og 1700 eduGAIN-tjenester
503 vertsorganisasjoner
Org DOrg COrg BOrg A
17700+
sammen-
koblinger
Rapport
Side 101 av 157
Figuren under viser en variant hvor noen (de fleste) av vertsorganisasjonene velger å
fortsette med dagens løsning for tilknytning til Feide, og noen velger å stå i direkte
knytning til tjenestene:
• For vertsorganisasjoner som forsetter med dagens løsning blir det ingen endring i lokalt
oppsett eller hvordan de tar i bruk tjenester.
• For de som ønsker en klassisk mesh vil endringen bli som beskrevet over, både for
vertsorganisasjoner og tjenester
• Føderasjonen måtte fortsette med dagens sentrale løsninger og levere de nye
støttesystemene for klassisk mesh.
Det tredje alternativet vi viser er en løsning med mange sentrale støttesystemer: en
hybrid mesh. I en overgangsperiode, eller permanent, vil vertsorganisasjoner og
tjenesteleverandører kunne fortsette som i dag, men de som ønsker det kan ta i bruk en
klassisk mesh-arkitektur med egen innloggingstjeneste og variasjoner i hvilken informasjon
som utveksles. Teknologisk vil dette være to mesher, en front-mesh som tjenestene som
SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP 7
550 Feide-tjenester og 1700 eduGAIN-tjenester
503 vertsorganisasjoner
Org DOrg C
17700+
sammen-
koblinger
Org A Org B
Rapport
Side 102 av 157
ønsker/trenger det ser og en backend-mesh som vertsorganisasjonene som ønsker det ser.
Logisk sett kan det ses på som én klassisk mesh føderasjon slik som alternativene beskrevet
over.
• For vertsorganisasjoner som forsetter med dagens løsning blir det ingen endring i lokalt
oppsett eller hvordan de tar i bruk tjenester.
• For de som ønsker klassisk mesh vil sentrale støttesystemer skjule mye av
kompleksiteten både for tjenesteleverandører og vertsorganisasjoner.
• Tjenester vil kunne integrere seg med et sentralt punkt, men må ha noe spesifikk
konfigurasjon for hver vertsorganisasjon. De kan be om avvikende informasjon fra
enkelte vertsorganisasjoner.
• Vertsorganisasjoner vil kunne forholde seg til tjenester som kommuniserer på samme
måte mot deres innloggingstjeneste, og de kan avvike fra standardoppsettet rundt
hvilken informasjon som gis til tjenestene.
• Føderasjonen måtte fortsette med dagens sentrale løsninger og levere de nye
støttesystemene for klassisk mesh.
Rapport
Side 103 av 157
Hvis vi ser dette fra synspunktet til en vertsorganisasjon som velger å stå i direkte kontakt
med tjenestene, vil bildet se slik ut uavhengig av grad av sentrale støttesystemer:
• De aller fleste har et lokalt AD som klienter autentiserer mot. Tradisjonelle
klientapplikasjoner gjenbruker gjerne denne autentiseringen.
• Vertsorganisasjonen har en lokal innloggingstjeneste der de plasserer lokale
webtjenester som benyttes i organisasjonen. Dette kan være egenutviklede tjenester
eller tjenester de kjøper hos leverandører, skytjenester og lignende.
• Den lokale innloggingstjenesten kan settes opp til å knytte sammen AD-domenet og sitt
SSO-domene slik at klientinnlogging gjenbrukes på denne.
• Feide-tjenester knyttes til den lokale innloggingstjenesten, enten direkte eller gjennom
et sentralt støttesystem.
SP 1 SP 3 SP 4 SP 7
Org D
K 1
K 2
Lokal
SP 1
Lokal
SP 2 Lokal
SP 3
SP 2 SP 5 SP 6
Rapport
Side 104 av 157
Sett fra en tjeneste, ser bildet slik ut. Avhengig av graden av støttesystemer vil
integrasjonen enten gå mot hver av organisasjonene eller et sentralt punkt. Koblingen vil
uansett kunne administreres som om tjenesten integreres med hver organisasjon.
• Uten sentrale støttesystemer må tjenesten integreres med hver organisasjon og
gjennomføres separat. Med støttesystemer vil man kunne integrere på samme måte for
alle vertsorganisasjoner på et sted.
• Hvilken informasjon som blir utlevert til tjenesten kan avtales for hver
vertsorganisasjon.
• En tjeneste kan be om annen informasjon for gitte vertsorganisasjoner, og en
vertsorganisasjon kan reservere seg fra å sende gitte informasjonselementer til
tjenesten.
SP 1
503 integrasjonspunkter
Org DOrg COrg BOrg A
Rapport
Side 105 av 157
Eksempel på innloggingsflyt fra utstyr med klientinnlogging
Et eksempel på flyten ved bruk av en Feide-tjeneste fra utstyr hvor brukeren logger inn på
klient med bruker utlevert av vertsorganisasjonen:
Steg:
1. Brukeren logger på sin lokale PC
2. Innloggingen valideres av AD og det opprettes en Kerberos-sesjon
3. Brukeren benytter en Feide-tjeneste
4. Feide-tjenesten spør om organisasjonstilknytning
5. Feide-tjenesten kontakter vertsorganisasjonen direkte over SAML2
Rapport
Side 106 av 157
6. Vertsorganisasjonen ser at det finnes en lokal sesjon allerede og gjenbruker denne
(SSO)
7. Vertsorganisasjonen returnerer avtalt informasjon om brukeren til tjenesten
8. Brukeren har tilgang til tjenesten
Denne flyten gir altså sømløs pålogging mellom klientinnloggingen og Feide-tjenesten.
Avhengig av hvilke støttesystemer som er på plass vil det kunne stå et sentralt punkt
mellom tjenesten og lokal innloggingstjeneste som kanskje kan hjelpe tjenesten med
organisasjonsvalg og vertsorganisasjonen med tilpassing av kommunikasjon til tjenesten.
Rapport
Side 107 av 157
Eksempel på innloggingsflyt fra eget utstyr
Et eksempel på flyten ved bruk av en Feide-tjeneste fra eget utstyr er som følger:
Steg:
1. Brukeren benytter en Feide-tjeneste
2. Feide-tjenesten spør om organisasjonstilknytning
3. Feide-tjenesten kontakter vertsorganisasjonen direkte over SAML2
4. Vertsorganisasjonen finner ingen lokal klientsesjon, og spør om brukernavn og passord
5. Vertsorganisasjonen returnerer avtalt informasjon om brukeren til tjenesten
6. Brukeren har tilgang til tjenesten
Rapport
Side 108 av 157
Avhengig av hvilke støttesystemer som er på plass vil det kunne stå et sentralt punkt
mellom tjenesten og lokal innloggingstjeneste som kanskje kan hjelpe tjenesten med
organisasjonsvalg og vertsorganisasjonen med tilpassing av kommunikasjon til tjenesten.
Eksempel på innloggingsflyt på neste tjeneste
Et eksempel på flyten ved bruk av neste tjeneste:
Steg:
1. Brukeren benytter neste tjeneste. Med en lokal tjeneste trenger ikke brukeren å velge
organisasjon han kommer fra. For en Feide-tjeneste må organisasjonsvalg gjøres på
nytt.
2. Tjenesten kontakter lokal innloggingstjeneste for innlogging over SAML2-protokollen
3. Brukeren har allerede en autentisert sesjon
Rapport
Side 109 av 157
4. Vertsorganisasjonen returnerer avtalt informasjon om brukeren til tjenesten
5. Brukeren har tilgang til tjenesten
Uavhengig av om brukeren er på en klient med eller uten AD-tilknytning så vil innlogging
på neste tjeneste foregå gjennom SSO og brukeren slipper å autentisere seg. Her illustrert
med en lokal tjeneste. Hadde dette vært en ny Feide-tjeneste måtte organisasjon settes
på nytt, enten av brukeren selv i tjenesten eller et nytt støttesystem som hjelper
tjenesten å velge organisasjon.
Kostnadspåvirkninger
Føderasjon. I en mesh-føderasjon flyttes de aller fleste oppgavene som i dag gjøres
sentralt over på hver vertsorganisasjon og tjenesteleverandør. Avhengig av hvor mange og
omfattende støttesystemer som lages sentralt vil det kunne avhjelpe en del av det lokale
arbeidet.
Sentralt Lokalt
Forvalte informasjonsmodell og tillitsnettverk ✔
Forvalte SAML2-profil ✔
Håndtere konfigurasjon for tjenester og andre vertsorganisasjoner
✔ ✔
Følge opp endringer i nasjonale krav og føringer ✔ ✔
Følge opp endringer i eduGAINs krav og føringer ✔ ✔
Holde eduGAIN metadata oppdatert med vertsorganisasjoner og tjenester
✔ ✔
Tilpasse tjenester til å støtte Feides SAML2-profil ✔
Kontroll av personer ved utlevering av brukerkonto ✔
Support. I en ren føderasjon flyttes alle supportoppgaver som i dag gjøres sentralt over på
hver vertsorganisasjon og tjenesteleverandør. Avhengig av hvor mange og omfattende
støttesystemer som lages sentralt vil det kunne avhjelpe en del av det lokale arbeidet.
Supportoppgaver som i dag er lokale fortsetter å være lokale.
Sentralt Lokalt
Førstelinje for sluttbrukere
✔
Rapport
Side 110 av 157
Sentralt Lokalt
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔ ✔
Ved oppkobling av nye tjenester, og oppdatering av tjenester ✔ ✔
Innloggingsfeil og -sporing - for vertsorganisasjoner ✔ ✔
Innloggingsfeil og -sporing - for tjenesteleverandører ✔ ✔
Sporing for CERT, jukseprosess og lignende ✔ ✔
Henvendelser fra eduGAIN-organisasjoner og -tjenester ✔ ✔
Datakvalitet ved vertsorganisasjon. I en mesh-føderasjon vil vi ikke kunne benytte de
verktøyene vi har sentralt i dag som sjekker datakvaliteten. Dette må gjøres lokalt for de
forskjellige teknologiske plattformene vertsorganisasjonen benytter. Avhengig av hvor
mange og omfattende nye støttesystemer som lages sentralt vil det kunne avhjelpe en del
av det lokale arbeidet.
Sentralt Lokalt
Holde datakvaliteten oppe
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔ ✔
Sjekk av kvalitet ved behov/ønske ✔ ✔
Løpende oversikt over kvalitet ved innlogginger ✔ ✔
Innloggingstjeneste for web. I en mesh-føderasjon vil vi ikke kunne benytte dagens
innloggingstjeneste og de verktøyene vi har sentralt i dag som støtter opp under denne.
Vertsorganisasjonene må ha egne innloggingstjenester som støtter tjenestene de benytter.
Med egen innloggingstjeneste vil det ikke lenger være bruk for dagens lokale Feide-
brukerkatalog. Avhengig av hvor mange og omfattende støttesystemer som videreutvikles
og lages sentralt vil det kunne avhjelpe en del av det lokale arbeidet.
Sentralt Lokalt
Støtte SAML2-profil for Feide ✔ ✔
Støtte SAML2-profil for eduGAIN ✔ ✔
Tilgangskontroll tjenester/vertsorg (gjensidig åpning) ✔ ✔
Rapport
Side 111 av 157
Sentralt Lokalt
Tilgangskontroll informasjonselementer (attribute release policy)
✔ ✔
Oversettelse av attributtformater etter tjenestens behov ✔ ✔
Universell utforming, responsiv design, gjenkjennbarhet ✔ ✔
Drift av IdP eksponert mot verden ✔ ✔
Tilgjengelighet, redundans, sikkerhet og DDoS-beskyttelse mot verden osv
✔ ✔
Drift av LDAP-katalog eksponert mot Feide ✔
Sterk autentisering. I en mesh-føderasjon vil vi ikke kunne benytte dagens løsning for
sterk autentisering. Vertsorganisasjonene må ha egne løsninger for dette som tilfredsstiller
kravene i offentlig sektor. Det vil være mulig med en mye større variasjon i hvilke metoder
som benyttes. Avhengig av hvor mange og omfattende støttesystemer som videreutvikles
og lages sentralt vil det kunne avhjelpe en del av det lokale arbeidet.
Sentralt Lokalt
Tilby sterk autentisering (nivå 3 nå, sannsynligvis nivå 4 senere)
✔ ✔
Administrere bruk av sterk autentisering mot tjenester ✔ ✔
Blokkere tilgang til tjenester om bruker ikke er sterkt nok autentisert
✔ ✔
Tjenestestartet sterk autentisering ved behov ✔ ✔
Statistikk. I en mesh-føderasjon vil ikke kommunikasjonen mellom tjenester og
vertsorganisasjoner gå gjennom en sentral innloggingstjeneste. Statistikk om bruken av
tjeneste vil bli distribuert utover mange innloggingstjenester. Dette løses ofte med at
lokale innloggingstjenester sender aggregert statistikkinformasjon til et sentralt
støttesystem. Mer detaljert statistikk håndteres lokalt i tjenester og innloggingstjenester.
Rapport
Side 112 av 157
Avhengig av hvor mange og omfattende støttesystemer som videreutvikles og lages sentralt
vil det kunne avhjelpe en del av det lokale arbeidet.
Sentralt Lokalt
Statistikk for føderasjonen som helhet (rapportering til KD o.l.)
✔
Statistikk for vertsorganisasjon rundt bruk av tjenester i føderasjonen
✔ ✔
Statistikk for tjenesteleverandører om bruk gjennom føderasjonen
✔ ✔
Statistikk til aggregering (+)
✔
Funksjonalitet til Dataporten. I en mesh-føderasjon vil vi ikke kunne benytte dagens
integrasjoner mellom Dataporten og vertsorganisasjonene. Disse benytter seg av dagens
Feide-katalog som i en mesh ikke vil eksistere lenger. Nye måter å realisere samme
funksjonalitet må lages.
Sentralt Lokalt
Tilby innlogging, sterk autentisering, tjenestestartet sterk autentisering
✔ ✔
Tilby brukerinformasjon i og utenfor innloggingssesjon ✔ ✔
Tilby gruppeinformasjon (Administrerte grupper) ✔ ✔
Tilby personsøk ✔ ✔
Policypåvirkninger
En helt eller delvis overgang til mesh-føderasjon vil føre til at alle kontrakter må
omarbeides. Ansvarsforhold endres og må reflekteres inn i avtalene.
Policyer rundt informasjonsmodell og hvordan disse representeres vil trenge en
gjennomgang, men ikke nødvendigvis endres.
Betalingsmodellen må endres. Det blir enda mer unaturlig å ta betaling fra
tjenesteleverandører for bruk av innloggingstjenesten/innloggingstjenester. Mengden av
utvikling, videreutvikling, drift og support av sentrale støttekomponenter vil påvirke
betalingsmodellen for vertsorganisasjoner.
Rapport
Side 113 av 157
V.5.3 Alternativ 2: Proxy
Beskrivelse
I en proxy-løsning vil mesteparten av dagens føderasjon kunne fortsette som i dag uten
større endringer.
Tjenester vil kunne forholde seg til et integrasjonspunkt som i dag.
Vertsorganisasjoner som ikke prioriterer å ha egen innloggingstjeneste vil kunne fortsette
som i dag uten endringer lokalt eller sentralt.
For vertsorganisasjoner som ønsker å ha sin egen innloggingstjeneste vil denne knyttes opp
mot den sentrale innloggingstjenesten. Dagens innloggingstjeneste vil da fungere som en
proxy som sender brukeren til den lokale innloggingstjenesten når brukere derfra logger
inn.
For den lokale innloggingstjenesten vil alle Feide-tjenester opptre som en tjeneste ’Feide’
og all Feide-informasjon om brukeren sendes over til den sentrale innloggingstjenesten
første gang brukeren logger inn i sesjonen. Prinsipielt er dette det samme som skjer mot
dagens lokale Feide-kataloger, men med en annen teknologi.
Som i mesh-alternativet vil vi i dette alternativet også få flere innloggingstjenester, en
sentral og flere lokale. Det vil bli en del duplisering av funksjonalitet og arbeid.
For vertsorganisasjoner med egne innloggingstjenester vil det kreve godt samarbeid
mellom sentral og lokal driftsorganisasjon for å få en god support.
Som med mesh vil sentrale støttesystemer kunne utvikles og videreutvikles for å
tilfredsstille behov som ikke er dekket i dag, for eksempel støtte flere varianter av måter å
bruke SAML2 på, å kunne tilpasse informasjonen som utveksles mellom tjenester og
enkelte vertsorganisasjoner og lignende.
Med en utvidelse av dagens pilot-støttesystem for front-mesh vil føderasjonen kunne støtte
tjenester som trenger en mesh-arkitektur gjennom det samme integrasjonspunktet uten å
påvirke tekniske løsninger hos vertsorganisasjonene.
Rapport
Side 114 av 157
Tekniske sammenkoplinger
Figuren viser et bilde av sammenhengen i en proxy-løsning:
• Alle tjenester integrerer seg med et punkt for å nå alle vertsorganisasjoner som i dagens
føderasjon. Protokollen som benyttes mellom tjenester og innloggingstjenester kan
brukes på mange måter og det er variasjoner. Innloggingstjenesten støtter en del
variasjoner i hvordan en tjeneste kommuniserer og tilpasser seg disse. Om en tjeneste
kommuniserer på en måte som innloggingstjenesten ikke støtter må vanligvis tjenesten
tilpasse seg føderasjonen. I enkelte tilfeller der det er hensiktsmessig tilpasses
føderasjonen tjenesten og funksjonaliteten gjøres tilgjengelig for alle tjenester.
• Noen vertsorganisasjoner kobler seg til innloggingstjenesten med en lokal
brukerkatalog. Det er satt krav til hvilken informasjon som skal være tilgjengelig for
tjenester og som vertsorganisasjonen må påse er i den lokale katalogen.
• Noen vertsorganisasjoner kobler seg til innloggingstjenesten med en lokal
innloggingstjeneste. Det er satt krav til hvilken informasjon som skal være tilgjengelig
for føderasjonen og som vertsorganisasjonen må påse sendes til den sentrale
innloggingstjenesten.
Rapport
Side 115 av 157
• Som i dag gjøres all administrasjon av hvilke tjenester som skal være åpne for hvilke
vertsorganisasjoner i en sentral tjeneste, gjennom selvbetjening for
tjenesteleverandører og vertsorganisasjoner i Feides kundeportal. Hver tjeneste får
utlevert samme informasjon om en bruker uavhengig av hvilken organisasjon brukeren
kommer fra.
Hvis vi ser dette fra synspunktet til en vertsorganisasjon med lokal innloggingstjeneste, vil
bildet se slik:
• De aller fleste har et lokalt AD som klienter autentiserer mot. Tradisjonelle
klientapplikasjoner gjenbruker gjerne denne autentiseringen.
• Vertsorganisasjonen har en lokal innloggingstjeneste der de plasserer lokale
webtjenester som benyttes i organisasjonen. Dette kan være egenutviklede tjenester
eller tjenester de kjøper hos leverandører, skytjenester og lignende.
• Den lokale innloggingstjenesten kan settes opp til å knytte sammen AD-domenet og sitt
SSO-domene slik at klientinnlogging gjenbrukes på denne.
Rapport
Side 116 av 157
• Feide-føderasjonen knyttes til den lokale innloggingstjenesten som en tjeneste på lik
linje med andre lokale tjenester.
Sett fra en tjeneste ser bildet slik ut. I praksis er føderasjonen slik den er i dag for
tjenester.
• Uavhengig av hvilke vertsorganisasjoner som skal benytte tjenesten integreres tjenesten
med et punkt for autentisering. Teknisk sammenkobling mellom tjenesten og en
vertsorganisasjon gjøres i Feides kundeportal med gjensidig åpning mellom tjenesten og
organisasjonen.
• Hvilken informasjon som blir utlevert til tjenesten er avtalt og satt på den sentrale
innloggingstjenesten og er lik for alle vertsorganisasjoner.
• Det er i dag ikke mulig for en tjeneste å be om annen informasjon for gitte
vertsorganisasjoner, og det er ikke mulig for en vertsorganisasjon å reservere seg fra å
sende gitte informasjonselementer til tjenesten. Med videreutvikling av sentrale
støttesystemer vil det være mulig å tilpasse informasjonen som sendes over til en
tjeneste fra forskjellige vertsorganisasjoner.
Rapport
Side 117 av 157
Eksempel på innloggingsflyt fra utstyr med klientinnlogging
Et eksempel på flyten ved bruk av en Feide-tjeneste fra utstyr hvor brukeren logger inn på
klient med bruker utlevert av vertsorganisasjonen:
Steg:
1. Brukeren logger på sin lokale PC
2. Innloggingen valideres av AD og det opprettes en Kerberos-sesjon
3. Brukeren benytter en Feide-tjeneste
4. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
5. Sentral innloggingstjeneste spør om organisasjonstilknytning, om dette ikke er valgt
tidligere
Rapport
Side 118 av 157
6. Sentral innloggingstjeneste sender brukeren videre til vertsorganisasjonens
innloggingstjeneste
7. Vertsorganisasjonen ser at det finnes en lokal sesjon allerede og gjenbruker denne
(SSO)
8. Vertsorganisasjonen returnerer avtalt informasjon om brukeren til den sentrale
innloggingstjenesten
9. Feide returnerer avtalt informasjon om brukeren til tjenesten
10. Brukeren har tilgang til tjenesten
Denne flyten gir altså sømløs pålogging mellom klientinnloggingen og Feide-tjenesten.
Rapport
Side 119 av 157
Eksempel på innloggingsflyt fra eget utstyr
Et eksempel på flyten ved bruk av en Feide-tjeneste fra eget utstyr er som følger:
Steg:
1. Brukeren benytter en Feide-tjeneste
2. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
3. Sentral innloggingstjeneste spør om organisasjonstilknytning, om dette ikke er valgt
tidligere
4. Sentral innloggingstjeneste sender brukeren videre til vertsorganisasjonens
innloggingstjeneste
Rapport
Side 120 av 157
5. Vertsorganisasjonen finner ingen lokal klientsesjon, og spør om brukernavn og passord
6. Vertsorganisasjonen returnerer avtalt informasjon om brukeren til den sentrale
innloggingstjenesten
7. Feide returnerer avtalt informasjon om brukeren til tjenesten
8. Brukeren har tilgang til tjenesten
Eksempel på innloggingsflyt på neste Feide-tjeneste
Et eksempel på flyten ved bruk av neste Feide-tjeneste:
Rapport
Side 121 av 157
Steg:
1. Brukeren benytter neste Feide-tjeneste
2. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
3. Brukeren har allerede en autentisert Feide-sesjon
4. Feide returnerer avtalt informasjon om brukeren til tjenesten
5. Brukeren har tilgang til tjenesten
Uavhengig av om brukeren er på en klient med eller uten AD-tilknytning så vil innlogging
på neste Feide-tjeneste foregå gjennom SSO med den sentrale innloggingstjenesten.
Eksempel på innloggingsflyt på neste lokale tjeneste
Et eksempel på flyten ved bruk av neste lokale tjeneste:
Steg:
1. Brukeren benytter en lokal tjeneste.
Rapport
Side 122 av 157
2. Tjenesten kontakter lokal innloggingstjeneste for innlogging over SAML2-protokollen
3. Brukeren har allerede en autentisert sesjon
4. Vertsorganisasjonen returnerer avtalt informasjon om brukeren til tjenesten
5. Brukeren har tilgang til tjenesten
Uavhengig av om brukeren er på en klient med eller uten AD-tilknytning så vil innlogging
på neste tjeneste foregå gjennom SSO og brukeren slipper å autentisere seg.
Kostnadspåvirkninger
Føderasjon. Ansvar og ressursbruk i føderasjonen blir stort sett uendret fra i dag. De som
har lokale innloggingsløsninger vil i større grad enn i dag følge opp nasjonale krav og
føringer.
Sentralt Lokalt
Forvalte informasjonsmodell og tillitsnettverk ✔
Forvalte SAML2-profil ✔
Håndtere konfigurasjon for tjenester og andre vertsorganisasjoner
✔
Følge opp endringer i nasjonale krav og føringer ✔ ✔
Følge opp endringer i eduGAINs krav og føringer ✔
Holde eduGAIN metadata oppdatert med vertsorganisasjoner og tjenester
✔
Tilpasse tjenester til å støtte Feides SAML2-profil ✔
Kontroll av personer ved utlevering av brukerkonto ✔
Support. De med lokal innloggingstjeneste vil måtte ta ansvaret for mer av support rundt
oppkobling mot sentral innloggingstjeneste og sporing av feil i sin tjeneste. Support for
tjenesteleverandører må koordineres godt mellom sentral og lokal driftsorganisasjon.
Sentralt Lokalt
Førstelinje for sluttbrukere
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔ ✔
Rapport
Side 123 av 157
Sentralt Lokalt
Ved oppkobling av nye tjenester, og oppdatering av tjenester ✔
Innloggingsfeil og -sporing - for vertsorganisasjoner ✔ ✔
Innloggingsfeil og -sporing - for tjenesteleverandører ✔ ✔
Sporing for CERT, jukseprosess og lignende ✔ ✔
Henvendelser fra eduGAIN-organisasjoner og -tjenester ✔
Datakvalitet ved vertsorganisasjon. For de med egen innloggingstjeneste vil vi ikke kunne
benytte de verktøyene vi har sentralt i dag som sjekker datakvaliteten på hele
brukermassen. Løpende datakvalitetssjekk ved innlogging vil kunne benyttes som før av
alle. Som for mesh, avhengig av videreutvikling av støttesystemer sentralt vil det kunne
avhjelpe en del av det lokale arbeidet.
Sentralt Lokalt
Holde datakvaliteten oppe
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔ ✔
Sjekk av kvalitet ved behov/ønske ✔ ✔
Løpende oversikt over kvalitet ved innlogginger ✔
Innloggingstjeneste for web. For de med egen innloggingstjeneste vil de måtte duplisere
en del av funksjonaliteten som er i sentral innloggingstjeneste. For de som ikke har slike
løsninger i dag vil det være en ny komponent eksponert mot internett med krav til
universell utforming og lignende. Med egen innloggingstjeneste vil det ikke lenger være
bruk for dagens lokale Feide-brukerkatalog.
Sentralt Lokalt
Støtte SAML2-profil for Feide ✔ ✔
Støtte SAML2-profil for eduGAIN ✔
Tilgangskontroll tjenester/vertsorg (gjensidig åpning) ✔
Tilgangskontroll informasjonselementer (attribute release policy)
✔
Rapport
Side 124 av 157
Sentralt Lokalt
Oversettelse av attributtformater etter tjenestens behov ✔
Universell utforming, responsiv design, gjenkjennbarhet ✔ ✔
Drift av IdP eksponert mot verden ✔ ✔
Tilgjengelighet, redundans, sikkerhet og DDoS-beskyttelse mot verden osv
✔ ✔
Drift av LDAP-katalog eksponert mot Feide ✔
Sterk autentisering. For de med egen innloggingstjeneste vil de måtte duplisere en del av
funksjonaliteten som er i sentral innloggingstjeneste rundt sterk autentisering.
Vertsorganisasjonene må ha egne løsninger for dette som tilfredsstiller kravene i offentlig
sektor. Det vil være mulig med en mye større variasjon i hvilke metoder som benyttes
lokalt.
Sentralt Lokalt
Tilby sterk autentisering (nivå 3 nå, sannsynligvis nivå 4 senere)
✔ ✔
Administrere bruk av sterk autentisering mot tjenester ✔ ✔
Blokkere tilgang til tjenester om bruker ikke er sterkt nok autentisert
✔
Tjenestestartet sterk autentisering ved behov ✔ ✔
Statistikk. I en proxy-løsning vil statistikkfunksjonalitet bli uendret fra i dag.
Sentralt Lokalt
Statistikk for føderasjonen som helhet (rapportering til KD o.l.)
✔
Statistikk for vertsorganisasjon rundt bruk av tjenester i føderasjonen
✔
Statistikk for tjenesteleverandører om bruk gjennom føderasjonen
✔
Rapport
Side 125 av 157
Funksjonalitet til Dataporten. For de med egen innloggingstjeneste vil vi ikke kunne
benytte de fleste av dagens integrasjoner mellom Dataporten og vertsorganisasjonene.
Dataporten benytter seg av dagens Feide-katalog som for disse ikke lenger vil eksistere.
Nye måter å realisere samme funksjonalitet må lages. Selve autentiseringsbiten av
Dataporten blir uendret fra i dag.
Sentralt Lokalt
Tilby innlogging, sterk autentisering, tjenestestartet sterk autentisering
✔
Tilby brukerinformasjon i og utenfor innloggingssesjon ✔ ✔
Tilby gruppeinformasjon (Administrerte grupper) ✔ ✔
Tilby personsøk ✔ ✔
Policypåvirkninger
En helt eller delvis overgang til proxy-løsningen vil føre til at kontrakter for
vertsorganisasjoner må omarbeides og kanskje deles i to forskjellige kontrakter. En for de
med egen innloggingstjeneste og en for de med Feide-katalog. For de med egen
innloggingstjeneste vil ansvarsforhold endres og må reflekteres inn i avtalene.
Policyer rundt informasjonsmodell og hvordan disse representeres vil trenge en
gjennomgang, men ikke nødvendigvis endres.
Betalingsmodellen må gjennomgås, men ikke nødvendigvis endres, avhengig av om det skal
utvikles spesielle støtteverktøy for de med egen innloggingstjeneste.
V.5.4 Alternativ 3: Kerberos
Beskrivelse
De aller fleste vertsorganisasjoner har i dag Active Directory eller en annen Kerberos-
basert autentiseringsløsning som de benytter til autentisering av brukere på klienter. I
alternativene over knyttes denne autentiseringen med de lokale innloggingstjenestene for
å få sømløs innlogging mellom klient og webtjenester.
Det er også mulig å knytte denne Kerberos-autentiseringen sammen med den sentrale
innloggingstjenesten i Feide direkte.
Rapport
Side 126 av 157
Om denne sammenkoblingen vil fungere avhenger av funksjonaliteten i brukerens
nettleser. Oppførselen varierer noe mellom nettleserprodukt og versjoner av produktet. De
mest brukte nettleserne i dag støtter funksjonaliteten.
I en slik løsning er det mange potensielle feilsituasjoner og uforutsigbar oppførsel for
brukere og for å minimere disse bør man ha veldig god kontroll på hvilke nettlesere og -
versjoner som benyttes, samt hvilke nettverk brukerne sitter på. Sammenkobling med
innloggingstjeneste og Kerberos kan være en god løsning for de som har denne kontrollen.
Feide har tidligere utredet muligheten for sammenkobling av Kerberos med den sentrale
innloggingstjenesten, men valgte da å ikke gå videre med implementasjon på grunn av alle
komplikasjonene vi så for brukerne i sektoren som helhet.
En slik Kerberos-integrasjon en enklere å realisere med en lokal innloggingstjeneste.
Dette alternativet kan løse behovet rundt gjenbruk av klientinnlogging på Feide-tjenester,
men løser ikke sammenkobling av Feide-tjenester og tjenester i en ’lokal føderasjon’.
Rapport
Side 127 av 157
Tekniske sammenkoplinger
Figuren viser et bilde av sammenhengen i en Kerberos-løsning:
• Alle tjenester integrerer seg med et punkt for å nå alle vertsorganisasjoner som i dagens
føderasjon. Protokollen som benyttes mellom tjenester og innloggingstjenester kan
brukes på mange måter og det er variasjoner. Innloggingstjenesten støtter en del
variasjoner i hvordan en tjeneste kommuniserer og tilpasser seg disse. Om en tjeneste
kommuniserer på en måte som innloggingstjenesten ikke støtter må vanligvis tjenesten
tilpasse seg føderasjonen. I enkelte tilfeller der det er hensiktsmessig tilpasses
føderasjonen tjenesten og funksjonaliteten gjøres tilgjengelig for alle tjenester.
• Alle vertsorganisasjoner kobler seg til innloggingstjenesten med en lokal brukerkatalog
som i dag. Det er satt krav til hvilken informasjon som skal være tilgjengelig for
tjenester og som vertsorganisasjonen må påse er i den lokale katalogen.
• Noen vertsorganisasjoner kobler sin Kerberos-autentisering inn mot innloggingstjenesten
slik at den kan gjenbruke Kerberos-sesjoner.
Rapport
Side 128 av 157
• Som i dag gjøres all administrasjon av hvilke tjenester som skal være åpne for hvilke
vertsorganisasjoner i en sentral tjeneste, gjennom selvbetjening for
tjenesteleverandører og vertsorganisasjoner i Feides kundeportal. Hver tjeneste får
utlevert samme informasjon om en bruker uavhengig av hvilken organisasjon brukeren
kommer fra.
Hvis vi ser dette fra synspunktet til en vertsorganisasjon med lokal innloggingstjeneste, vil
bildet se slik:
• De aller fleste har et lokalt AD som klienter autentiserer mot. Tradisjonelle
klientapplikasjoner gjenbruker gjerne denne autentiseringen.
• For Feide-føderasjonen har vertsorganisasjonen en Feide-katalog som benyttes av
innloggingstjenesten.
• Innloggingstjenesten knyttes sammen med dette AD-domenet for å gjenbruke Kerberos-
sesjonen derfra.
Rapport
Side 129 av 157
• Enkelte vertsorganisasjoner, gjerne større organisasjoner, har i dag også en ’lokal
føderasjon’ der de plasserer lokale webtjenester som benyttes i organisasjonen. Dette
kan være egenutviklede tjenester eller tjenester de kjøper hos leverandører,
skytjenester og lignende.
Sett fra en tjeneste ser bildet slik ut. I praksis er føderasjonen slik den er i dag for
tjenester.
• Uavhengig av hvilke vertsorganisasjoner som skal benytte tjenesten integreres den med
ett punkt for autentisering. Teknisk sammenkobling mellom tjenesten og en
vertsorganisasjon gjøres i Feides kundeportal med gjensidig åpning mellom tjenesten og
organisasjonen.
• Hvilken informasjon som blir utlevert til tjenesten er avtalt og satt på den sentrale
innloggingstjenesten og er lik for alle vertsorganisasjoner.
• Det er i dag ikke mulig for en tjeneste å be om annen informasjon for gitte
vertsorganisasjoner, og det er ikke mulig for en vertsorganisasjon å reservere seg fra å
sende gitte informasjonselementer til tjenesten. Med videreutvikling av sentrale
SP 1
Org A Org B Org DOrg C
Rapport
Side 130 av 157
støttesystemer vil det være mulig å tilpasse informasjonen som sendes over til en
tjeneste fra forskjellige vertsorganisasjoner.
Eksempel på innloggingsflyt fra utstyr med klientinnlogging
Et eksempel på flyten ved bruk av en Feide-tjeneste fra utstyr hvor brukeren logger inn på
klient med bruker utlevert av vertsorganisasjonen:
Steg:
1. Brukeren logger på sin lokale PC
2. Innloggingen valideres av AD og det opprettes en Kerberos-sesjon
SP
Org D
SAML2
Kerberos
LDAP
6
38
4
9
1
2
5
7
Rapport
Side 131 av 157
3. Brukeren benytter en Feide-tjeneste
4. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
5. Innloggingstjenesten spør om organisasjonstilknytning, om dette ikke er valgt tidligere
6. Innloggingstjenesten ser at det finnes en lokal Kerberos-sesjon allerede og gjenbruker
denne (SSO)
7. Vertsorganisasjonen returnerer avtalt informasjon om brukeren til den sentrale
innloggingstjenesten
8. Feide returnerer avtalt informasjon om brukeren til tjenesten
9. Brukeren har tilgang til tjenesten
Denne flyten gir altså sømløs pålogging mellom klientinnloggingen og Feide-tjenesten.
Rapport
Side 132 av 157
Eksempel på innloggingsflyt fra eget utstyr
Et eksempel på flyten ved bruk av en Feide-tjeneste fra eget utstyr er som følger:
Steg:
1. Brukeren benytter en Feide-tjeneste
2. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
3. Innloggingstjenesten spør om organisasjonstilknytning, om dette ikke er valgt tidligere
4. Innloggingstjenesten ser at det ikke er noen Kerberos-sesjon og spør om brukernavn og
passord
5. Innloggingen valideres mot vertsorganisasjonens Feide-katalog
6. Feide returnerer avtalt informasjon om brukeren til tjenesten
Rapport
Side 133 av 157
7. Brukeren har tilgang til tjenesten
I dette tilfellet er ikke klienten som brukeren benytter medlem av et AD-domene og det er
ikke noen Kerberos-sesjon inne i bildet.
Eksempel på innloggingsflyt på neste Feide-tjeneste
Et eksempel på flyten ved bruk av neste Feide-tjeneste:
Steg:
1. Brukeren benytter neste Feide-tjeneste
2. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
3. Brukeren har allerede en autentisert Feide-sesjon
Rapport
Side 134 av 157
4. Feide returnerer avtalt informasjon om brukeren til tjenesten
5. Brukeren har tilgang til tjenesten
Uavhengig av om brukeren er på en klient med eller uten AD-tilknytning så vil innlogging
på neste Feide-tjeneste foregå gjennom SSO med den sentrale innloggingstjenesten.
Eksempel på innloggingsflyt på en lokal tjeneste
Et eksempel på flyten ved bruk av tjeneste i en ’lokal føderasjon’:
Steg:
1. Brukeren benytter en lokal tjeneste.
2. Tjenesten kontakter lokal innloggingstjeneste for innlogging over SAML2-protokollen
3. Brukeren autentiserer seg selv om han allerede har aktiv Feide-sesjon.
4. Vertsorganisasjonen returnerer avtalt informasjon om brukeren til tjenesten
5. Brukeren har tilgang til tjenesten
Rapport
Side 135 av 157
I og med at Feide-føderasjonen og ’lokal føderasjon’ ikke henger sammen vil brukeren
måtte autentisere seg igjen når han går mot en lokal tjeneste. Om den lokale
innloggingstjenesten er koblet sammen med AD-domenet vil Kerberos-sesjonen derfra
kunne gjenbrukes om den allerede eksisterer. Om ikke må brukeren autentisere seg på den
lokale innloggingstjenesten.
Kostnadspåvirkninger
Føderasjon. Ansvar og ressursbruk i føderasjonen blir stort sett uendret fra i dag.
Sentralt Lokalt
Forvalte informasjonsmodell og tillitsnettverk ✔
Forvalte SAML2-profil ✔
Håndtere konfigurasjon for tjenester og andre vertsorganisasjoner
✔
Følge opp endringer i nasjonale krav og føringer ✔
Følge opp endringer i eduGAINs krav og føringer ✔
Holde eduGAIN metadata oppdatert med vertsorganisasjoner og tjenester
✔
Tilpasse tjenester til å støtte Feides SAML2-profil ✔
Kontroll av personer ved utlevering av brukerkonto ✔
Support. Ansvar og ressursbruk rundt support blir stort sett uendret fra i dag, men de som
benytter Kerberos-sesjoner vil få mer ansvar og arbeid rundt sporing av innloggingsfeil for
egne brukere.
Sentralt Lokalt
Førstelinje for sluttbrukere
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔
Ved oppkobling av nye tjenester, og oppdatering av tjenester ✔
Innloggingsfeil og -sporing - for vertsorganisasjoner ✔ ✔
Innloggingsfeil og -sporing - for tjenesteleverandører ✔
Rapport
Side 136 av 157
Sentralt Lokalt
Sporing for CERT, jukseprosess og lignende ✔ ✔
Henvendelser fra eduGAIN-organisasjoner og -tjenester ✔
Datakvalitet ved vertsorganisasjon. Ansvar og ressursbruk rundt datakvalitet blir uendret
fra i dag
Sentralt Lokalt
Holde datakvaliteten oppe
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔
Sjekk av kvalitet ved behov/ønske ✔
Løpende oversikt over kvalitet ved innlogginger ✔
Innloggingstjeneste for web. Ansvar og ressursbruk rundt innloggingstjenesten blir stort
sett uendret fra i dag, men de som ønsker bruk av Kerberos-sesjoner må stille med en
Kerberos-tjener lokalt.
Sentralt Lokalt
Støtte SAML2-profil for Feide ✔
Støtte SAML2-profil for eduGAIN ✔
Tilgangskontroll tjenester/vertsorg (gjensidig åpning) ✔
Tilgangskontroll informasjonselementer (attribute release policy)
✔
Oversettelse av attributtformater etter tjenestens behov ✔
Universell utforming, responsiv design, gjenkjennbarhet ✔
Drift av IdP eksponert mot verden ✔
Tilgjengelighet, redundans, sikkerhet og DDoS-beskyttelse mot verden osv
✔
Drift av LDAP-katalog eksponert mot Feide ✔
Drift av Kerberos-tjener e.l. (+) ✔
Rapport
Side 137 av 157
Sterk autentisering. Mulighetene rundt sterk autentisering er uavklart. Dette var ikke et
tema da vi utredet dette alternativet tidligere og må ses nærmere på.
Sentralt Lokalt
Tilby sterk autentisering (nivå 3 nå, sannsynligvis nivå 4 senere)
✔ ? ?
Administrere bruk av sterk autentisering mot tjenester ✔ ? ✔ ?
Blokkere tilgang til tjenester om bruker ikke er sterkt nok autentisert
✔
Tjenestestartet sterk autentisering ved behov ✔ ? ?
Statistikk. I en Kerberos-løsning vil statistikkfunksjonalitet være uendret fra i dag.
Sentralt Lokalt
Statistikk for føderasjonen som helhet (rapportering til KD o.l.)
✔
Statistikk for vertsorganisasjon rundt bruk av tjenester i føderasjonen
✔
Statistikk for tjenesteleverandører om bruk gjennom føderasjonen
✔
Funksjonalitet til Dataporten. I en Kerberos-løsning vil funksjonaliteten Dataporten
benytter være uendret fra i dag.
Sentralt Lokalt
Tilby innlogging, sterk autentisering, tjenestestartet sterk autentisering
✔
Tilby brukerinformasjon i og utenfor innloggingssesjon ✔
Tilby gruppeinformasjon (Administrerte grupper) ✔
Tilby personsøk ✔
Rapport
Side 138 av 157
Policypåvirkninger
En full eller delvis overgang til Kerberos-løsningen vil føre til at kontrakter for
vertsorganisasjoner må omarbeides og kanskje deles i to forskjellige kontrakter. En for de
med Kerberos-sammenkobling og en for de uten. For de med Kerberos-sammenkobling vil
ansvarsforhold endres noe og dette må reflekteres inn i avtalene.
Policyer rundt informasjonsmodell og hvordan disse representeres vil ikke endres.
Betalingsmodellen må gjennomgås, men ikke nødvendigvis endres, avhengig av om
Kerberos-sammenkobling er en del av felleskostnadene eller ekstratjeneste for de som
benytter den.
V.5.5 Alternativ 4: Revers proxy for tjenester
Beskrivelse
I dette alternativet endres ikke dagens Feide-føderasjon, men vertsorganisasjoner må
legge til eller endre sin ’lokale føderasjon’ til å også kunne benytte den sentrale
innloggingstjenesten.
Dette vil løse behovet med sammenkobling av Feide-tjenester og lokale tjenester, men vil
ikke koble sammen klientinnlogging med Feide-innlogging.
Det er også mulig å koble sammen autentisering i ’sky-føderasjoner’ som Microsofts Azure
AD og Googles økosystem inn i dette alternativet som en erstatning for eller i tillegg til den
’lokale føderasjonen.’
I og med at dette ikke krever endringer i Feide-føderasjonen er det vertsorganisasjoner
som i mindre eller større grad benytter dette alternativet allerede.
Rapport
Side 139 av 157
Tekniske sammenkoplinger
Figuren viser et bilde av sammenhengen i en revers proxy-løsning:
• Alle tjenester integrerer seg med et punkt for å nå alle vertsorganisasjoner som i dagens
føderasjon. Protokollen som benyttes mellom tjenester og innloggingstjenester kan
brukes på mange måter og det er variasjoner. Innloggingstjenesten støtter en del
variasjoner i hvordan en tjeneste kommuniserer og tilpasser seg disse. Om en tjeneste
kommuniserer på en måte som innloggingstjenesten ikke støtter må vanligvis tjenesten
tilpasse seg føderasjonen. I enkelte tilfeller der det er hensiktsmessig tilpasses
føderasjonen tjenesten og funksjonaliteten gjøres tilgjengelig for alle tjenester.
• Alle vertsorganisasjoner kobler seg til innloggingstjenesten med en lokal brukerkatalog
som i dag. Det er satt krav til hvilken informasjon som skal være tilgjengelig for
tjenester og som vertsorganisasjonen må påse er i den lokale katalogen.
• Vertsorganisasjoner med lokal innloggingstjeneste kobler denne opp mot den sentrale
innloggingstjenesten slik at den kan benyttes på lokale tjenester.
Rapport
Side 140 av 157
• Som i dag gjøres all administrasjon av hvilke tjenester som skal være åpne for hvilke
vertsorganisasjoner i en sentral tjeneste, gjennom selvbetjening for
tjenesteleverandører og vertsorganisasjoner i Feides kundeportal. Hver tjeneste får
utlevert samme informasjon om en bruker uavhengig av hvilken organisasjon brukeren
kommer fra.
Hvis vi ser dette fra synspunktet til en vertsorganisasjon med lokal innloggingstjeneste, kan
bildet se slik ut:
• De aller fleste har et lokalt AD som klienter autentiserer mot. Tradisjonelle
klientapplikasjoner gjenbruker gjerne denne autentiseringen.
• For Feide-føderasjonen har vertsorganisasjonen en Feide-katalog som benyttes av
innloggingstjenesten.
• Vertsorganisasjoner med en ’lokal føderasjon’ der de plasserer lokale webtjenester som
benyttes i organisasjonen kobles til den sentrale innloggingstjenesten slik at Feide-
sesjoner kan gjenbrukes lokalt.
Rapport
Side 141 av 157
• Vertsorganisasjonen gjenbruker Feide-sesjoner når de kobler opp skytjenester som
Office 365 gjennom Azure AD, G-Suite fra Google og lignende.
Sett fra en tjeneste ser bildet slik ut. I praksis er føderasjonen slik den er i dag for
tjenester.
• Uavhengig av hvilke vertsorganisasjoner som skal benytte tjenesten integreres den med
ett punkt for autentisering. Teknisk sammenkobling mellom tjenesten og en
vertsorganisasjon gjøres i Feides kundeportal med gjensidig åpning mellom tjenesten og
organisasjonen.
• Hvilken informasjon som blir utlevert til tjenesten er avtalt og satt på den sentrale
innloggingstjenesten og er lik for alle vertsorganisasjoner.
• Det er i dag ikke mulig for en tjeneste å be om annen informasjon for gitte
vertsorganisasjoner, og det er ikke mulig for en vertsorganisasjon å reservere seg fra å
sende gitte informasjonselementer til tjenesten. Med videreutvikling av sentrale
støttesystemer vil det være mulig å tilpasse informasjonen som sendes over til en
tjeneste fra forskjellige vertsorganisasjoner.
Rapport
Side 142 av 157
Eksempel på innloggingsflyt fra utstyr med klientinnlogging
Et eksempel på flyten ved bruk av en Feide-tjeneste fra utstyr hvor brukeren logger inn på
klient med bruker utlevert av vertsorganisasjonen:
Steg:
1. Brukeren logger på sin lokale PC
2. Innloggingen valideres av AD og det opprettes en Kerberos-sesjon
3. Brukeren benytter en Feide-tjeneste
4. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
5. Feide spør om organisasjonstilknytning, om dette ikke er valgt tidligere i Feide
6. Feide spør om brukernavn og passord
Rapport
Side 143 av 157
7. Innloggingen valideres mot vertsorganisasjonens Feide-katalog
8. Feide returnerer avtalt informasjon om brukeren til tjenesten
9. Brukeren har tilgang til tjenesten
Dette alternativet har ingen sømløs pålogging mellom innlogging på klienten og Feide-
tjenesten. Den lokale organisasjonen har som regel en synkronisering av brukernavn og
passord mellom AD og den lokale Feide-katalogen, men det er ingen kopling som gjør at
Kerberos-sesjonen kan gjenbrukes: brukeren må oppgi brukernavn og passord på nytt ved
innlogging på første Feide-tjeneste.
Eksempel på innloggingsflyt fra eget utstyr
Et eksempel på flyten ved bruk av en lokal tjeneste fra eget utstyr er som følger:
Merk at vi her velger å illustrere eget utstyr med en lokal tjeneste, ikke en Feide-tjeneste
som i tidligere alternativer. For en Feide-tjeneste med eget utstyr vil flyten bli nøyaktig
den samme som vist i V.5.1.4 Eksempel på innloggingsflyt fra eget utstyr.
Steg:
1. Brukeren benytter en lokal tjeneste
2. Tjenesten kontakter lokal innloggingstjeneste over SAML2-protokollen
Rapport
Side 144 av 157
3. Lokal innloggingstjeneste sender brukeren videre til sentral innloggingstjeneste med
forhåndsvalgt organisasjonstilknytning
4. Sentral innloggingstjeneste spør om brukernavn og passord
5. Innloggingen valideres mot vertsorganisasjonens Feide-katalog
6. Sentral innloggingstjeneste returnerer avtalt informasjon om brukeren til den lokale
innloggingstjenesten
7. Lokal innloggingstjeneste returnerer avtalt informasjon om brukeren til tjenesten
8. Brukeren har tilgang til tjenesten
Fra nå av vil brukeren ha SSO med andre lokale tjenester.
Eksempel på innloggingsflyt på neste Feide-tjeneste
Et eksempel på flyten ved bruk av neste Feide-tjeneste:
Rapport
Side 145 av 157
Steg:
1. Brukeren benytter neste Feide-tjeneste
2. Tjenesten kontakter Feide for innlogging over SAML2-protokollen
3. Brukeren har allerede en autentisert Feide-sesjon
4. Feide returnerer avtalt informasjon om brukeren til tjenesten
5. Brukeren har tilgang til tjenesten
Uavhengig av om brukeren er på en klient med eller uten AD-tilknytning så vil innlogging
på neste Feide-tjeneste foregå gjennom SSO med den sentrale innloggingstjenesten.
Kostnadspåvirkninger
Føderasjon. Ansvar og ressursbruk i føderasjonen blir uendret fra i dag.
Sentralt Lokalt
Forvalte informasjonsmodell og tillitsnettverk ✔
Forvalte SAML2-profil ✔
Håndtere konfigurasjon for tjenester og andre vertsorganisasjoner
✔
Følge opp endringer i nasjonale krav og føringer ✔
Følge opp endringer i eduGAINs krav og føringer ✔
Holde eduGAIN metadata oppdatert med vertsorganisasjoner og tjenester
✔
Tilpasse tjenester til å støtte Feides SAML2-profil ✔
Kontroll av personer ved utlevering av brukerkonto ✔
Support. Ansvar og ressursbruk rundt support blir uendret fra i dag.
Sentralt Lokalt
Førstelinje for sluttbrukere
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔
Ved oppkobling av nye tjenester, og oppdatering av tjenester ✔
Rapport
Side 146 av 157
Sentralt Lokalt
Innloggingsfeil og -sporing - for vertsorganisasjoner ✔
Innloggingsfeil og -sporing - for tjenesteleverandører ✔
Sporing for CERT, jukseprosess og lignende ✔ ✔
Henvendelser fra eduGAIN-organisasjoner og -tjenester ✔
Datakvalitet ved vertsorganisasjon. Ansvar og ressursbruk rundt datakvalitet blir uendret
fra i dag
Sentralt Lokalt
Holde datakvaliteten oppe
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔
Sjekk av kvalitet ved behov/ønske ✔
Løpende oversikt over kvalitet ved innlogginger ✔
Innloggingstjeneste for web. Ansvar og ressursbruk rundt innloggingstjenesten blir uendret
fra i dag.
Sentralt Lokalt
Støtte SAML2-profil for Feide ✔
Støtte SAML2-profil for eduGAIN ✔
Tilgangskontroll tjenester/vertsorg (gjensidig åpning) ✔
Tilgangskontroll informasjonselementer (attribute release policy)
✔
Oversettelse av attributtformater etter tjenestens behov ✔
Universell utforming, responsiv design, gjenkjennbarhet ✔
Drift av IdP eksponert mot verden ✔
Tilgjengelighet, redundans, sikkerhet og DDoS-beskyttelse mot verden osv
✔
Drift av LDAP-katalog eksponert mot Feide ✔
Rapport
Side 147 av 157
Sterk autentisering. Ansvar og ressursbruk rundt sterk autentisering blir uendret fra i dag.
Sentralt Lokalt
Tilby sterk autentisering (nivå 3 nå, sannsynligvis nivå 4 senere)
✔
Administrere bruk av sterk autentisering mot tjenester ✔ ✔
Blokkere tilgang til tjenester om bruker ikke er sterkt nok autentisert
✔
Tjenestestartet sterk autentisering ved behov ✔
Statistikk. Statistikkfunksjonalitet vil være uendret fra i dag.
Sentralt Lokalt
Statistikk for føderasjonen som helhet (rapportering til KD o.l.)
✔
Statistikk for vertsorganisasjon rundt bruk av tjenester i føderasjonen
✔
Statistikk for tjenesteleverandører om bruk gjennom føderasjonen
✔
Funksjonalitet til Dataporten. Funksjonaliteten Dataporten benytter vil være uendret fra
i dag.
Sentralt Lokalt
Tilby innlogging, sterk autentisering, tjenestestartet sterk autentisering
✔
Tilby brukerinformasjon i og utenfor innloggingssesjon ✔
Tilby gruppeinformasjon (Administrerte grupper) ✔
Tilby personsøk ✔
Rapport
Side 148 av 157
Policypåvirkninger
Kontrakter vil ikke endres.
Policyer rundt informasjonsmodell og hvordan disse representeres vil ikke endres.
Betalingsmodellen vil ikke endres.
V.5.6 Alternativ 5: Klientinnlogging med web-SSO
Beskrivelse
I dette alternativet endres ikke dagens Feide-føderasjon, men vertsorganisasjoner må
knytte sin klientinnlogging mot den sentrale innloggingstjenesten.
Dette vil løse behovet med sammenkobling av klientinnlogging med Feide-innlogging.
Alternativet vises her som en utvidelse av alternativet over og vil dermed også koble
sammen Feide-tjenester og lokale tjenester. For vertsorganisasjoner som velger å knytte
alle lokale tjenester enten til Feide-føderasjonen eller ’sky-føderasjoner’ som Azure AD og
Googles økosystem vil den lokale innloggingstjenesten ikke være nødvendig.
Teknologien er på plass for å gjøre Feide-innlogging på klienter i Googles økosystem
allerede med Chromebooks. På Windows-siden ser vi konturene til dette med Modern
Authentication og ADAL3 der man bruker web-innlogging i klientapplikasjoner, men det er
ikke tilgjengelig på selve klientinnloggingen. Vi vet ikke om dette er en funksjonalitet som
vil bli innført på klientinnloggingen i Windows også.
I og med at dette ikke krever endringer i Feide-føderasjonen er det vertsorganisasjoner
som i mindre eller større grad benytter dette alternativet allerede.
3 Azure Active Directory Authentication Libraries - https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-libraries
Rapport
Side 149 av 157
Tekniske sammenkoplinger
Figuren viser et bilde av sammenhengen i en løsning som benytter web-SSO på klientene og
revers proxy for lokale tjenester:
• Alle tjenester integrerer seg med et punkt for å nå alle vertsorganisasjoner som i dagens
føderasjon. Protokollen som benyttes mellom tjenester og innloggingstjenester kan
brukes på mange måter og det er variasjoner. Innloggingstjenesten støtter en del
variasjoner i hvordan en tjeneste kommuniserer og tilpasser seg disse. Om en tjeneste
kommuniserer på en måte som innloggingstjenesten ikke støtter må vanligvis tjenesten
tilpasse seg føderasjonen. I enkelte tilfeller der det er hensiktsmessig tilpasses
føderasjonen tjenesten og funksjonaliteten gjøres tilgjengelig for alle tjenester.
• Alle vertsorganisasjoner kobler seg til innloggingstjenesten med en lokal brukerkatalog
som i dag. Det er satt krav til hvilken informasjon som skal være tilgjengelig for
tjenester og som vertsorganisasjonen må påse er i den lokale katalogen.
Rapport
Side 150 av 157
• Vertsorganisasjoner med lokal innloggingstjeneste kobler denne opp mot den sentrale
innloggingstjenesten slik at den kan benyttes på lokale tjenester.
• Som i dag gjøres all administrasjon av hvilke tjenester som skal være åpne for hvilke
vertsorganisasjoner i en sentral tjeneste, gjennom selvbetjening for
tjenesteleverandører og vertsorganisasjoner i Feides kundeportal. Hver tjeneste får
utlevert samme informasjon om en bruker uavhengig av hvilken organisasjon brukeren
kommer fra.
Hvis vi ser dette fra synspunktet til en vertsorganisasjon med web-SSO på klienter og lokal
innloggingstjeneste, kan bildet se slik:
• Det er ikke behov for et lokalt AD for å få til sammenkoblingen.
• Chromebooks kobles opp mot Googles økosystem. Modern Autentication-applikasjoner
kobles til Azure AD.
• Om det i fremtiden blir mulig kan Windows-klienter enten kobles til lokal
innloggingsløsning, sannsynligvis en ADFS, eller Azure AD.
Rapport
Side 151 av 157
• For Feide-føderasjonen har vertsorganisasjonen en Feide-katalog som benyttes av
innloggingstjenesten.
• Vertsorganisasjoner med en ’lokal føderasjon’ der de plasserer lokale webtjenester som
benyttes i organisasjonen kobles til den sentrale innloggingstjenesten slik at Feide-
sesjoner kan gjenbrukes lokalt.
• Vertsorganisasjonen gjenbruker Feide-sesjoner når de kobler opp skytjenester som
Office 365 gjennom Azure AD, G-Suite fra Google og lignende.
Sett fra en tjeneste ser bildet slik ut. I praksis er føderasjonen slik den er i dag for
tjenester.
• Uavhengig av hvilke vertsorganisasjoner som skal benytte tjenesten integreres den med
ett punkt for autentisering. Teknisk sammenkobling mellom tjenesten og en
vertsorganisasjon gjøres i Feides kundeportal med gjensidig åpning mellom tjenesten og
organisasjonen.
Rapport
Side 152 av 157
• Hvilken informasjon som blir utlevert til tjenesten er avtalt og satt på den sentrale
innloggingstjenesten og er lik for alle vertsorganisasjoner.
• Det er i dag ikke mulig for en tjeneste å be om annen informasjon for gitte
vertsorganisasjoner, og det er ikke mulig for en vertsorganisasjon å reservere seg fra å
sende gitte informasjonselementer til tjenesten. Med videreutvikling av sentrale
støttesystemer vil det være mulig å tilpasse informasjonen som sendes over til en
tjeneste fra forskjellige vertsorganisasjoner.
Eksempel på klientinnlogging på en klient med web-SSO
Et eksempel på flyten ved bruk av en Chromebook hvor brukeren logger inn på klient med
bruker utlevert av vertsorganisasjonen:
Steg:
1. Brukeren starter innlogging på sin Chromebook
2. Klienten spør Googles innloggingstjeneste om å starte innlogging
Rapport
Side 153 av 157
3. Googles innloggingstjeneste kontakter Feide for innlogging over SAML2-protokollen,
med informasjon om hvilken organisasjon brukeren kommer fra.
4. Feide spør om brukernavn og passord
5. Innloggingen valideres mot vertsorganisasjonens Feide-katalog
6. Feide returnerer avtalt informasjon om brukeren til Googles innloggingstjeneste
7. Googles innloggingstjeneste sender autentisert bruker til Chromebook
8. Brukeren er logget inn på klienten.
Med denne innloggingen på klienten vil brukeren ha SSO med Googles økosystem og alle
Feide-tjenester. Om vertsorganisasjonen også har lokale tjenester med revers proxy som
alternativet over vil han ha SSO der også som vist under.
Eksempel på innloggingsflyt på lokal tjeneste
Et eksempel på flyten videre ved bruk av en lokal tjeneste fra Chromebook er som følger:
Steg:
1. Brukeren benytter en lokal tjeneste
Rapport
Side 154 av 157
2. Tjenesten kontakter lokal innloggingstjeneste over SAML2-protokollen
3. Lokal innloggingstjeneste sender brukeren videre til sentral innloggingstjeneste med
forhåndsvalgt organisasjonstilknytning
4. Brukeren har allerede en autentisert Feide-sesjon
5. Sentral innloggingstjeneste returnerer avtalt informasjon om brukeren til den lokale
innloggingstjenesten
6. Lokal innloggingstjeneste returnerer avtalt informasjon om brukeren til tjenesten
7. Brukeren har tilgang til tjenesten
Kostnadspåvirkninger
Føderasjon. Ansvar og ressursbruk i føderasjonen blir uendret fra i dag.
Sentralt Lokalt
Forvalte informasjonsmodell og tillitsnettverk ✔
Forvalte SAML2-profil ✔
Håndtere konfigurasjon for tjenester og andre vertsorganisasjoner
✔
Følge opp endringer i nasjonale krav og føringer ✔
Følge opp endringer i eduGAINs krav og føringer ✔
Holde eduGAIN metadata oppdatert med vertsorganisasjoner og tjenester
✔
Tilpasse tjenester til å støtte Feides SAML2-profil ✔
Kontroll av personer ved utlevering av brukerkonto ✔
Support. Ansvar og ressursbruk rundt support blir uendret fra i dag.
Sentralt Lokalt
Førstelinje for sluttbrukere
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔
Ved oppkobling av nye tjenester, og oppdatering av tjenester ✔
Rapport
Side 155 av 157
Sentralt Lokalt
Innloggingsfeil og -sporing - for vertsorganisasjoner ✔
Innloggingsfeil og -sporing - for tjenesteleverandører ✔
Sporing for CERT, jukseprosess og lignende ✔ ✔
Henvendelser fra eduGAIN-organisasjoner og -tjenester ✔
Datakvalitet ved vertsorganisasjon. Ansvar og ressursbruk rundt datakvalitet blir uendret
fra i dag
Sentralt Lokalt
Holde datakvaliteten oppe
✔
Ved oppkobling, oppdatering og fusjon av vertsorganisasjon ✔
Sjekk av kvalitet ved behov/ønske ✔
Løpende oversikt over kvalitet ved innlogginger ✔
Innloggingstjeneste for web. Ansvar og ressursbruk rundt innloggingstjenesten blir uendret
fra i dag.
Sentralt Lokalt
Støtte SAML2-profil for Feide ✔
Støtte SAML2-profil for eduGAIN ✔
Tilgangskontroll tjenester/vertsorg (gjensidig åpning) ✔
Tilgangskontroll informasjonselementer (attribute release policy)
✔
Oversettelse av attributtformater etter tjenestens behov ✔
Universell utforming, responsiv design, gjenkjennbarhet ✔
Drift av IdP eksponert mot verden ✔
Tilgjengelighet, redundans, sikkerhet og DDoS-beskyttelse mot verden osv
✔
Drift av LDAP-katalog eksponert mot Feide ✔
Rapport
Side 156 av 157
Sterk autentisering. Ansvar og ressursbruk rundt sterk autentisering blir uendret fra i dag.
Sentralt Lokalt
Tilby sterk autentisering (nivå 3 nå, sannsynligvis nivå 4 senere)
✔
Administrere bruk av sterk autentisering mot tjenester ✔ ✔
Blokkere tilgang til tjenester om bruker ikke er sterkt nok autentisert
✔
Tjenestestartet sterk autentisering ved behov ✔
Statistikk. Statistikkfunksjonalitet vil være uendret fra i dag.
Sentralt Lokalt
Statistikk for føderasjonen som helhet (rapportering til KD o.l.)
✔
Statistikk for vertsorganisasjon rundt bruk av tjenester i føderasjonen
✔
Statistikk for tjenesteleverandører om bruk gjennom føderasjonen
✔
Funksjonalitet til Dataporten. Funksjonaliteten Dataporten benytter vil være uendret fra
i dag.
Sentralt Lokalt
Tilby innlogging, sterk autentisering, tjenestestartet sterk autentisering
✔
Tilby brukerinformasjon i og utenfor innloggingssesjon ✔
Tilby gruppeinformasjon (Administrerte grupper) ✔
Tilby personsøk ✔
Rapport
Side 157 av 157
Policypåvirkninger
Kontrakter vil ikke endres.
Policyer rundt informasjonsmodell og hvordan disse representeres vil ikke endres.
Betalingsmodellen vil ikke endres.