Solution Architecture
Altinn 3 Broker solution architecture for basic use cases of Managed File Transfers.
The solution architecture described here is the foundation architecture for Altinn Broker, as relevant for the basic use cases of managed file transfers. Further descriptions of the solution architecture related to advanced use cases and possible future extensions will build on this foundation architecture.
Guiding Architecture Principles
Overarching architectural principles for digitization of the public sector
The overarching architectural principles for digitization of the public sector in Norway are a support for work with enterprise architecture and are intended to contribute to increased interoperability across enterprises and sectors.
These high level principals apply.
General Altinn 3 Architecture Principles
The Altinn 3 Architecture Principles apply.
Further considerations
Altinn 3 Broker is one of several Digdir products within the product groups for Messaging and Data Sharing. Architecture principles for these product groups are under construction.
Pending architecture principles for the relevant procuct areas, here are some important considerations for the Altinn 3 Broker solution architeture:
Support for on-premise hosting and data storage. Due to information security concerns, some customers will not tolerate cloud hosting and storage on the cloud platform chosen by Altinn. The solution architecture should therefore allow for on premise hosting and storage on a per customer basis.
Future readiness in general. The international landscape of regulations, standards, technologies and solutions is evolving. The solution architecture should take this into account, and prepare for compliance, interoperability and reuse. Examples: Semantic Web and Linked Data, Self Souvereign Identity and Verifiable Credentials.
Compliance with EU regulations and standards. European regulations and standards for data sharing will apply for Norway in the coming years. Compliance will be mandated, and interoperability will be essential for cross border value chains. See e.g. Digdir’s overview of EU legislation for data sharing and Data Spaces Support Center om “Regulatory Compliance”
High Level Solution Overview – main building blocks
The following figure gives a high level solution overview.
This diagram expands on the basic context overview by indicating the involved building blocks.
The Altinn application components (right side) realize the functionality as indicated by the high level application services (bottom). The exact mapping between services and conponents is not shown in this, high level diagram.
In addition to general descriptions of each of the application components given elsewhere, here’s a summary of how these components relates to and serves Altinn 3 Broker:
- ID-porten: Auhentication of human end users.
- Maskinporten: Authentication and authorization of machines (End User Systems). Authorization features are realized in cooperation with the Altinn Authorization component.
- Altinn Authorization. Register services resources and authorize access.
- Altinn Notifications. Notifications to human end users via e-mail and sms.
- Altinn Events. Notifications to webhooks in End User Systems.
- Altinn Studio. Applications and user interface for self service configuration of the solutions.
- Altinn Billing. Invoicing of customers.
Related solutions
An overview of related solutions is provided in the following diagram. This serves as a starting point for assessing interaction with, as well as the use and reuse of, other solutions in the detailed solution architecture for Altinn Broker. The most relevant solutions are highlighted in bold.
Transition Architecture - Altinn 2 to Altinn 3
General
Two migration options are supported for migration of Altinn Broker services - hard shift and soft switch.
Hard shift from Altinn 2 to Altinn 3 for all users of a service
With the Hard shift option, all users and End User Systems make a coordinated shift to Altinn 3.
This option is recommended in cases where such a coordinated shift is feasible. No transition solution is needed and all features of Altinn 3 may be used as soon as the shift has been made.
Uploaded files are stored om Altinn 2 Broker File Storage up until the shift.
Note: In this case, it is assumed that Altinn 2 Broker files have been purged and are not needed in Altinn 3 Broker. However, if required, it will be possible to move files from Altinn 2 to Altinn 3 Broker File Storage after the transition.
Soft shift from Altinn 2 to Altinn 3
With the Soft shift option, users and End User Systems shift to Altinn 3 on an individual basis, when ready. The transition solution bridges between Altinn 2 and Altinn 3.
During the transition period, uploaded files will always be stored on Altinn 3 Broker Storage.
File storage
Broker File Storage is based MS Azure Blob Storage, and isolated to a storage account per Service Owner.
Stored Files are always encrypted; ref. Azure Storage encryption for data at rest | Microsoft Learn.
Metadata storage
The following information model details the conceptual information model under basic concepts.
Addressing and Routing
The basic Altinn 3 Broker adressing and routing mechanisms are:
- Specific adressing of recipients
- Addressing via subscription
Note: Further adressing capabilities are considered, including criteria based om role, service and context.
Specific adressing of recipients
TBD.
Addressing via subscription
TBD.
Notifications
Notifications to human end users
For notifications to human recipients via e-mail and sms, Altinn Broker uses the Altinn Notifications component.
Notifications to End User Systems
End User Systems may register custom webhooks for receiving events; see Altinn Events.
See the Altinn 3 Broker OpenAPI specification for specification of the supported events.
API Management
Azure API Management (APIM) is used for scaling, operational insights, and securing Altinn Broker APIs.
Altinn Broker runs on an APIM instance that is shared with other platform services in Altinn.
Logging and Monitoring
TBD
Clearing and Billing
TBD
Security Controls
The documentation of security controls is work in progress, first in Norwegian, then to be translated to English.