Autorisasjon Guider Systemleverandør Systembruker Endre Systembruker

Endre rettigheter på systembrukere

Gjennomgang av hvordan man endrer rettigheter på Systembruker for eget system og for klientforhold

Endring av Systembruker for eget system

Det er bare Sluttbrukersystemleverandør (SBSL) som kan be om en endring av en Systembruker, dette fordi det er deres oppgave å vite hvilke tilganger som trengs for systemet, ihht hvordan de skal integrere seg mot en Tjeneste Eier sitt API. Men det er Sluttbruker selv som må godkjenne endringen, fordi det er Sluttbruker som “eier” SystemBrukeren. Dersom en organisasjon er både “leverandør” og sluttbruker, må de likevel igjennom prosessen med å opprette en endringsforespørsel, og deretter godkjenne den.

Hente en eksisterende systembruker for eget system

Du trenger systembruker-ID-en for å opprette en endringsforespørsel. Hent systembrukeren med byquery-endepunktet.

Kallet krever scopet altinn:authentication/systemuser.request.write i Maskinporten-tokenet.

Test (TT02): GET https://platform.tt02.altinn.no/authentication/api/v1/systemuser/vendor/byquery?system-id={system-id}&orgno={orgno}&external-ref={ekstern-ref}
Produksjon: GET https://platform.altinn.no/authentication/api/v1/systemuser/vendor/byquery?system-id={system-id}&orgno={orgno}&external-ref={ekstern-ref}

Parameteren external-ref er valgfri og brukes bare dersom den ble satt ved opprettelse.

Se Hente systembruker via spørring for full dokumentasjon av endepunktet, inkludert alle parametere og felter i responsen.

Opprettelse av en Forespørsel om Endring

SBSL må sende inn en Change Request til vårt API på endepunkt. Der må det oppgis Id for SystemBrukeren som kan hentes på et eget endepunkt; samt en unik ny uuid for selve endringsforespørselen.

For enten TT02 eller PROD:

Med Query Parameters:

correlation-id required , SBSL generer et gyldig UUID selv, unik for hver POST change request , brukes i senere GET call.
system-user-id required. Den unike UUID id for SystemBruker

Eksempel på Post request body’en kan vi ta imot disse fem feltene:

To lister for påkrevde og ikke-påkrevde enkelt rettigheter (Rights), to lister for påkrevde og ikke-påkrevde tilgangspakker (AccessPackages). I eksempelet nedenfor har vi lagt inn en verdi for Rights og en for AccessPackages. RedirectUrl er valgfri å bruke, men må være validerbar opp mot det som er forhåndsregistrert på systemet, på samme måte som for Create SystemUser.

{
  "requiredRights": [
    {
      "resource": [
        {
          "id": "urn:altinn:resource",
          "value": "authentication-e2e-test"
        }
      ]
    },
    {
      "resource": [
        {
          "id": "urn:altinn:resource",
          "value": "en-annen-test2"
        }
      ]
    }
  ],
  "unwantedRights": [
    {
      "resource": [
        {
          "id": "urn:altinn:resource",
          "value": "testressurs"
        }
      ]
    }
  ],
  "requiredAccessPackages": [
    {
      "urn": "urn:altinn:accesspackage:jordbruk"
    }
  ],
  "unwantedAccessPackages": [
    {
      "urn": "urn:altinn:accesspackage:skogbruk"
    }
  ],
  "redirectUrl": ""
}

Det er viktig å merke seg at det bare skal legges inn en resource pr Right, det er pr tid ikke støtte for sub-ressurser. Dersom det skal legges inn flere Rights er riktig syntax oppgitt over.

Alle endringer er Idempotente, dvs det er helt ok å prøve å legge til en ressurs som allerede er delegert, eller å prøve å fjerne en ressurs som ikke er delegert. Da vil det ikke skje noen.

Responsen fra Post vil inneholde en kopi av det innsendte, uavhengig av hva som allerede er delegert, samt en dyplenke (confirmUrl) til godkjennings-siden som SBSL så må gi til Sluttbruker på en trygg måte. Når sluttbruker følger dyplenken vil de bli spurt om å logge inn i Altinn via Idporten, og kan godkjenne forespørselen. Deretter vil endringen bli utført.

{
  "id": "107319e1-8e4c-47f4-85be-6bdbd8b97b7f",
  "externalRef": "f592dace-e26f-456d-bc8b-02cd6aff272d",
  "systemId": "312605031_Virksomhetsbruker",
  "systemUserId": "613bd887-b8a2-40ce-b7f2-ff31e40a4010",
  "partyOrgNo": "312220865",
  "requiredRights": [
	  {
		"resource": [
		{
			"id": "urn:altinn:resource",
			"value": "authentication-e2e-test"
		}]
	},
	{
	"resource": [
	{
		"id": "urn:altinn:resource",
		"value": "en-annen-test2"
	}
  ],
  "unwantedRights": [
    {
      "resource": [
        {
          "id": "urn:altinn:resource",
          "value": "testressurs"
        }
      ]
    }
  ],
  "requiredAccessPackages": [
	{
		"urn": "urn:altinn:accesspackage:jordbruk"
	}
  ],
  "unwantedAccessPackages": [
    {
      "urn": "urn:altinn:accesspackage:skogbruk"
    }
  ],
  "status": "New",
  "redirectUrl": "",
  "confirmUrl": "https://am.ui.at22.altinn.cloud/accessmanagement/ui/systemuser/changerequest?id=107319e1-8e4c-47f4-85be-6bdbd8b97b7f&DONTCHOOSEREPORTEE=true"
}

Den “id” som kommer i responsen, er den samme som SBSL sendte inn som en Correlation-id, og kan brukes til å følge status på endringsforespørselen. Etter at sluttbrukeren har trykket på Godkjenn, blir endringene gjennomført dersom den innloggede brukeren har de nødvendige fullmaktene til å gi systembrukeren de forespurte fullmaktene.

Flere Endringer

Hver Endringsforespørsel (Change Request) skal ha en Correlation-id som er en UUID som genereres av SBSL selv ved opprettelsen. Dersom det skal gjøres flere endringer på SystemBrukeren så må det opprettes en ny Correlation-id for hver endring. Det er ikke nødvendig å slette en Forespørsel, dersom SBSL ikke skal bruke den, den vil til slutt gå ut på tid og fjernes automatisk.

Endring av Systembruker for Klientforhold

Endring av Systembruker for Klientforhold er ikke mulig pt. De må slettes og opprettes på nytt. Det tilbys et klientdelegerings-API der SBSL kan hente ut hvilke fullmakter som er gitt, og lagre dem i sitt eget system. SBSL kan deretter opprette en ny systembruker med de ønskede fullmaktene, få den godkjent av tjenestetilbyderen og legge klientene til den nye systembrukeren én om gangen via API-et. Hvis noen av de tidligere klientene ikke kan legges til, kan årsaken være at klientene ikke har gitt fasilitatoren fullmakt til alle de nye tilgangspakkene. Dette håndteres enklest av SBSL selv. I et stort system er det sannsynlig at minst én klient mangler fullmakt til de nye tilgangspakkene. Derfor kan vi ikke tilby en endringsforespørsel der alt godkjennes i én operasjon.