The applications has a web native architecture and is deployed to Kubernetes Clusters as docker containers. The Kubernetes clusters are isolated between the different applications owners and hosted in a public cloud solution making it highly scalable. »
Integrations Kafka The Notifications email microservice has an integration towards a Kafka broker, and this integration is used both to publish and consume messages from topics relevant to the microservice. Consumers: The following Kafka consumers are defined: SendEmailQueueConsumer: Consumes email objects with recipient data that are ready to be sent EmailSendingAcceptedConsumer: Consumes pairs of notification and communications services operation ids Producers: A single producer KafkaProducer is implemented and used by all services that publish to Kafka. »
API Public API DeliveryReportController Endpoint receiving delivery reports in XML-format from SMS provider. The controller is protected with basic authentication. Integrations Kafka The Notifications sms microservice has an integration towards a Kafka broker, and this integration is used both to publish and consume messages from topics relevant to the microservice. Consumers: The following Kafka consumers are defined: SendSmsQueueConsumer: Consumes sms objects with recipient data that are ready to be sent Producers: A single producer KafkaProducer is implemented and used by all services that publish to Kafka. »
In 2022-2026, Altinn will modernize its authorization architecture and components. Therefore, the below description is a mix of as-is and to-be. Altinn uses attribute-based access control (ABAC). In short, Altinn authorization control access through rules defined in XACML Policies. Each rule defines which resource the rule describes, what operation, and who can perform it. Altinn Authorization - Components The diagram below shows the future components of a new Altinn Architecture. »
System architecture illustration When a publish request is posted to the /app endpoint, the event will first be saved in the events-registration queue for operational resilience and flexibility. When an event retrieval request is received, it will respond with results from the internal relational database used for events persistence. Altinn Event Architecture Flow for processing a single incoming event Sequence diagram - POST event System and service dependencies Internal Altinn Authorization: used to authorize access to endpoints Altinn Register: used to support lookup on alternative subject External Azure Kubernetes Services: hosts the docker containers for microservices and cron jobs in a fully managed Kubernetes cluster PostgreSQL: used for storage Azure Functions: used internally to process and forward incoming cloud events to subscriber webhooks. »
System architecture illustration The solution is supported by multiple cron jobs running in the same Kubernetes cluster, a Kafka server and an instance of Azure Communication services. The following diagram illustrates the overall data flow. Solution diagram Altinn Notifications Process flow between microservices and Kafka topics Vis/skjul innhold Flow chart for order processing Flow chart including Kafka topics for order processing Vis/skjul innhold Flow chart for email notification processing Flow chart including Kafka topics for email notification processing Vis/skjul innhold Flow chart for sms notification processing Flow chart including Kafka topics for sms notification processing System and service dependencies Internal Altinn Authorization: used to authorize access to endpoints Altinn Profile: used to retrieve recipient information Altinn Register: used to retrieve recipient information The number of internal dependencies for Notifications is currently quite limited, but during 2024 we expect the services below to be utilized by Notifications. »
Kafka topic overview Below is an overview of the Kafka topics used in our system, along with information about the producers and the content of each topic Health Vis/skjul innhold altinn.notifications.health.check Description: A topic dedicated to verifying the connectivity between microservices and the Kafka cluster. Event trigger: External party has requested that the health of the microservice is checked. Producer: Altinn Notifications, KafkaHealthCheck Content: Format: string Description: A string not intended to carry any significant data. »
Development ApplicationsDevelopment Applications are used by the devops team to support the different development capabilities required. Operations ApplicationOperations Applications are used by the devops team for supporting the different operation and management capabilities required »
When defining the authorization components, we used the XACML reference architecture. Conceptual components We have defined the following conceptual components/functional areas from the reference architecture. PDP - Policy Decision Point The policy decision point is responsible for deciding if an authorization request is authorized or not. It bases its decision on rules and information it has of the resource and the user/system trying to access and perform an operation on a resource. »
See solutions for details about the functionality provided by this component. Construction Components Altinn Access Control The diagram below shows where the different solution components are located The Authorization component is constructed as a asp.net MVC application exposing API. The API communicates with the different solution components The below diagram shows the data flow including PEP. Data flow authorization Decision API The decision API is the API that orchestrates the decision process. »
