Gå til hovedinnhold

Tilgangstyring for studenter og ansatte

info
  • ⏪ Ikke validert: Prosessen er ennå ikke validert/standardisert. Siden viser enten: 1) Dokumentasjon av gjeldende praksis; 2) En prosess som er identifisert, men ikke dokumentert. 3) Prosessen er under vurdering.
  • Denne prosessbeskrivelsen er ment som dokumentasjon av gjeldende praksis. Prosessen er ennå ikke standardisert.

FS kan integreres med brukerinformasjonssystemer for å sørge for at studenter og ansatte får de riktige tilgangene både i FS, og i andre systemer som er integrert med FS. Datautvekslingen vil variere avhengig av om brukeren er student eller ansatt. For studenter er FS masterdatakilde for grunnleggende personopplysninger, og det er også FS-data som avgjør om studenten skal ha en aktiv brukerkonto. For ansatte er det ansattsystemet som er masterdatakilde både for grunnleggende personopplysninger og aktiv-status. Ansatte kan være fagpersoner, administrativt ansatte eller andre typer ansatte. Organisasjonens brukerinformasjonssystem er normalt masterdatakilde for brukernavn (Feide-bruker) og e-postadresse. Se dokumentasjon for Felles IAM for mer informasjon om hvordan brukerinformasjon håndteres i Sikts produktportefølje.

Prosessen for vedlikehold av brukerinformasjon har tre hoveddeler:

  1. Aktivere bruker
  2. Vedlikeholde informasjon om brukeren
  3. Deaktivere bruker

1 Vedlikeholde brukerinformasjon for studenter​

For å vedlikeholde brukerinformasjon om studenter, må brukeradministrasjonssystemet lytte på hendelser i FS. Brukeradministrasjonssystemet avgjør hvilken status studenten skal ha, og oppdaterer FS med riktige data.

1.1 Aktivere studentbruker​

For at studenten skal få en aktiv brukerkonto, må brukeradministrasjonssystemet få informasjon om at studenten er aktiv. Kriteriet er normalt at studenten har fått en aktiv studierett på et emne, et studieprogram eller et EVU-kurs. For å avgjøre om dette har skjedd, må klienten lytte på hendelser i FS.

1.1.1 Trigge aktivering av bruker​

I FS GraphQL API kan du følgende hendelsesspørringer for deler av denne prosessen: Query.studenthendelser:

  • STUDENT_STARTET_PA_STUDIEPROGRAM - Studenten har fått en aktiv studierett på et studieprogram

Query.emneSoknadshendelser:

  • EMNE_SOKER_TATT_OPP - Studenten har fått studierett på et emne

Query.evuKursSoknadshendelser:

  • EVU_KURS_SOKER_TAKKET_JA - Studenten har fått studierett på et EVU-kurs

Flere relevante hendelser vil komme etterhvert. Kontakt gjerne fs-support@sikt.no dersom du har behov for andre hendelser enn den som er nevnt her.

Felles IAM bruker foreløpig meldingskøfunksjonaliteten i FS-APIet for å lytte på hendelser om studenter. Enkelte læresteder bruker også FSWS-BAS (avvikles etter 31.03.2027) til dette formålet.

1.1.2 Oppdatere studenten med riktig brukerinformasjon​

Når brukeren er aktivert i brukeradministrasjonssystemet, må FS oppdateres med brukernavn og eventuelt tildelt e-postadresse.

I FS GraphQL API kan du bruke Mutation.angiBrukerinformasjon til dette formålet.

Felles IAM bruker foreløpig FS-APIet for å oppdatere brukerinformasjon for studenter. FSWS-BAS (avvikles etter 31.03.2027) har også hatt funksjonalitet for å angi brukernavn for studenter, men end of service for disse endepunktene har nå passert.

1.2 Vedlikeholde informasjon om studentbruker​

Siden FS er masterdatakilde for studentopplysninger, må brukeradministrasjonssystemet lytte på en rekke hendelser i FS:

  • Nye studieretter som får betydning for brukerens gyldighetsperiode (se under pkt. 1 over)
  • Endringer i studentens personopplysninger, som navn og telefonnummer kan hentes via Query.studenthendelser:
    • ENDRET_NAVN - Studentens navn er endret
    • ENDRET_MOBILNUMMER - Studentens mobilnummer

Det kan være andre hendelser som er aktuelle, avhengig av hvilke data som behandles i brukeradministrasjonssystemet.

Felles IAM bruker foreløpig meldingskøfunksjonaliteten i FS-APIet for å lytte på hendelser om studenter. Enkelte læresteder bruker også FSWS-BAS (avvikles etter 31.03.2027) til dette formålet.

1.3 Deaktivere studentbruker​

Siden FS er masterdatakilde for studentopplysninger, må brukeradministrasjonssystemet lytte på hendelser i FS for å deaktivere brukeren.

1.3.1 Avgjøre når brukeren skal deaktiveres​

Brukeren skal normalt deaktiveres når studenten ikke lenger har en aktiv studierett. Det betyr at brukeradministrasjonssystemet må cache studentens aktive studieretter på studieprogrammer, emner og EVU-kurs, og sette gyldighetsperiode for brukeren basert på studierettenes gyldighetsperioder. Brukeradministrasjonssystemet må også lytte på hendelser som endrer gyldighetsperioden for studentens studieretter.

FS GraphQL API tilbyr følgende hendelser i Query.studenthendelser:

  • SLUTTET_PA_STUDIEPROGRAM
  • STUDIERETT_FORLENGET
  • DODSFALL

For studieretter på emner, er det terminen som avgjør gyldighetsperioden.

For studieretter på EVUkurs er det kursperioden som avgjør. FS GraphQL API tilbyr følgende hendelse i Query.evuKurshendelser:

  • EVU_KURS_PERIODE_ENDRET

Felles IAM bruker foreløpig meldingskøfunksjonaliteten i FS-APIet for å lytte på hendelser om studenter. Enkelte læresteder bruker også FSWS-BAS (avvikles etter 31.03.2027) til dette formålet.

1.3.2 Deaktivere brukeren​

Når studentbrukeren skal deaktiveres, kan du bruke Mutation.angiBrukerinformasjon. Sett tomme strenger for de feltene som skal nullstilles.

2 Vedlikeholde brukerinformasjon for fagpersoner​

For fagpersoner er det ansattsystemet som er masterdatakilde for grunnleggende personopplysninger og aktiv-status.

2.1 Opprette eller aktivere fagperson​

Når en fagperson blir aktiv i personalsystemet, må vedkommende opprettes eller aktiveres i FS. FS GraphQL API har støtte for å opprette fagpersoner med eller uten norsk fødselsnummer.

2.1.1 Opprette fagperson med fødselsnummer​

FS GraphQL API har støtte for å opprette fagpersoner som har norsk fødselsnummer, D-nummer eller erstatningsnummer. Mutation.opprettFagpersonForGittFodselsnummer tar inn grunnleggende personopplysninger om fagpersonen. Hvis det finnes en person-profil for det oppgitte fødselsnummeret, vil den bli oppdatert med de oppgitte opplysningene. Hvis navnet som sendes inn, ikke samsvarer med navnet i person-profilen, vil det bli registrert en navneendring for personen. Hvis det ikke finnes en person-profil, blir den opprettet. Til slutt blir det opprettet en fagperson-oppføring.

mutation OpprettFagperson {
  opprettFagpersonForGittFodselsnummer(
    input: [
      {
        eierOrganisasjonskode: "1234", 
        fodselsnummer: "11623790055", 
        fornavn: "Pia-Zofia", 
        etternavn: "Hermod-Hansen", 
        privatEpost: "piazofiahermodhansen@test.com", 
        mobilTelefon: {
          landnummer: "+47", 
          nummer: "12321211"}, 
        arbeidsAdresse: {
          co: "", 
          gate: "Bråkmakergata", 
          postnummerOgSted: "1234 Oslo", 
          land: ""}}]
  ) {
    opprettFagpersonForGittFodselsnummerResult {
      personProfil {
        id
      }
      fagperson {
        id
      }
    }
    errors {
      ... on Error {
        path
        message
      }
    }
  }
}

Eksempel på svar:

{
  "data": {
    "opprettFagpersonForGittFodselsnummer": {
      "opprettFagpersonForGittFodselsnummerResult": [
        {
          "personProfil": {
            "id": "NzY6MTIzNCw5Mjg"
          },
          "fagperson": {
            "id": "MzE6MTIzNCw5Mjg"
          }
        }
      ],
      "errors": []
    }
  }
}

Felles IAM bruker foreløpig FS-APIet for å opprette fagpersoner med fødselsnummer. Det er inntil videre også mulig å opprette fagpresoner med fødselsnummer via følgende APIer:

Det har også vært mulig å opprette fagpersoner via FSWS-BAS, men end of service for dette endepunktet har passert.

2.1.2 Opprette fagperson uten fødselsnummer​

