Skip to main content

FS-Admin Pålogging og tilgangskontroll i pilot

Her beskriver vi pålogging, tilgangskontroll og sikkerhet for FS Admin slik den er implementert i pilotfasen.

Pålogging og tilgangskontroll - kort fortalt​

Pålogging via Feide​

  • Gitt at du har aktiv feidebruker hos en av vertsorganisasjonene som FS-Admin er åpnet for
  • Når du logger på med Feide
  • Så får du logget inn i FS Admin

Tilgangskontroll etter pålogging​

  • Gitt at du har logget inn i FS Admin
  • Når du er registrert som saksbehandler i FS (og konto hverken er sperret eller utløpt på dato)
  • Så vil du ha tilgang på funksjonalitet i FS Admin

Mer om pålogging til FS-admin via Feide​

For å kunne bruke FS-Admin må du som ansatt først logge på og identifisere deg via Feide.

Forutsetninger for at ansatte får logge på FS Admin​

Følgende Feide-vertsorganisasjoner har aktivert tjenesten FS Admin via Feide pr dags dato, siden vi ikke kan skille mellom produksjons- og testmiljø i Feide:

  • HK-dir
  • Kristiania
  • Sikt
  • UiT Denne listen vil endre seg etterhvert som vi involverer flere piloterer og flere tar i bruk FS Admin.

Vi i Sikt/FS må gi læresteder tilgang til å aktivere tjenesten. Læresteder (og andre vertsorganisasjoner) godkjenner deretter aktiveringen via Feide.

Det er kun dersom du har aktiv feidebruker hos en av vertsorgansisasjonene over at du får logget inn i FS Admin.

Hva innebærer det at du logger inn​

Når du logger inn, så spør Feide deg som bruker om lov til å:

  • gi FS Admin tilgang til informasjon om hvem du er
  • bruke FS GraphQL-API på vegne av deg med dine tilgangsnivåer

Dette er litt teknisk, men følger av FS-strategien som krever at vi i Sikt/FS skal bruke de samme APIene som vi tilbyr til partnere og kunder i og utenfor utdanningssektoren.

Tilgangskontroll etter pålogging​

Etter at du som bruker har logget på og godkjent tilgangsforespørselen i Feide, så er det opptil FS Admin å vurdere hva slags funksjonalitet du skal få tilgang til. Vurderingen skjer på flere nivåer i tråd med prinsippet om forsvar i dybden. Se Digdirs veileder for detaljer.

Merk at vi i piloten legger innsatsen vår i sikkerhetstiltak i nivå 4, men at vi beskriver alle nivåene, siden vi kommer til å bruke flere i fremtiden.

Nivå 4 Databaselaget: Du må være registrert som bruker i FS Databasen (implementert i pilot)​

Hvis du ikke er registrert som aktiv saksbehandler i FS ved et lærested, vil du ikke få tilgang til noe funksjonalitet. Det vil si at dersom du ikke har FS-bruker, eller brukeren din er blitt sperret eller har utløpt på dato, så vil du få beskjed om at du ikke har tilgang til noen læresteder i grensesnittet.

Nivå 3 Tjenestelaget: Du får tilgang til konkret forretningslogikk og funksjonalitet ut fra din tilgangsrolle (ikke i pilot, utover er saksbehandler ved lærested)​

Tjenestelaget er der vi skriver forretningslogikk og funksjonalitet vi vil tilgjengeliggjøre. Alle forespørsler til FS GraphQL resulterer i kall til funksjonalitet i tjenestelaget vårt.

En viktig sikkerhetssjekk vi uanset gjør i dette laget er å verifisere at informasjonen fra Feide. Gitt at den er riktig og ikke for gammel, så beriker vi den med informasjon fra tilgangsstyringsdatabasen. Dermed kan vi utføre nødvendig forretningslogikk, inkludert tilgangskontroll.

Vi legger inn læresteder som skal bruke FS Admin eksplisitt i tjenestelaget, slik at det kan svare på om saksbehandlere ved lærestedet får bruke funksjonalitet i FS Admin.

Vi jobber nå aktivt med å få på plass selvbetjent tilgangsstyring og roller/rettighetspakker, så her kan dere forvente å se mer i tiden fremover.

Nivå 2 API-laget: GraphQL-API har ingen tilgangskontroll​

I fremtiden vil vi vurdere å se på bruk av tilgangskontroll også på dette laget for å øke sikkerheten ytterligere, men beste praksis for GraphQL anbefaler at vi fokuserer på de andre lagene først.

Nivå 1 Brukergrensesnittet: FS Admin viser funksjonalitet du har tilgang gitt underliggende nivåer​

Dersom du som bruker ikke har en tilknytning eller en rolle som tilsier at du skal få bruke funksjonalitet i løsningen, så vil vi heller ikke vise fram funksjonalitet.

Det å skjule funksjonalitet på denne måten handler først og fremst om brukervennlighet. Det er ikke hensiktsmessig å tro at du får utføre en oppgave, for deretter å få en feilmelding på at du ikke får utføre oppgaven.

Som følge av at vi ikke eksponerer tilgangsnøkler vi får fra Feide til sluttbrukeren, så kan vi i tillegg sørge for økt sikkerhet ved å nekte å ta imot forespørsler for brukere som ikke skal ha tilgang. Vi kan for eksempel stenge ute personer som har feidebrukere hos vertsorganisasjonen, men som ikke har relevant tilknytning.