Konsolider Actor, DialogUserType, PartyIdentifier, og ClaimsPrinsiple(?)

[MagnusSandgren]

Introduction

I dag har vi noen ganske like konsepter (se tittel) hvor grensene mellom dem er noe uklare. Kan vi konsolidere disse konseptene og dermed forbedre toolingen/koden vår?

Description

Konseptet om en aktør/bruker/identitet er ganske spredt p.t. i Dialogporten. Hvem er det som kaller oss, på vegne av hvem? Hvordan representeres identiteten deres gjennom systemet? Hvor mange ganger resolver vi identiteten deres i de forskjellige lagene i systemet vårt? Hvor og hvordan valideres aktøren? Burde dette være et cross cutting consern, og i så fall - i hvilket lag (applikasjon/domene/presentasjon)? Burde vi konsolidere identiteten fra presentasjonslag til applikasjonslag?

• ServiceOwnerOnBehalfOfPersonMiddeware - Legger til / overrider pid claim i ClaimsPrinciple dersom enduserid ligger som query parameter.
• UserTypeValidationMiddeware - Validerer at brukeren ikke er DialogUserType.Unknown, men ligger bare på web api presentasjonslaget (ikke graphql).
• user id representeres både på urn format samt kun et personnummer (fra token).

Kunne vi på en eller annen måte samlet disse konseptene til et konsept, og på en cross cutting måte, helst på applikasjonsnivå, resolvet, konsolidert og verifisert identitet chainen (bruker på vegne av noen) til en scoped ressurs som vi kunne brukt videre mot bl.a. altinn autorisasjon?

Implementation

If there are guidelines on architecture or other implementation choices, they are added here. Different approaches can also be discussed here.

Tasks

Preview Give feedback

1. Implementation tasks are added here
2. Prepare documentation (if relevant - either update working document, or add a new file in docs)
3. Add e2e-test (if relevant)

Threat modelling

Preview Give feedback

1. Does this change introduce any potential security issues?

Acceptance criteria

GIVEN ...
WHEN ....
THEN ...

GIVEN ...
WHEN ....
THEN ...

[elsand]

Disse er relaterte, men er til syvende og sist ulike konsepter. Vi må skille mellom autentisert identititet (som kan være via en tjenesteeier) og bare referanser til andre identitier (dialog.party og actor.actorid). PartyIdentifier er i så måte bare en felles enkoding.

Vi kan nok sikkert se på begrepsbruk og for den saks skyld implementasjon (mht middlewares), men hvordan disse konseptene skal kunne konsolideres sliter jeg med å se.

Fjerner tag på denne og lar denne ligge til evt. opprydding senere (kanskje ifm #647)