Dersom fagpersonen ikke har norsk fødselsnummer, kan du opprette fagpersonen via Mutation.opprettFagpersonGittPass. Fagpersonen må identifiseres med navn, fødselsdato, kjønn og passnummer.

Felles IAM bruker foreløpig Gemini for å opprette fagpersoner uten fødselsnummer.

2.1.3 Aktivere fagperson​

Dersom fagpersonen allerede finnes i FS, kan den aktiveres via Mutation.aktiverFagpersoner. I forbindelse med aktivering kan du sette brukernavn, e-postadresse, organisasjonsenhet og campus.

mutation AktiverFagperson {
  aktiverFagpersoner(
    input: {
      id: "MzE6MTIzNCw4ODE"
    }
  ) {
    fagpersoner {
      id
      aktiv
    }
    errors {
      ... on Error {
        path
        message
      }
    }
  }
}

Eksempel på svar:

{
  "data": {
    "aktiverFagpersoner": {
      "fagpersoner": [
        {
          "id": "MzE6MTIzNCw4ODE",
          "aktiv": true
        }
      ],
      "errors": null
    }
  }
}

Felles IAM bruker foreløpig FS-APIet (POST /personer/{id}) for å aktivere fagpersoner. Det er inntil videre også mulig å aktivere fagpersoner via følgende APIer:

2.2 Vedlikeholde informasjon om fagperson​

Dersom nøkkelinformasjon om fagpersonen endrer seg i kildesystemet, må FS oppdateres med endringene. Du kan for eksempel endre navn på fagpersonen i FS med følgende mutasjoner:

  • endrePersonProfilNavn

Kontakt fs-support@sikt.no hvis du ikke finner en mutasjon som passer.

Felles IAM bruker foreløpig FS-APIet for å vedlikeholde informasjon om fagpersoner.

Fagpersoner kan inntil videre også vedlikeholdes via FSWS-CRUD (REST) (avvikles etter 31.03.2026).

Det har tidligere vært mulig å vedlikeholde fagpersondata via FSWS-BAS (REST), men end of service for dette endepunktet har passert.

2.3 Registrere permisjon for fagpersonen​

Det er mulig å registrere at fagpersonen er i permisjon, dersom vedkommende er midlertidig fraværende. Foreløpig er det bare mulig å gjøre dette via POST /personer/{id} i FS-APIet. Du registrerer at fagpersonen er i permisjon ved å sette "permisjon" til true. Du kan avslutte permisjonen ved å sette "permisjon" til false.

2.4 Deaktivere fagperson​

Fagpersonen må deaktiveres i FS når vedkommende slutter i stillingen sin, eller det kortvarige engasjementet er avsluttet.

mutation DeaktiverFagperson {
  deaktiverFagpersoner(
    input: {
      id: "MzE6MTIzNCw4ODE"
    }
  ) {
    fagpersoner {
      id
      aktiv
    }
    errors {
      ... on Error {
        path
        message
      }
    }
  }
}

Eksempel på svar:

{
  "data": {
    "deaktiverFagpersoner": {
      "fagpersoner": [
        {
          "id": "MzE6MTIzNCw4ODE",
          "aktiv": false
        }
      ],
      "errors": null
    }
  }
}

Det er også mulig å nullstille brukerinformasjon når du deaktiverer fagpersonen.

Felles IAM bruker foreløpig FS-APIet (POST /personer/{id} og PATCH /personer/{id}) for å deaktivere fagpersoner. Det er inntil videre også mulig å deaktivere fagpersoner via UPSERT Fagperson (avvikles etter 31.03.2026) i FSWS-CRUD (REST).

3 Studieadministrativt ansatte​

Studieadministrativt ansatte vil normalt opprettes som saksbehandlere i FS. Det må som regel også opprettes en bruker med riktige rettigheter til FS-klienten. FS GraphQL API har foreløpig ikke støtte for å opprette studieadministrativt ansatte, men du kan bruke Mutation.angiBrukerinformasjon for å registrere og fjerne Feide-brukernavn og tildelt e-postadresse, dersom person-profilen finnes i FS fra før.

Det er også mulig å opprette personer via følgende APIer:

4 Andre kategorier av ansatte​

Det vil også fra tid til annen være behov for å opprette andre kategorier av ansatte i FS. FS GraphQL har føreløpig ingen direkte støtte for dette behovet, men du kan bruke Mutation.angiBrukerinformasjon for å registrere og fjerne Feide-brukernavn og tildelt e-postadresse, dersom person-profilen finnes i FS fra før.

Det er også mulig å opprette personer via følgende APIer: