Other services will need to create notifications on behalf of an application owner

[SandGrainOne]

Description

There is a need for an "on behalf of" dimension to notification orders. The best example would be when "correspondence" includes the need for a notification. The application owner would order the creation of a correspondence using the correspondence API which in turn would send a request to notification. In order to track the notification back to the correct application owner we would need this as input from the corresponence application.

Additional Information

Separate specialiced endpoint with an admin scope that internal systems can use to order notifications on behalf of their users.

Refinement notes

• We need to know what Notifications should keep track of and what Correspondence will keep track of.
  • Do we (Notifications) need to know both that the order was placed by system and who it was for: Correspondence for SSB.

[olebhansen]

Yes, we need to know both the client (i.e. internal service issuing the call as part of a bundeled service) and the actual service owner (the on-behalf-of part).

[olebhansen]

@olebhansen : add contents from discussion on what stats to provide and if this can be extracted from existing API usage info. Can be extracted from the Maskinporten-token (it will have claims set, that can be used for this purpose). Need to understand the process and if some explicit delegation is needed and/or if that will result in a too-convoluted process.

[olebhansen]

Extracting some snippets that might inform the thinking or otherwise be relevant:

en utfordring er å propagere sluttbruker-konteksten fra f.eks. app A, som tar i mot trafikk fra en klient med JWT fra ID-Porten, til app B som kun kan nås over mTLS internt i clusteret. Authorizationpolicy kan styre hvilke verb og paths som app A kan bruke hos app B, men det blir opp til app A å styre hva en gitt bruker får lov til å gjøre av kall videre.

... har vi god nytte av OAuth2.0 Token Exchange (eller on-behalf of) for å sikre at brukerkontekst sendes med videre ned mot mikrotjenester.

Et alternativ man kan vurdere er å bare propagere tokenet fra ID-porten videre. Ulempen da er at man med ett token kan få tilgang til veldig mange tjenester, i og med at de alle validerer på samme audience. Hvis man har andre måter å identifisere og tilgangsstyre en konsument på så er det ikke sikkert at det er så farlig (typ SPIFFE e.l.) Token exchange slik vi har implementert det løser dette ved å gi deg et nytt token med smalere audience, der hver enkelt tjeneste også kan definere hvilke konsumenter som får lov til å bytte inn tokens

Relevant links mentioned in the same context: https://docs.nais.io/auth/tokenx/index.html and https://github.com/nais/tokendings