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: Apps: Forenklet integrasjon for sluttbrukersystemer digdir/roadmap#84
  • Client systems could be "fagsystemer", "sluttbrukersystemer", "leverandører" etc
• "System users": Fremtidig løsning for sluttbrukersystemer altinn-authentication#200
• App authorization
  • Required due to various internal operations and integrations, read more at Autorisere appen (appbruker, ikke sluttbruker) altinn-decision-log#28 and App-user/token(s) for background processing, cleanup, service tasks #813
• Various upcoming features and integrations
  • User-controlled and parallel signing
  • BPMN service tasks, background work (Correspondence, Dialogporten)
• Simplify and improve current integrations
  • eFormidling, PDF
• Avoid token exchange in the future?
  • Has been discussed, will probably be handled through PEP

In scope

• Map out the inbound flow and possible contexts
• Map out the outbound flow (which tokens and mechanisms are used)
• Start a design to better abstract authenticated state and context

Analysis

Mechanisms for authorization

These methods are supported through Altinn Authentication and Authorization through PEP and PDP.

• User token (logged in through Altinn)
  • Authorized as: person
  • Access control: roles, instance delegations, dedicated XACML rules
• Org token
  • Authorized as: org
  • Access control: dedicated XACML rules in app (i.e. [ORG])
  • Always exchanged to an Altinn token, we don't support Maskinporten directly (that would be done in PEP).
  • To get the right permissions, we have to use serviceowner scopes here, as that gives us the urn:altinn:org claim in the resulting Altinn token
• Systemuser
  • Authorized as: system user
  • Access control: roles, system user delegations (what actions the system user owner approves that the system can do on behalf of the system user owner)
  • A system user is a special Maskinporten client (in principle) using Rich Authorization Request (RAR) protocol to enrich Maskinporten tokens with Altinn system user details (systemuser_id, system_id)
• App (WIP)
  • Authorized as: app within an org
  • Access control: XACML rule either manually written or injected (TBD)
  • Used by the app to perform certain actions independently of the current client/user
  • Altinn decision log item: Autorisere appen (appbruker, ikke sluttbruker) altinn-decision-log#28

User flow

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": "<string>",
  "urn:altinn:authlevel": <int>,
  "scope": "altinn:portal/enduser"
}

Q:

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

Self identified users

{
  "nameid": "<int>",
  "urn:altinn:userid": "<int>",
  "urn:altinn:username": "<string>",
  "urn:altinn:partyid": <int>,
  "urn:altinn:authenticatemethod": "SelfIdentified",
  "urn:altinn:authlevel": 0,
  "scope": "altinn:portal/enduser"
}

Org flow

• Authenticate with a Maskinporten client
• Exchange the token through Altinn authentication
• Resulting Altinn token functions as an org token (XACML must allow org actions)

JWT token claims

{
  "urn:altinn:org": "<string>",
  "urn:altinn:orgNumber": "<int>",
  "urn:altinn:authenticatemethod": "<string>",
  "urn:altinn:authlevel": <int>
}

System user flow

More details to come, but

• Make system
• Use supplier/system enrollment flow to register a system user (which includes delegations)
• Supplier authenticates with a Maskinporten client including RAR grant
• Resulting Maskinporten token can be used directly without exchange

Q:

• Does it really not need to be exchanged?

JWT token

{
  "authorization_details": [
    {
      "type": "urn:altinn:systemuser",
      "systemuser_id": ["ID of system user"],
      "systemuser_org": {
        "authority": "iso6523-actorid-upis",
        "ID": "0192:Org no of the org owning the system user"
      },
      "system_id": "ID of the system in the system register"
    }
  ]
}

More details

An Altinn system user concept consists of the following entities

• System user (systembruker)
• System (system)
• Supplier (leverandør) - the organization providing some automated Altinn-related service
• Customer (kunde) - the organization using the service provided by the supplier
• Maskinporten client - Maskinporten provides org-level identities meant for integrating across orgs

The customer owns the system user, and the permissions/delegations are owned by the system user.
The supplier owns the system, and the system owns the Maskinporten client.
The system owner concept/feature in Altinn 3 allows a system to impersonate a system user,
thereby enabling the system to perform operations in Altinn 3 as if it was the system user.
So the system "inherits" all delegations and roles assigned to the system user and can utilize these
by authenticating with Maskinporten using the system user RAR grant.
A key differentiator from the "org token" mechanism is that the system user can have roles similarly to a regular user.
A system user can be viewed as a virtual user owned by some customer/client organization.

App flow

TBD

Outbound authn/authz

• 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
  • APIM subscription key is used to disallow anything but GET depending on the subscription (to allow mutating operators only from apps running in app clusters)
  • Consists of ApplicationClient, InstanceClient, InstanceEventClient, ProcessClient, SignClient, TextClient, DataClient
• Notifications - PlatformAccessToken
• Altinn2MetadataApiClient - none
• NetsClient - API key from configuration
• Events - user token + PlatformAccessToken + APIM subscription key
  • Events subscription only uses APIM subscription key + secret code (IEventsSecretCodeProvider)
• Profile - user token + PlatformAccessToken + APIM subscription key
• Maskinporten - Maskinporten token
• Register - user token + PlatformAccessToken + APIM subscription key
• Authentication - user token + APIM subscription key (used to refresh token)
• Authorization - user token + APIM subscription key
  • Some operations use PEP and PDP directly through libraries
• Azure
• Key Vault - Entra client secret
• PDF - user token (cluster local endpoint)

Conclusion

Work that needs to be done

• Design an abstraction, something like IClientContext, that allows us to represent the authenticated state/context
  • Can represent users, orgs, systemusers and the app itself
  • How do we express outbound authn - when do we pass on the current context and when do we choose differently?
  • Formulate as ADR
  • Initial design in: Initial IAuthenticationContext abstraction #880
• Start using internal abstraction IClientContext where possible - which encapsulates the authenticated state
  • Not always possible - i.e. PEP APIs and our own public APIs
  • JwtTokenUtil
  • IUserTokenProvider
  • .User (match case, whole word)
    • Consider deprecating ClaimsPrincipalExtensions
    • Consider deprecating UserHelper
    • ClaimsPrincipal
    • Manually iterating claims, such as TelemetryEnrichingMiddleware
  • Consider creating shim/abstraction between us and public PEP APIs such as DecisionHelper
• Review all usage of profile client, as system users don't have profiles
• Get updated PlatformUser (part of InstanceEvent) that considers system users
  • Update GenerateProcessChangeEvent, InstanceEventExtensions
• Frontend updates
  • Confirmation page
  • Receipt page
  • PDF
  • Authorization/user/profile/party related requests
• Figure out if there is a migration path to use Maskinporten tokens directly (no exchange)

[martinothamar]

Closing as the main work is done, but will probably be extended and/or moved into docs somewhere