Tilgangsstyring for utviklere

Dette må du få med deg

Alle views i configuration.xml skal ha et access-element som definerer tilgangsstyring. Du får ikke installere kjerneapi-skjemaet dersom et view mangler access; mvn install vil feile.

Ved installering blir det opprettet sikkerhets-retningslinjer for alle views og tabeller. Brukere som aksesserer et kjerneapi-view må eksplisitt gis tilgang. Er brukeren din ikke nevnt i en tilgangsliste, får den ikke tilgang.

Brukere

users-elementet i konfigurasjonen forteller hvilke brukere som skal opprettes i RAS. Her begrenser vi oss enn så lenge til én bruker for applikasjonsformål og én for integrasjonsformål. Sistnevnte tilgangskontrollerer vi basert på rollene som maskinbrukerenen har fått tildelt i FSWS_AUTH. Førstnevnte krever i tillegg at vi kjenner til sluttbruker, og at hen har nødvendig tilgang i FS.

<users>
    <user>APPLIKASJONSBRUKER</user>
    <user>MASKINBRUKER</user>
</users>

Ved installasjon av KJERNEAPI-skjemaet blir brukerne i users-elementet opprettet.

Merk at disse brukerne ikke er vanlige databasebrukere, men RAS-brukere. Oracle kaller de for applikasjonsbrukere i sin dokumentasjon

Hvilken bruker blir brukt?

Forespørsler som inneholder fødselsnummer (fra Feide eller sudo-header) bruker applikasjonsbruker. Andre forespørsler håndteres med maskinbruker.

Roller

roles-elementet forteller hvilke roller som finnes:

<roles>
    <role enabledByDefault="true">
        <name>STUDIEELEMENTER_LES1</name>
        <principals>
            <principal>APPLIKASJONSBRUKER</principal>
            <principal>MASKINBRUKER</principal>
        </principals>
    </role>
	...
</roles>

Her er name navnet på rolla og principals listen med brukere og roller som skal ha den.

enabledByDefault angir hvorvidt rolla blir aktivert automatisk ved oppretting av ny database-sesjon for brukeren. Dette må brukes med varsomhet. For eksempel er det mange ulike brukere, med ulike tilgangsnivåer som skal ha MASKINBRUKER-tilgang. Det betyr at flere roller ikke skal aktiveres automatisk. I stedet blir roller aktivert for brukeren dersom hen har den oppført i FSWS_AUTH.RASBRUKER_INSTITUSJON_ROLLE-tabellen.

En spesiell kontrolliste

Det finnes en spesiell tilgangskontrolliste, BYPASS_RAS_ACL. Denne blir gitt til databaserollen FS_WSROLE, for at den skal få omgå restriksjonene i tilgangsstyringen.

Domener (realms)

Alle tilgjengelige domener er definert i starten av configuration.xml.

Disse har et predikat som blir sjekket for å avgjøre om en view-rad (tabell-rad) tilhører skrankens domene. Predikatet 1=1 er sant for alle rader. Andre predikat gjør for eksempel en sjekk på databasesesjonens PLNR-attributt i forhold til viewets PLNR-kolonne.

Her er noen eksempeler sakset fra dagens konfigurasjon:

    <realmPredicates>
        <realmPredicate>
            <name>ALLE_RADER</name>
            <predicate><![CDATA[1=1]]></predicate>
        </realmPredicate>
        <realmPredicate>
            <name>SAKSBEHANDLER_STUDENT_FORBINDELSE</name>
            <predicate>
                <![CDATA[''J'' = Pk_Ras_Tilgang.F_Saksbehandler_Student_Forbindelse('
                         ||'Xs_Sys_Context(''KJERNEAPINS'',''PLNR''),'
                         ||'Plnr)]]>
            </predicate>
        </realmPredicate>
        ...

Hvordan kan jeg teste tilgangskontrollen?

Du kan enkelt teste tilgangskontroll ved å sette sudo-headere. Merk at dette bare fungerer mot miljø som kun inneholder syntetiske data. Dette vil dermed fungere for lokal utvikling og mot test-miljøet, men ikke demo og prod.

Vi støtter to forskjellige sudo-headere:

Sudo-Fodselsnr lar deg overstyre fødselsnummeret som forespørselen tilgangstyres etter.
Sudo-Roller lar deg overstyre hvilke tilgangsroller forespørselen skal tilgangsstyres etter.

Verdien til Sudo-Roller er en kommaseparert liste med roller. For eksempel "lanekassen_rolle,studinfoskriv".

Merk at for applikasjonsbrukere så utføres tilgangskontroll både for fødselsnummer og institusjonsroller så må oppgitt bruker ha nødvendige tilganger

Sudo-headere med GraphiQL

Settes ved å legge inn en json-verdi i Headers-fanen nederst i GraphiQL. For eksempel:

{
  "Sudo-Fodselsnr": "01514490283"
}

Sudo-headere med curl

Følgende fungerer med curl:

$ curl -u admin:admin \
       -H Content-Type:application/json \
       -H Sudo-Fodselsnr:01514490283 \
       -H Sudo-Roller:student \
       -d '{"query":"query { studenter(filter: { eierInstitusjonsnummer: \"1234\" }, first: 2) 
             { nodes { studentnummer }}}" }' \
       http://localhost:8080/graphql
   
$ curl -u admin:admin \
       -H Content-Type:application/json \
       -H Sudo-Fodselsnr:12587590814 \
       -H Sudo-Roller:saksbehandler \
       -d '{"query":"query { studenter(filter: { eierInstitusjonsnummer: \"1234\" }, first: 2) 
             { nodes { studentnummer }}}" }' \
       http://localhost:8080/graphql
	   
$ curl -u admin:admin \
       -H Content-Type:application/json \
       -H Sudo-Roller:studieelementer_les2 \
       -d '{"query":"query { fagpersoner(filter: { eierInstitusjonsnummer: \"1234\" },
                                         first: 2) 
             { nodes { fornavn }}}" }' \
       http://localhost:8080/graphql

