Authorization scenarios and mechanisms analysis

[martinothamar]

Description

We need to get an overview of common authorization scenarios and mechanisms that exist today and will be implemented into the platform. Here are some movements happening where there are questions related to authorization

• Simplified integration for system owners: https://github.com/digdir/roadmap/issues/84
  • Client systems could be "fagsystemer", "sluttbrukersystemer", "leverandører" etc
• "System users": https://github.com/Altinn/altinn-authentication/issues/200
• Background processing/user independent actions in the process engine in Altinn.App
  • IServiceTask implementations (may run in background, may retry operations on failure)
  • Different kinds of payment processing
  • Invoke other product/platform APIs such as
  • PDF generator
  • Authorization Delegation/AccessControl
  • eFormidling
  • Correspondence
  • Storage
  • Notifications
  • Events
• Maskinporten, PlatformAccessToken are scoped to organization, not app, though some apps want further isolation
• Maskinporten -> Altinn token exchange is cumbersome
  • Options
  • Not have token exchange
  • Do token exchange internally in the platform

In scope

No response

Out of scope

No response

Additional Information

No response

Analysis

User flow 1

Log into tt02 manually, then navigate to an app

• Log into tt02.altinn.no - altinnContext cookie is set (this is still A2 I think)
  • Some base64 stuff?
• Choose party/reportee - altinnContext and altinnReportee cookies are set (this is still A2 I think)
• Go to Altinn 3 app URL directly - 302 redirect to platform.tt02.altinn.no/authentication/api/v1/authentication then back again
  • AltinnStudioRuntime is set by Authn API, it is a JWT, see below
• Frontend renders party selection
  • Queries user, parties and current party (/profile/user, /parties, /authorization/parties/current)
• Party selection invokes PUT /parties/{partyId}, AltinnPartyId cookie is set
• App is rendered

JWT token claims:

{
  "nameid": "<int>",
  "urn:altinn:userid": "<int>",
  "urn:altinn:partyid": <int>,
  "urn:altinn:authenticatemethod": "IdportenTestId",
  "urn:altinn:authlevel": 3
}

Q:

• The partyid claim in the auth cookie can differ from altinnReportee and AltinnPartyId, how does this stay consistent?

Mechanisms for authorization accepted by apps APIs

• User token (logged in through Altinn)
  • Context: person, and party through party selection
• Maskinporten token
  • Context: org

Platform and Core APIs

• Storage - user token + APIM subscription key
  • User token comes from IUserTokenProvider which in reality is either the AltinnStudioRuntime cookie or the auth header, so it needs the HTTP Context directly
• Notifications - PlatformnAccessToken
• Events - user token + PlatformAccessToken + APIM subscription key
• Profile - user token + PlatformAccessToken + APIM subscription key

Conclusion

No response