feat(api): Support self registered users/Feide users

[elsand]

Description

This introduces support for SI-users as well as other IDP authenticated persons (such as Feide) relying on userId/partyId only.

Note! Feide / ID-porten SRE users are currently disallowed in the validator (and relevant integration tests), pending resolution of identifier names. The rest of the implementation is included in this PR.

This includes:

• Authenticating users from new endpoint having userid/partyid claims
• Support list authorizations for these users
• Support detail authorizations for these users
• Support partylist authorizations for these users
• Support dialogs having a username/feide orgsub/idporten email as dialog.party
• Support these types as actors

Other

• Use new endpoint in Register for name resolutions (same as adapter)
• Refactor DialogDetailsAuthorizationRequest to contain reference to ClaimsPrincipal instead of a List copy, reducing allocations and required extension methods.

Limitations: there is no support in accessmanagement or PDP to perform authorizations on the new external identifiers, so we are only able to support authorization scenarios where we have a authenticated enduser context. In practice, this means we cannot support ?EndUserId= on SO-API for anything other than ID-porten authenticated persons and system users.

Related Issue(s)

• Support self-identified/Feide users #2698

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)

Documentation

• Documentation is updated (either in docs-directory, Altinnpedia or a separate linked PR in altinn-studio-docs., if applicable)

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/Digdir.Domain.Dialogporten.Infrastructure/Altinn/Authorization/AltinnAuthorizationClient.cs (1)

95-130: Self‑identified/Feide early‑return is sound but make assumptions explicit

The emulation path for IdportenSelfIdentifiedUserIdentifier / AltinnSelfIdentifiedUserIdentifier / FeideUserIdentifier looks correct and matches the documented limitation (no access‑management support; only end‑user contexts). Two minor points to consider:

• You rely on _user.GetPrincipal() for PartyUuid/PartyId while also accepting an authenticatedParty parameter; if GetAuthorizedParties is ever called with an authenticatedParty that does not come from the current principal, this branch will silently mix identities. Either document this invariant on the interface or add a guard/assertion to fail fast if they diverge.
• You call _user.GetPrincipal() twice; capturing it once (e.g. var principal = _user.GetPrincipal();) would slightly improve clarity and avoid duplication.

Functionally this looks fine and matches AuthorizedPartiesHelper’s SelfIdentified handling.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a218a22 and 1084437.

📒 Files selected for processing (2)

• src/Digdir.Domain.Dialogporten.Application/Externals/AltinnAuthorization/AuthorizedPartiesResult.cs (1 hunks)
• src/Digdir.Domain.Dialogporten.Infrastructure/Altinn/Authorization/AltinnAuthorizationClient.cs (4 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

src/Digdir.Domain.Dialogporten.Infrastructure/Altinn/Authorization/AltinnAuthorizationClient.cs (6)

tests/Digdir.Domain.Dialogporten.Application.Integration.Tests/Common/IntegrationTestUser.cs (1)

• ClaimsPrincipal (29-29)

src/Digdir.Domain.Dialogporten.GraphQL/Common/Authentication/LocalDevelopmentUser.cs (1)

• ClaimsPrincipal (26-26)

src/Digdir.Domain.Dialogporten.WebApi/Common/LocalDevelopmentUser.cs (1)

• ClaimsPrincipal (26-26)

src/Digdir.Domain.Dialogporten.Infrastructure/Altinn/Authorization/AuthorizedPartiesResultDto.cs (1)

• AuthorizedPartiesResultDto (3-19)

src/Digdir.Domain.Dialogporten.Application/Common/Extensions/ClaimsPrincipalExtensions.cs (2)

• TryGetPartyUuid (156-166)
• TryGetPartyId (168-178)

src/Digdir.Domain.Dialogporten.Infrastructure/Altinn/Authorization/AuthorizedPartiesHelper.cs (1)

• AuthorizedPartiesHelper (6-87)

🔇 Additional comments (4)

src/Digdir.Domain.Dialogporten.Application/Externals/AltinnAuthorization/AuthorizedPartiesResult.cs (1)

42-43: Verification confirms enum change is correctly implemented.

All usages of AuthorizedPartyType properly handle the new SelfIdentified member:

• Both switch expressions in AuthorizedPartiesHelper.cs (lines 37–45 and 53–59) explicitly map the new member with default exception handling
• AutoMapper automatically handles enum mapping in MappingProfile.cs files without requiring special configuration
• Business logic properly integrates the new member (line 62: IsCurrentEndUser check)
• No serialization or database migration issues identified

src/Digdir.Domain.Dialogporten.Infrastructure/Altinn/Authorization/AltinnAuthorizationClient.cs (3)

64-71: Switch to ClaimsPrincipal is consistent with the new API surface

Using _user.GetPrincipal() directly for DialogDetailsAuthorizationRequest.ClaimsPrincipal aligns with the new DecisionRequestHelper.CreateDialogDetailsRequest contract and avoids duplicating claim extraction here. No issues from a correctness or maintainability perspective.

---

239-246: Comment clarifies expected behavior for empty authorized parties

The new comment around system users vs. other user types clearly documents why an empty list is treated as an error except for SystemUserIdentifier. This matches the subsequent guard and improves readability.

---

290-298: xacmlJsonResponse renaming and flow are correct

Renaming to xacmlJsonResponse and passing it consistently to LogIfIndeterminate and CreateDialogDetailsResponse preserves behavior and clarifies the variable’s purpose. No functional concerns here.