Kartlegging av behov for sammenkopling av Feide og lokale innloggingsløsninger

Transkript

1 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

2 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 vertsorganisasjonene. 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. Side 2 av 157

3 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. Side 3 av 157

4 Behovskartleggingen, analysen og anbefalingene i rapporten bygger på flere informasjonskilder, 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 vertsorganisasjonene. 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: Lokal Microsoft AD 76% Azure AD 17% Google Directory Google Directory med kopling mot Feide 4% 3% 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. Side 4 av 157

5 For det andre behovsområdet, sammenkopling av Feide med lokale løsninger for tjenesteinnlogging, oppga vertsorganisasjonene at følgende løsninger ble brukt: Lokal Microsoft AD 51% Lokal ADFS Azure AD MinId BankId 14% 12% 9% 8% Google Directory Facebook/Twitter/annen social login 3% 2% 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 sammenkopling 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 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. Side 5 av 157

6 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 arbeidsgruppens 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 ikkerespondentene 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 tilknytningsavgiften som følge av tiltak hos Feide sentralt. Side 6 av 157

7 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 vertsorganisasjonene 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. Side 7 av 157

8 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 tilpasningsmuligheter. Disse organisasjonene har høy teknisk kompetanse, og større økonomisk spillerom. På den andre siden, har vi organisasjoner som ønsker enkelhet og forutsigbarhet, 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. Side 8 av 157

9 Innhold 1 Innledning Bakgrunn Metode og aktiviteter Dokumentreferanser Begrepsliste Informasjonsinnhenting Innledning Dokumenter Spørreundersøkelse sendt til vertsorganisasjonene Arbeidsgruppen Løsningsalternativer Oppsummering Diskusjon Gevinster Innledning Gevinsttyper Beskrivelse av gevinster Gevinst: bedret brukeropplevelse Gevinst: mindre behov for brukerstøtte Gevinst: potensielt bedret sikkerhet Gevinst: bedret omdømme Gevinst: økt handlingsrom Diskusjon Innledning Behov Brukstilfeller Muligheter Kostnader, ansvarsforhold og policy Gevinster Interesse Andre forhold Anbefaling Side 9 av 157

10 Vedlegg 1: Resultater fra spørreundersøkelsen V.1.1 Innledning V.1.2 Utforming V.1.3 Distribusjon V.1.4 Svarprosent V.1.5 Feilmarginer V.1.6 Funn: behov for sammenkopling av klientinnlogging med Feide V.1.7 Funn: behov for sammenkopling av Feide og andre innloggingsløsninger V.1.8 Funn: andre scenarioer V.1.9 Funn: type utstyr V.1.10 Funn: lokal katalog for klientinnlogging for ansatte V.1.11 Funn: type lokale innloggingsløsninger V.1.12 Funn: gevinster V.1.13 Funn: finansiering og gjennomføringskapasitet V.1.14 Funn: andre tilbakemeldinger Vedlegg 2: Spørsmålene i spørreundersøkelsen Vedlegg 3: Svar på spørsmål om andre scenarioer Vedlegg 4: Svar på spørsmål om andre tilbakemeldinger Vedlegg 5: Løsningsalternativer V.5.1 Dagens føderasjon V.5.2 Alternativ 1: Mesh V.5.3 Alternativ 2: Proxy V.5.4 Alternativ 3: Kerberos V.5.5 Alternativ 4: Revers proxy for tjenester V.5.6 Alternativ 5: Klientinnlogging med web-sso Side 10 av 157

11 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 SSOlø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. Side 11 av 157

12 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 Feides systemarkitektur Veileder: gevinstrealisering, DFØ Side 12 av 157

13 1.4 Begrepsliste Active Directory (AD) Active Directory Federation Services (ADFS) Attribute release policy Attributt Autentisering 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. Microsofts programvare for å håndtere føderering og SSO på tvers av virksomheter. Den støtter blant annet SAML-protokollen. Kontrakt som beskriver og håndhever hvilke attributter/informasjonselementer som kan overføres fra en vertsorganisasjon til en tjeneste ved innlogging. 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. Å 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. Side 13 av 157

14 Autentiseringspunkt Autorisasjon Identitetstjeneste 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. 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 adgangsrettigheter. Autorisering forutsetter normalt at brukeren er autentisert. Feide tilbyr autentisering, men overlater til tjenestene å gjøre autorisering basert på denne autentiseringen. Feides tjeneste for å levere informasjon om vilkårlig Feidebruker 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 Kerberos Kryssføderering 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) En autentiseringsprotokoll mye brukt mellom klienter og servere, for eksempel mellom et Active Directory og klientene koblet til dette. 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. Side 14 av 157

15 LDAP OAuth OpenID, OpenID Connect SAML Service Provider (SP) Single sign-on (SSO) Tjenesteleverandør 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. En protokoll for å gi kontrollert tilgang til ressurser. 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. 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. Sluttbrukertjeneste i en SAML2-føderasjon som benytter føderasjonens innloggingstjeneste(r) for autentisering og uthenting av informasjon om brukere. 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. 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). Side 15 av 157

16 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. Side 16 av 157

17 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 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 Side 17 av 157

18 Samarbeidsrelasjoner med tilsvarende aktivitet i og utenfor offentlig sektor, nasjonalt og internasjonalt Rammer for aktiviteter innenfor forskning og utvikling (FoU) og drift 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 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. Side 18 av 157

19 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 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: Side 19 av 157

20 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Universitet Fylkeskom mune Annen Høgskole Kommune Privat skoleeier Totalt Svarprosent 82% 61% 54% 39% 37% 36% 39% 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 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. Side 20 av 157

21 Lokal katalog for klientinnlogging: Lokal Microsoft AD 76% Azure AD 17% Google Directory 4% Google Directory med kopling mot Feide 3% Type lokale innloggingsløsninger: Lokal Microsoft AD 51% Lokal ADFS 14% Azure AD 12% MinId 9% BankId 8% Google Directory 3% Facebook/Twitter/annen social login 2% Side 21 av 157

22 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 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 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 Side 22 av 157

23 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 Arbeidsform Arbeidsgruppen gjennomførte tre møter: Arbeidsmøte 1, Hell, 28. august 2017: Informasjonsutveksling o o o o UNINETT presenterte overordnede løsningsscenarioer Institusjonene presenterte behov UNINETT delte ut noen hjemmeoppgaver til vertsorganisasjonene knyttet til nærmere beskrivelse av behov, gevinster og kostnader UNINETT presenterte utkast til spørreundersøkelse Arbeidsmøte 2, Værnes, 19. oktober 2017: Utforming av anbefalinger o o o o UNINETT presenterte resultatene fra spørreundersøkelsen UNINETT presenterte utkast til sluttrapport Detaljering av gevinster Diskusjon om anbefalinger Arbeidsmøte 3, videomøte, 7. november 2017: Ferdigstille anbefalinger o o UNINETT presenterte utkast av sluttrapporten 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. Side 23 av 157

24 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 tjenesteleverandø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 proxyarkitektur 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 vertsorganisasjonene 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. Side 24 av 157

