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.