System architecture
System context, responsibilities and overall construction of Altinn Authorization.
Altinn Authorization is not a single application. It is a set of services that establish identity and representation, describe protected resources, administer rights, evaluate policy and record security-relevant events.
The trust chain
- Identity: Who, or which system, is acting?
- Party and representation: On behalf of which person or organisation?
- Resource: What is the actor trying to use?
- Right: Which rules, roles, delegations or consents apply?
- Decision: Is this action permitted in the current context?
- Traceability: Can the event and decision basis be examined later?
System context
| Area | Main responsibility | Core components |
|---|---|---|
| Identity | Establish authenticated identity context | Authentication |
| Party and representation | Describe persons, organisations, roles and representation | Register |
| Resource | Identify and describe services and protected objects | Resource Registry |
| Rights administration | Create, read and change delegations and access relationships | Access Management |
| Machine representation | Allow a system to act on behalf of an organisation | System User |
| Purpose-specific authority | Create and validate consents | Consent |
| Access control | Evaluate policy, rights and context | Authorization/PDP |
| Traceability | Process and store authentication and authorization events | Audit Log |
Important system boundaries
The team owns the authentication service and the authorization components described here. It does not own ID-porten or Maskinporten. Altinn Access Token is owned by Team Platform and is a dependency. Maskinporten client administration is an integration, not part of the team’s system responsibility.
A PEP enforces a decision close to the protected service and may therefore be outside the team’s components. The decision basis and PDP capability belong to the authorization system.
Architecture principles
- Resources are explicitly identified; rights are not granted to undefined objects.
- Identity and representation are separate concepts.
- Administration of rights is separated from evaluation of rights.
- PDP returns a decision; the calling PEP enforces it.
- External tokens are evidence that is validated and translated into internal identity context.
- Events should be correlatable across component boundaries.
The existing architecture reference remains for now. It focuses on the XACML roles PDP, PAP, PRP, PIP, Context Handler and PEP. This page is the new system-oriented entry point.