25 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 vertsorganisasjoner (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. Side 25 av 157

26 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 Kerberosalternativet 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. Side 26 av 157

27 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å innloggingsflyter, 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 informasjonsmodell 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. Side 27 av 157

28 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 Feidefø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 vertsorganisasjonene 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 Side 28 av 157

29 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. Side 29 av 157

30 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. Side 30 av 157

31 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 budsjettmessige 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 budsjettmessige gevinster Kvalitative gevinster Mer effektive arbeidsprosesser (reduserte timeverk) Færre henvendelser, saker eller klager (reduserte timeverk) 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. Side 31 av 157

32 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. Side 32 av 157

33 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 tofaktor 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. Side 33 av 157

34 Gevinsttype Målsetninger Kvalitativ gevinst. 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 Interessenter 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. 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. Side 34 av 157

35 Gevinsttype Målsetninger Indirekte budsjettmessig gevinst. 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 Interessenter 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. IKT-avdelingene hos vertsorganisasjonene. Andre ansatte som får brukerhenvendelser hos vertsorganisasjonene, 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. Side 35 av 157

36 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 Målsetninger Triggere Interessenter Kvalitativ gevinst. Færre sikkerhetsbrudd hvor man får tilgang til Feide-innloggede tjenester uten gyldig autorisasjon. Delegering av autentiseringssteget til lokale innloggingsløsninger. 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. Side 36 av 157

37 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 Målsetninger Kvalitativ gevinst. 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 Interessenter Bedre brukeropplevelse og eventuelt færre sikkerhetshendelser. En Feide-tjeneste som støtter sentrale brukstilfeller. 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. Side 37 av 157

38 Gevinsttype Målsetninger Triggere Interessenter Kvalitativ gevinst 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. Delegering av funksjonalitet til vertsorganisasjoner som ønsker det slik at de kan utvide med lokale tilpasninger. Vertsorganisjoner med avanserte behov. Side 38 av 157

39 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ørreundersø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ørreundersøkelsen. Side 39 av 157

40 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 behovsområ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. Side 40 av 157

41 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: Lokal Microsoft AD 76% Azure AD 17% Google Directory 4% Google Directory med kopling mot Feide 3% 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. Side 41 av 157

42 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: Lokal Microsoft AD 51% Lokal ADFS 14% Azure AD 12% MinId 9% BankId 8% Google Directory 3% Facebook/Twitter/annen social login 2% 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 arbeidsgruppen. 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. Side 42 av 157

43 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 brukstilfellene 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: Side 43 av 157

44 Behov 1 Mesh 2 Proxy 3 Kerberos 4 Revers proxy 5 Klientinnlogging med web- SSO Sammenkopling av Feide med klientinnlogging AD Ja Ja Ja Nei Nei Azure AD Ja Ja Nei Nei Nei 1 GCDS Ja Ja Nei Nei Ja 2 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 Ja Ja Nei Som i dag Som i dag login Tilpasset login Ja Ja, med «on Nei Nei Nei per tjeneste behalf of» Lokal Attribute Ja Nei Nei Nei Nei Release Policy 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. Side 44 av 157

45 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 Klientinnlogging med web- SSO Kostnader Sentralt Lokalt Klassisk mesh: lav Hybrid mesh: høy Klassisk mesh: høy Hybrid mesh: høy Middels-Høy Middels-Høy Middels Middels 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. Side 45 av 157

46 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. Side 46 av 157

47 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 vertsorganisasjonene. 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. Side 47 av 157

48 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. Side 48 av 157

49 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 tilpasningsmuligheter. Disse organisasjonene har høy teknisk kompetanse, og større økonomisk spillerom. På den andre siden, har vi organisasjoner som ønsker enkelhet og forutsigbarhet, 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. Side 49 av 157

50 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 tjenesteleverandø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 vertsorganisasjonene 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. Side 50 av 157

51 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. Side 51 av 157

52 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 Side 52 av 157

53 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: 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Universitet Fylkeskom mune Annen Høgskole Kommune Privat skoleeier Totalt Svarprosent 82% 61% 54% 39% 37% 36% 39% 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. Side 53 av 157

54 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. Side 54 av 157

55 Formelen for beregning av feilmargin med 95 % konfidensnivå er: ± 1,96 50 % (1 50 %) utvalg populasjon utvalg populasjon 1 populasjon = antallet i gruppen utvalg = antall svar fra gruppen 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: Side 55 av 157

56 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. Feilmarginen 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 Feidepå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 Side 56 av 157

57 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 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. Side 57 av 157

58 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 66 34,2 % 13,1 % prioritet Nei, det er mindre viktig og bør ikke 27 14,0 % 5,4 % prioriteres 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 ,6 % Sum ,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. Side 58 av 157

59 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 vertsorganisasjoner 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 1 0,8 % som tar oss til andre FEIDE innlogginger som Salaby og Conexus, vi kommer da rett inn ved å trykke på FEIDE ikonet. 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 1 0,8 % har SSO, er brukarnamn og passord likt. 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 % Side 59 av 157

60 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 1 7,1 % negative konsekvenser. 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 1 14,3 % 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. 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 % Side 60 av 157

61 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 Side 61 av 157

62 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. Side 62 av 157

63 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 vertsorganisasjoner 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 ,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. Side 63 av 157

64 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. 1 0,8 % Snarveier ligger samlet ett sted. Elevene vår bruker ipad og disse er organisert i Airwatch, eleven logger 1 0,8 % seg på FEIDE i appen eller i nettleseren 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 % Side 64 av 157

65 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 % 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. Side 65 av 157

66 Lokale engangspassord (TOTP) Kameraovervåkning, adgangskontroll, Wordpress og print Logge seg inn i Canvas på tvers av institusjoner Office 365 lokalt Office 365 online 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. Slike integrasjoner støttes dersom det finnes et tilgjengelig webgrensesnitt. Dette er fullt mulig i dag. Feide legger ingen begrensninger, men forutsetter lokal bruker i Canvas-instans. 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. 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. Side 66 av 157

67 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. Side 67 av 157

68 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. Lokal Microsoft AD 76% Azure AD 17% Google Directory 4% Google Directory med kopling mot Feide 3% 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 Side 68 av 157

69 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: Lokal Microsoft AD 51% Lokal ADFS 14% Azure AD 12% MinId 9% BankId 8% Google Directory 3% Facebook/Twitter/annen social login 2% 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) Side 69 av 157

70 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: Bedre brukeropplevelse for de ansatte 40% Mindre arbeid for IKT-avdelingen(e) 19% Bedret sikkerhet 13% Mindre arbeid for administrasjonen 12% Bedre omdømme for din organisasjon 7% Ingen, for vi har allerede løst dette 5% Vi ser ingen direkte eller indirekte gevinster i dette scenarioet 4% 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. Side 70 av 157

71 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: Bedre brukeropplevelse for elevene/studentene 27% Mindre arbeid for IKT-organisasjonen sentralt i din organisasjon 14% Mindre arbeid for lærere/forelesere 14% Mindre arbeid for administrasjonen på skolene/universitetet/høyskolen 10% Mindre arbeid for administrasjonen 10% Bedret sikkerhet 10% Bedre omdømme for din organisasjon 7% Ingen, for vi har allerede løst dette 5% Vi ser ingen direkte eller indirekte gevinster i dette scenarioet 4% 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. Side 71 av 157

72 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 IKTlø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 Vi fikk følgende svar: Svar Totalt Universitet Fylkeskommune 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 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. Side 72 av 157

73 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: 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 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: Side 73 av 157

74 Lokale investeringer vs sammenkopling med klientinnlogging Sentrale investeringer vs sammenkopling med klientinnlogging r -0,037 r -0,193 r 2 0,001 r 2 0,037 Prioritet Prioritet Vurdering Totalt Vurdering Totalt Blank Blank Totalt Totalt Lokale investeringer vs sammenkopling med lokale innloggingsløsninger Sentrale investeringer vs sammenkopling med lokale innloggingsløsninger r -0,014 r -0,116 r 2 0,000 r 2 0,013 Prioritet Prioritet Vurdering Totalt Vurdering Totalt Blank Blank Totalt Totalt Vi ser at for alle fire varianter er det - som forventet en svak negativ korrelering mellom investeringsvilje og prioritet, r. Kvadratet av korreleringskoeffisienten, r 2, 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 r 2 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. Side 74 av 157

75 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. Side 75 av 157

76 Vedlegg 2: Spørsmålene i spørreundersøkelsen Side 76 av 157

77 Side 77 av 157

78 Side 78 av 157

79 Side 79 av 157

80 Side 80 av 157

81 Side 81 av 157

82 Side 82 av 157

83 Side 83 av 157

84 Side 84 av 157

85 Side 85 av 157

86 Side 86 av 157

87 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 ADpå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 å Side 87 av 157

88 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 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. Side 88 av 157

89 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 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. Side 89 av 157

90 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-signon/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 Side 90 av 157

91 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. Side 91 av 157

92 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): 550 Feide-tjenester og 1700 edugain-tjenester SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP sammenkoblinger Org A Org B Org C Org D 503 vertsorganisasjoner 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. Side 92 av 157

93 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: SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP 7 K 1 K 2 Lokal SP 1 SAML2 org profil Org D Lokal SP 2 Lokal SP 3 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. Side 93 av 157

94 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: SP 1 Org A Org B Org C Org D 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. Side 94 av 157

95 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 Side 95 av 157

96 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 Feidetjenesten. 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: Side 96 av 157

97 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. Side 97 av 157

98 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 Side 98 av 157

99 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. Side 99 av 157

100 Tekniske sammenkoplinger Figuren viser et bilde av sammenhengen i en klassisk mesh-føderasjon: 550 Feide-tjenester og 1700 edugain-tjenester SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP sammenkoblinger Org A Org B Org C Org D 503 vertsorganisasjoner 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. Side 100 av 157

101 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: 550 Feide-tjenester og 1700 edugain-tjenester SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP sammenkoblinger Org A Org B Org C Org D 503 vertsorganisasjoner 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 Side 101 av 157

102 ø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. Side 102 av 157

103 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: SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP 7 K 1 K 2 Lokal SP 1 Lokal SP 2 Lokal SP 3 Org D 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. Side 103 av 157

104 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. SP 1 Org A Org B Org C Org D 503 integrasjonspunkter 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. Side 104 av 157

105 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 Side 105 av 157

106 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. Side 106 av 157

107 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 Side 107 av 157

108 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 Side 108 av 157

109 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 Side 109 av 157

110 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 Feidebrukerkatalog. 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) Side 110 av 157

111 Tilgangskontroll informasjonselementer (attribute release policy) 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. 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. Tilby sterk autentisering (nivå 3 nå, sannsynligvis nivå 4 senere) Sentralt Lokalt 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. Side 111 av 157

112 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. Tilby innlogging, sterk autentisering, tjenestestartet sterk autentisering Sentralt Lokalt 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. Side 112 av 157

113 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. Side 113 av 157

114 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. Side 114 av 157

115 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. Side 115 av 157

116 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. Side 116 av 157

117 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 Side 117 av 157

118 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. Side 118 av 157

119 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 Side 119 av 157

120 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: Side 120 av 157

121 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. Side 121 av 157

122 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 Side 122 av 157

123 Ved oppkobling av nye tjenester, og oppdatering av tjenester 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. 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) Side 123 av 157

124 Oversettelse av attributtformater etter tjenestens behov Sentralt Lokalt 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. Tilby sterk autentisering (nivå 3 nå, sannsynligvis nivå 4 senere) Sentralt Lokalt 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 Side 124 av 157

125 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 Kerberosbasert 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. Side 125 av 157

126 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. Side 126 av 157

127 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. Side 127 av 157

128 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 Kerberossesjonen derfra. Side 128 av 157

129 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. SP 1 Org A Org B Org C Org D 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 Side 129 av 157

130 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: SP 8 3 SAML LDAP 1 Kerberos 6 2 Org D Steg: 1. Brukeren logger på sin lokale PC 2. Innloggingen valideres av AD og det opprettes en Kerberos-sesjon Side 130 av 157

131 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. Side 131 av 157

132 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 Side 132 av 157

133 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 Side 133 av 157

134 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 Side 134 av 157

135 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 Side 135 av 157

136 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. (+) Side 136 av 157

137 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 Side 137 av 157

138 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. Side 138 av 157

139 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. Side 139 av 157

140 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 Feidesesjoner kan gjenbrukes lokalt. Side 140 av 157