You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Autentiserte sluttbrukere skal kunne hente en dialog for en party som de har en eller annen rettighet for; det vil si at minst en av følgende må stemme:
De er av party blitt gitt tilgang til en rolle/accessgroup som omfatter tjenesteressursen dialogen tilhører (aka "rolledelegering")
De er av party blitt gitt tilgang til én eller flere actions (på en eller flere subressurser) for den aktuelle tjenesteressursen (aka "tjenestedelegering")
De er av party blitt gitt tilgang til én eller flere actions (på en eller flere subressurser) for den aktuelle dialogen (aka "instansdelegering")
Hvis en eller flere av de overstående stemmer, skal altså tilgang gis til å lese dialogen, tilhørende aktivitetshistorikk, actions og dialogelementer. Dette omtales i akseptansekriteriene under som "tilgang til dialogen".
Men Dialogporten skal også vise i dialogen hvilke actions og dialogelementer den aktuelle sluttbrukeren ikke er autorisert for å hente og eller utføre.
Dialogporten har i XACML-arkitekturen her rollen som PEP, altså Policy Enforcement Point, og skal da sørge for at de aktuelle policyene som ligger til grunn blir etterlevd. Altinn.Common.PEP er et bibliotek som tilbyr modeller, en hjelper og en standardimplementasjon av en HTTP-klient som kaller Decision-API-et i Altinn Autorisasjon. Med denne kan det bygges opp en "authorization request" som lar en sjekke om tilgang til en gitt ressurs foreligger.
The content you are editing has changed. Please copy your edits and refresh the page.
GITT en autentisert GET-forespørsel fra en sluttbruker for en dialog som eksisterer NÅR Altinn Autorisasjon indikerer at tilgang til dialogen ikke foreligger SÅ skal API-et returnere 403 Forbidden og retunere en feilmeldingsmodell som indikerer at man ikke har tilgang til dialogen
GITT en autentisert GET-forespørsel fra en sluttbruker for en dialog som eksisterer NÅR Altinn Autorisasjon indikerer at tilgang til dialogen foreligger SÅ skal API-et returnere 200 OK OG berike responsmodellen med isAuthorized: false for alle actions hvor sluttbrukeren ikke har rettigheten indikert av action, evt for oppgitt autorisasjonsressurs OG berike responsmodellen med isAuthorized: false for alle dialogelementer hvor sluttbrukeren ikke har rettigheten read, evt for oppgitt autorisasjonsressurs OG returnere responsmodellen
Implementasjonsnotater
Det skal altså bygges en request basert på hva dialogen inneholder av actions og dialogelementer med tilhørende autorisasjonsattributter, hvis oppgitt. En dialog som inneholder
Tre actions: read, submit, sign
Et dialogelement som har definert authorizationAttribute: urn:altinn:subresource:some-subresource (krever da "read")
skal da føre til at det bygges en request ala følgende:
Klikk for å se XACML request i JSON-format
{"Request": {"ReturnPolicyIdList": false,/* AccessSubject inneholder informasjon om autentisert bruker. Her kopierer vi inn alle claims fra tokenet som starter med "urn:altinn"; det mest sentrale her er urn:altinn:userid. Se under for eksempler på claims som kommer fra tokens vi får: */"AccessSubject": [{"Id": "s1",// Brukt for multirequests"Attribute": [{"AttributeId": "urn:altinn:userid","Value": 1234},{"AttributeId": "urn:altinn:partyid","Value": 1234},{"AttributeId": "urn:altinn:authenticatemethod","Value": "IDPorten"},{"AttributeId": "urn:altinn:authlevel","Value": "3"}]}],/* Action er handlingene som vi ønsker å sjekke om kan autoriseres */"Action": [{"Attribute": [{"Id": "a1","AttributeId": "urn:oasis:names:tc:xacml:1.0:action:action-id","Value": "read"},{"Id": "a2","AttributeId": "urn:oasis:names:tc:xacml:1.0:action:action-id","Value": "submit"},{"Id": "a3","AttributeId": "urn:oasis:names:tc:xacml:1.0:action:action-id","Value": "sign"}]}],/* Resource inneholder informasjon om ressursene vi ønsker å sjekke. */"Resource": [{// Dette er dialogen i seg selv "Id": "r1",// Brukt for multirequests"Attribute": [{"AttributeId": "urn:altinn:resource",// serviceresource"Value": "super-simple-service"},{"AttributeId": "urn:altinn:resourceinstance","Value": "f4e6df3c-7434-44c3-875e-8dca1cdf0b20"},// Dette er party på dialogen. Støtte kun organisasjonsnummer pt, se #122{"AttributeId": "urn:altinn:organizationnumber","Value": "912345678"}]},{// Dette er subressursen"Id": "r2","Attribute": [{"AttributeId": "urn:altinn:resource",// serviceresource"Value": "super-simple-service"},{"AttributeId": "urn:altinn:subresource",// authorizationattribute"Value": "some-subresource"},{"AttributeId": "urn:altinn:resourceinstance","Value": "f4e6df3c-7434-44c3-875e-8dca1cdf0b20"},{"AttributeId": "urn:altinn:organizationnumber","Value": "912345678"}]}],/* Denne brukes for å konstruere separate forespørsler som PDP besvarer individuelt. Ved hjelp av "id"-attributtet på action og resource kan man formulere flere forspørsler som alle kan ha ulike svar basert på hva brukeren vi ønsker å autorisere (her "subject"), som det alltid bare er én av i en request som denne. */"MultiRequests": {"RequestReference": [{"ReferenceId": [// Kan subject gjøre "read" på denne dialogen?"s1","r1","a1"]},{"ReferenceId": [// Kan subject gjøre "submit" på denne dialogen?"s1","r1","a2"]},{"ReferenceId": [// Kan subject gjøre "sign" på denne dialogen?"s1","r1","a3"]},{"ReferenceId": [// Kan subject gjøre "read" på subressursen "some-subresource" i denne dialogen?"s1","a1","r2"]}]}}
Klikk for å se eksempel på JWT token payload for en person
elsand
changed the title
Implementere autorisasjonskontroll på detaljvisninger av Dialoger
Implementere autorisasjonskontroll på detaljvisninger av dialoger for sluttbrukere
Jul 6, 2023
Autentiserte sluttbrukere skal kunne hente en dialog for en party som de har en eller annen rettighet for; det vil si at minst en av følgende må stemme:
Hvis en eller flere av de overstående stemmer, skal altså tilgang gis til å lese dialogen, tilhørende aktivitetshistorikk, actions og dialogelementer. Dette omtales i akseptansekriteriene under som "tilgang til dialogen".
Men Dialogporten skal også vise i dialogen hvilke actions og dialogelementer den aktuelle sluttbrukeren ikke er autorisert for å hente og eller utføre.
Dialogporten har i XACML-arkitekturen her rollen som PEP, altså Policy Enforcement Point, og skal da sørge for at de aktuelle policyene som ligger til grunn blir etterlevd. Altinn.Common.PEP er et bibliotek som tilbyr modeller, en hjelper og en standardimplementasjon av en HTTP-klient som kaller Decision-API-et i Altinn Autorisasjon. Med denne kan det bygges opp en "authorization request" som lar en sjekke om tilgang til en gitt ressurs foreligger.
Tasks
Akseptansekriterier
GITT en autentisert GET-forespørsel fra en sluttbruker for en dialog som eksisterer
NÅR Altinn Autorisasjon indikerer at tilgang til dialogen ikke foreligger
SÅ skal API-et returnere 403 Forbidden og retunere en feilmeldingsmodell som indikerer at man ikke har tilgang til dialogen
GITT en autentisert GET-forespørsel fra en sluttbruker for en dialog som eksisterer
NÅR Altinn Autorisasjon indikerer at tilgang til dialogen foreligger
SÅ skal API-et returnere 200 OK
OG berike responsmodellen med isAuthorized: false for alle actions hvor sluttbrukeren ikke har rettigheten indikert av
action
, evt for oppgitt autorisasjonsressursOG berike responsmodellen med isAuthorized: false for alle dialogelementer hvor sluttbrukeren ikke har rettigheten
read
, evt for oppgitt autorisasjonsressursOG returnere responsmodellen
Implementasjonsnotater
Det skal altså bygges en request basert på hva dialogen inneholder av actions og dialogelementer med tilhørende autorisasjonsattributter, hvis oppgitt. En dialog som inneholder
skal da føre til at det bygges en request ala følgende:
Klikk for å se XACML request i JSON-format
Klikk for å se eksempel på JWT token payload for en person
Klikk for å se eksempel på JWT token payload for en systembruker
Se også
The text was updated successfully, but these errors were encountered: