Security Checklist

Design General # Title Description 1 Do the design use the security architecture correct? Are the mechanismen like authentication and authorization used correctly?. 2 Sikrer designet 3 Vil designet gi økt fare for DOS angrep? Eksponerer funksjonalitet tunge operasjoner som kan gjentas mange ganger 4 Is it performed a treath assessment for the change? Hvilke nye risikoer introdusereres ved hjelp av endringen Muligheter for tilgang til data? »

Access Token

Altinn Studio The designer application creates a JWT based Access Token based on a certificate that designer has available when running in the Altinn Studio Kubernetes Cluster. The different Altinn Studio environments have their own certificate. This makes it possible for each Altinn Platform environment to configure which Altinn Studio environment that is allowed to deploy and modify applications in that specific environment. The token is generated with help of the Access Token generator and this is generated for each call designer are doing aginst the platform solution for Storage and Authorization. »

Authentication Capabilities

Altinn Studio Developer authentication The App Developer using Altinn Studio will authenticate with help of the build in account in Gitea. The designer part of Altinn Studio integrates with Gitea so it identifies the user logged in in Gitea. Git repo authentication When users tries to update the Git-repo where source files for the app is stored it needs to authenticate against the Git-repo. This can be done through using a App Key generated in Gitea or using the username/password for the Gitea account. »

Authentication APIs

As part of the authentication component, there is some APIs that support authentication of different types of users and systems. API for SBL Authentication cookie This API creates a JWT Cookie (A cookie with a JWT Token) based on the SBL Cookie created during login in the Legacy SBL solution. This API uses API in the SBL Bridge to verify the cookie and get information about the logged-in user. Based on this information this API creates a JWT token with claims about the user (userid, authentication level ++) and sign the JWT token with the private key of Altinn Platform. »


The authorization capabilities are based around ABAC (Attribute-Based Access Controls) and the XACML standard. This gives very flexible authorization capabilities. Support authorization of app and platform access Rights can be given to subjects with a given role, or direct to a person/organization or another type of attribute Support unlimited levels of resource levels Resources can have different access requirements based on resource state Rules can contain obligations like security level required Roles can be retrieved from different sources Access rights are verified at a central solution Authorize based on API parameters The following concepts are important »

Context Handler

As an example, a decision request could contain only userId and instanceId together with the action requested. <?xml version="1.0" encoding="utf-8"?> <Request xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" ReturnPolicyIdList="false" CombinedDecision="false" xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:xsi=""> <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"> <Attribute IncludeInResult="false" AttributeId="urn:altinn:user-id"> <AttributeValue DataType="">15468</AttributeValue> </Attribute> </Attributes> <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"> <Attribute IncludeInResult="false" AttributeId="urn:altinn:instance-id"> <AttributeValue DataType="">cbdc7b44-9442-4fe0-854b-da278bf0b0e</AttributeValue> </Attribute> </Attributes> <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"> <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"> <AttributeValue DataType="">Read</AttributeValue> </Attribute> </Attributes> <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" /> </Request> The enriched decision request contains all the needed attributes so PDP can identify the correct policy and evauluate the request based on it. »


NOTE: Work in progress. See Github Issue. Apps hosted in Altinn Apps could cover lots of functional scenario. For statefull apps where the App store data in Altinn Platform in the Storage component, the type of data could be data that is 100% public to highly sensitive data. The Org that creates the App, would based on the type of data have spceial requirements for encryption to support their Confidentiality requirement for the data. »


JWTCookieAuthentication is a ASP.NET Core authentication service created for supporting Json Web Tokens (JWT) as bearer tokens and JWT in Cookies. It is based on JWTBearer This is created for scenarios where you have need for APIs that will be accessed from system using bearer tokens and from Single Page Applications (SPA) where you want to protect the JWT from this SPA. (XSS attacks). When JWT is put in a http only cookie it is not accessible from the SPA and can’t be stolen by malicous javascript running in the browser. »

JWT Format

JSON Web Token are an open, industry standard RFC 7519 method for representing claims securely between two parties and are choosen as the bearer of information about users and systems. The format that is choosen for JWT tokens is RSA256. This is a asymetric algorithm where the Authentication component in Altinn Platform generates tokens based on a private key in a certificate, and everyone can validate the token with the public key. »

Policy Administration Point

The rules for apps is defined in Altinn Studio when developing the app. The rules for this is defined by XACML. See XACML for details. Delegation of rights is performed in Altinn II platform. When delegation is done through creation of new rules that gives user or organisation new rights. »