Integrasjonstester

I tillegg til manuell testing så har vi enhetstester i kjerneapi-service. Let etter fila TilgangsTest.java. Her blir det gjort direkte sql som tester funksjonaliteten.

Videre finnes det integrasjonstester i fsapi-rest som bruker sudo-headere.

Direkte testing med databasebruker

Du kan også logge deg direkte på databasen som bruker ras_session_mgr (passord "FS_TEST") i imaget. Denne brukeren kan opprette sesjoner for ras-brukertyper. Du finner nødvendige invokasjoner i ConnectionManager.java:setupRasSession.

Slik kan du f.eks. starte en sesjon som maskinbruker med rollen studentdata_les1:

  DECLARE
      session_id VARCHAR2(32);
  BEGIN
      kjerneapi.pk_ras.create_and_attach(
          p_Institusjonsnr     => '1234',
          p_Applikasjonnavn    => NULL, 
          p_Applikasjonsroller => kjerneapi.pk_ras.t_rolleliste('studentdata_les1'),
          p_Fodselsnr          => NULL,
          p_SudoFodselsnr      => NULL,
          p_SessionId          => session_id
      );

      DBMS_OUTPUT.PUT_LINE('Session ID: ' || session_id);
  END;

Referanse til Oracles dokumentasjon

For mer informasjon om tilgangsstyringen, se Oracles RAS-dokumentasjon

Beslutningslogg for tilganger

Team Studieplanlegging føler et behov for å tracke diskusjoner/avgjørelser rundt tilgangskontroll. Vi håper dette dokumentet kan komme godt med.

Besluttet	Dokument	Beslutning
2024-01-10	Gradvis innføring av RAS	Vi ønsker en gradvis overgang til bruk av RAS
2024-01-10	Minimumstilgang for api-brukere	Vi ønsker at brukere av api-et får en minimums-tilgang
2024-01-29	Tilgang til fagpersoner og roller	Tilgang til Fagpersoner (uten tilgang til Personer)
2024-02-15	Tilgang til grunnleggende studentdata	Tilgang til grunnleggende data for studenter
2024-02-29	Tilgang til studenters protokoller	Tilgang til studenters protokoller i forbindelse med resultatutveksling
2024-04-12	Tilgang til studenters bankkontonummer	Tilgang til bankkontonummer krever en egen rolle
2024-04-15	Tilgang til flere studentdata	Tilgang til data for grunnleggende studieadministrative prosesser
2024-04-15	Tilgang til studenthendelser	Tilgang til studenthendelser
2024-04-30	Lese- og skrivetilgang til studentbilder	Tilgang til studentbilder
2024-05-10	Nye roller for tilgang til fagpersondata og personroller	Vi endrer på rollesettet for tilgang til fagpersondata og personroller
2024-05-10	Tilgang til utvekslingsopphold i Gemini	Midlertidig rolle for tilgang til utvekslingsopphold i Gemini (gammel modell)
2024-05-10	Tilgang til persondata	Tilgangsroller for klienter som skal behandle data om alle personer
2024-05-10	Tilgang til studieelementer	STUDIEELEMENTER_LES2 skal gi tilgang til grunnlagsdata som ikke alle brukere skal ha tilgang til
2024-05-10	Tilgang for godkjenning av ekstern utdanning
2024-06-12	Tilganger for utvekslingsstudenter	Vi oppretter tilgangsroller for henholdsvis innreisende og utreisende utvekslingsstudenter
2025-03-20	Tilgang til data om EVU-kursdeltakere
2025-03-26	Tilgang til emnesøknader
2025-03-27	Tilgang til undervisningsdata
2025-03-28	Tilgang til data om EVU-kurssøknader	EVU_OPPTAK_LES1 gir tilgang til EVU-kurssøknader. EVU_OPPTAK_HENDELSER_LES1 gir tilgang til EUV-kurssøknadshendelser.
2025-03-28	Tilgang til personprofilhendelser
2025-03-28	Tilgang til personrollehendelser	PERSONROLLE_HENDELSER_LES1 gir tilgang til alle personrollehendelser

Dette må du få med deg​

Brukere​

Hvilken bruker blir brukt?​

Roller​

En spesiell kontrolliste​

Domener (realms)​

Hvordan kan jeg teste tilgangskontrollen?​

Sudo-headere med GraphiQL​

Sudo-headere med curl​

Integrasjonstester​

Direkte testing med databasebruker​

Referanse til Oracles dokumentasjon​

Beslutningslogg for tilganger​