Description

This task is created to make manual test plan for end to end testing of Audit log component.

Test cases to be covered

Test cases to be tested should be listed here. Test cases should cover component level testing and full flow testing. Both positive and negative tests should be listed.

**Instantiation of different apps by different users to verify logs in authentication **

• Login with TestID login method for SSN user who is Instantiating app and verify events are logged in Audit log
• Login with BankID login method for SSN user who is Instantiating app and verify events are logged in Audit log
• Login with Altinnpin login method for SSN user who is Instantiating app and verify events are logged in Audit log
• Verify events are logged when EC_user tries to login and instantiate app
• Verify events are logged when user logged in via API using maskinporten token and instantiates an app

**With feature toggle on and off **

• Verify events are logged when Audit log feature toggle is on.
• Events should not be logged in database when feature toggle is off.

**Verify logs for org and Changes made by different users on app after instantiation **

• SSN user who has rights on another SSN make changes after Instantiating app
• Verify event logs are logged when org user instantiate app and all operations which are performed should also be logged
• Verify Org A who has delegated Altinn 3 App to user A and user A instantiate app on behalf of Org A. events should be logged in.
• User logged in with maskinporten token after got logged out saves refresh event in event log.

**Verify logs when Org is delegating MaskinPortenScheme and resources **

• Event logs should be logged when Org A has delegated MaskinPorten scehme and resources to Org B

When verifying audit log it shows wrong ID for user who is logged in with TestID login method @acn-dgopa

Description

Now the auditlog is ready to be deployed in production. Release notes draft will be created at 00:00 20.march. Publish the release notes and that will trigger the deployment to tt02 and production

Tasks

• Publish release notes
• Update the deploy template for the weekly deployment to include auditlog

Acceptance Criteria

• Release notes is published
• Deployed auditlog successfully to yt01, tt02, prod
• Feature toggle for auditlog is turned on in all AT environments
• Feature toggle for auditlog is turned on in TT02
• Feature toggle for auditlog is turned on in Prod

Description

The security log component will be the component responsible for adding logs to database for authorization and authentication. Setup a database for audit log with table AuthenticationEvent

Tasks

• Setup Yuniql for automated database scripts
• Add database script to create table AuthenticationEvent
• Add script to create function to write to authenticationevent table
• Create Core project that will establish services to integrate with repository project
• Create Repository project that will establish services to read/write to the table
• Update AuthenticationEventcontroller post method to call core service
• Update AuthenticationEventController get method to call core service
• Add unit tests

Acceptance Criteria

• A database with 2 tables are created
• Core project is created
• Repository project is created
• It is possible to create an authentication event via api endpoint

Description

As part of transistion to the new cloud platform we need to create a new Authentication log.

• Logtype. (login, failedlogin, logout)
• UserId/systemid/
• Timestamp
• Method
• Ip-address
• Sessionid
• Supplier/System id
• AdditionalInfo (possible needed in some fail scenarios?)

Additional Information

• It should be possible to search logs and join them with other metadata like instance history

Do we need to log additional info like scope?

Docs
https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/informasjonssikkerhet-internkontroll/etablere-internkontroll/iverksette-styringssystem-for-informasjonssikkerhet/

https://www.digdir.no/digital-samhandling/veileder-identifikasjon-og-sporbarhet-i-elektronisk-kommunikasjon-med-og-i-offentlig-sektor/2992

Log requirements

As part of the requirements, we need to define

• How long can we store these logs
• Is there a difference in storage time for the different data
• Is there need for additional integrity on logs(hash++)

@benedicteos

Log architecture

• What kind of log database should we use
• Should we use queue technology to improve speed and

Suggestion

1. New TTPLog schema/db
2. Table for AuthenticationEvent
3. New TTPLog component
4. Queue Storage for high-performance logging. (no need for waiting for db write
5. Azure Function for looking at log model and calling correct endppoo
6. Write only for application user

Tasks

• Define Log architecture

Acceptance Criteria

• Logs every request where user logs direct in to Altinn 3 with OIDC
• Logs when Altinn 3 logins based on Altinn 2 session
• Logs when maskinporten token is exchanged
• Logs when id-porten token is exchanged
• Logs when logging out
• The logs should support at least 500.000.000 log inserts
• The log storage should not allow

Description

Hashing of a selected set of properties together with signing the hash reduces the chance that logs have been tampered with.
https://learn.microsoft.com/en-us/dotnet/standard/security/cryptographic-signatures

Use SHA384 to Hash values.

Use RSA to sign HASH.

Do we need to support rotation of certificates. How should we know which certificates to

###Analysis

• Analyze and find out what are the list of values that need to be included in Hash.

Tasks

• Implement Hashing service
• Add hash, signature and reference to certificate/key fields in database
• Update function to store the new fields in database

Acceptance Criteria

• Hashing is implemented

Description

Add a readme file to the auditlog component that describes about the project and the practical guidelines.

Tasks

• Update the readme with the project architecture and description
• Update the readme with getting started section

Acceptance Criteria

• Readme is updated
• Development setup is available in the gettting started section

Description

Setup actions to build, run unit tests and analyze audit log component

Tasks

• Setup build and run unit test action
• Setup sonar cloud analysis

Acceptance Criteria

• Build and run unit test is triggered on every new PR
• Sonar cloud analysis is run on every PR

Description

Infrastructure to host the audit-log component, storage queue for the log events, function to process the queue must be tested in a development/testing environment to ensure the log workflow/dataflow from authentication/authorization components. The infrastructure can be set up in test subscription with own resource group for audit-log component.

Tasks

• Setup container app for audit-log component
• Setup storage queue to receive log events
• Setup function app to process the events
• Setup network access such that the access is granted to queue log request for calls from authentication/authorization component in platform cluster
• Grant function app access to the queue (service principal?)
• Grant function app access to the audit-log api (internal access?)

Acceptance Criteria

• A test environment is established for the audit-log component
• A test queue is provisioned
• A function app for testing is provisioned
• Authentication/Authorization component in one of the test environment is able to queue event for logging
• The function app is able to process the event queue and send log request to audit log component
• The audit-log component is able tor receive log requests and event is logged to database

Description

When issue Altinn/altinn-authentication#372 is resolved, the eventlog implementation in authentication/authoriztion must be updated to map the ipadress from the request to the ipaddress in event model

Tasks

• Update mapping to get the ipaddress from the request

Acceptance Criteria

• ipaddress is mapped to the event model

Description

The security log component will be the component responsible for adding logs to database for authorization events. Add an endpoint to enable this logging.

Tasks

• Add authorizationevent controller for logging authorization events
• Add function in postgres sql
• Add service class
• Add repository class
• Add unit tests

Acceptance Criteria

• Endpoint for authorizationevent log is created

Description

Components that send log requests must be authenticated.

Tasks

• Implement authentication event log for login event
• Implement authentication event log for logout
• Implement authentication event log for refresh
• Implement authentication event log for failed authentication
• Implement authentication event log for token exchange
• Add unit tests
• Refactor the helper/service class
• Add additional fields ipadress, timetodelete
• Remove sessionid field
• Update unit tests

Acceptance Criteria

• Authentication is implemented
• An event is logged for login
• An event is logged for logout
• An event is logged for refresh event
• An event is logged for failed authentication
• An event is logged for token exchange

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update npm non-major dependencies (@babel/core, @babel/eslint-parser, yarn)
• chore(deps): update nuget non-major dependencies (Microsoft.AspNetCore.Mvc.Testing, Microsoft.AspNetCore.OpenApi, Microsoft.IdentityModel.Logging, Microsoft.IdentityModel.Tokens, coverlet.collector)
• chore(deps): update dependency microsoft.aspnetcore.openapi to v8
• chore(deps): update dependency npgsql.dependencyinjection to v8
• chore(deps): update yarn to v4
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Description

A release routine must be setup to deploy updates to TT02/Prod environment. As of now, the release routine for Team Authorisasjon is TT02 on tuesdays and prod on wednesdays.

Container Application
A github release will be created every wednesday at 00:00. The release will have a naming format [year].[month].[day]. A github package registry will be tagged on every wednesday for container app. The package will have a release version in the format [year].[month].[day] f.ex 2024.3.18. The package will be deployed to TT02 on wednesday and production deploy will wait until next tuesday.
The code will be tested for stability in TT02 for a week. The same package is then deployed to production.

Function application
A github release will be created every tuesday at 00:00. The release will have a naming format [year].[month].[day]. f.ex 2024.3.18. The function app will be deployed to TT02 on wednesday and production deploy will wait until next tuesday.

Tasks

• Setup action to schedule a release, tag image and release notes draft with version format as [year].[month].[day]
• Setup action to deploy to tt02 after a release
• Update action to deploy to prod after tt02 deploy

Acceptance Criteria

• Release is created on every wednesday
• Deploy fails when the container app is unhealthy after deploy
• Deploy fails when the function app is unhealthy after deploy
• Deploy awaits approval on TT02 and prod

Description of the bug

When app sends authorization request, it is actually sent by the PEP package to the platform authorization api. The PEP package does not include the x-forwarded-for header in the api request sent to the platform authorization api. Therefore the iaddress received in the authorization component is the ipaddress of the app cluster. But we need the ipaddress of the app client.
To acheive this,

• we need to make sure app component, receives the client ipaddress
• add x-forwarded-for header with the client ip in the api request sent to the authorization component.

Steps To Reproduce

1. Instantiate/open an existing instance
2. edit a field
3. Go to the auditlog database and query authz.eventlog
4. Ipaddress of the app cluster is logged in the ipaddress column

Expected : Ipaddress of the app client is logged in the ipaddress column

Additional Information

No response

Description

We need queue to receive all event log requests and function to process the requests in the queue. When authentication/authorization sends log request, it will be sent to the log queue. Azure function will then process each item in the queue and send log request to the authentication/authorization end point

Tasks

• Setup storage queue for event logging
• Setup function project to process events
• Test the logging queue workflow from authentication component

Acceptance Criteria

• Queue is setup
• Queue accepts log requests
• Functions is set up
• Function is able to process the log requests

I see time which comes in event logs is different than the actual time

Feedback after reviweing eventlog in tt02

@lovoll used some time to go over the logs and give some valuable feedback on eventlog. the following feedback is received

1. På Autentisering er det noen innslag som ikke sier så mye bare tidspunkt ikke noen bruker og trolig heller ikke noen Autentiseringsmetode regner med at 0 er deafault for TokenExchange og AltinnPin henger ikke sammen.
2. Ser ut som SubjectPartyId ikke alltid får verdi selv om SubjectOrgnumber og SubjectOrgCode men det er kanskje ikke tilgjengelig uten ekstra oppslag.
3. Burde Resource vært mer entydig slik den er nå så ser det ut som den bare inneholder appid og ikke org og den sier vel heller ikke hvilken type resurs det er. App/ResourceRegister
4. Tenker vi må lage noen spørringer som kan trekke ut svar på standard spørsmål.
5. Tenker det blir bedre når sessionid for verdi i Autorisasjonsloggen.
6. Kunne vært lurt om Authentication Method og AuthenticationLevel hadde null når verdien manglet nå mistenker jeg at den blir 0 som sammenfaller med en autentisk verdi.
7. Mye bra her vi kan vel pusse litt på denne etter hvert som vi ser mangler.

Description

We should test partitioning on the table so we do not need to do what we do in Altinn 2, where we rename the table every year.

https://severalnines.com/blog/guide-partitioning-data-postgresql/#:~:text=The%20maximum%20table%20size%20allowed,a%20hundredth%20of%20that%20space.

Need for Partitioning

Event log data can increase over period and therefore partitioning can offer the following benefits

• Improved performance
• Efficient Data Management
• Faster data loading and unloading
• Easy to archive and delete a range of data which helps with managing data retention policies
• Query optimization, improve parallel query performance

Dimensioning

Data Ingestion Rate

We expect the following numbers for the data

• 50.000.000 instances
• 50 authorizations per instance

Projected Increase

Altinn 3 applications will increase over time and the number of authentication/authorization requests will definitely increase over time which will produce enormous events. We expect the following
--TODO

Data Retention

As of now, we plan to save the data for a period of 2 years

Data Access Pattern

The data is only made available internally. We will be frequently querying the event log data for a period of time in connection to requests from service owners.
The date time range can vary from

• a day
• couple of days
• a week
• a month
• specific months
• a year
• more than a year, upto 3 years back in time (But not sure if that will be offered with new data retention policy)

Examples of data retreival are

• List out all the activities of a specfic user
• List out all the activities of a specific organisation
• List out activities of a specific user over a period of time
• List out activities from a specific ipaddress
• List out activities for a specific service for a specific user/org

Lessons from Altinn2

TODO

Partitioning

Method

Event log data is usually accessed with the interest over a period. Range partitioning can help us partition the event log table based on datetime range

Key

Keys that will be used mainly for query retreivals are

• Date range
• SSN/Organisation number
• Service Owner

Datetime can be the right partitionkey in case of eventlog. Don't see a need for composite partition keys at this point of time.

Sub-Partitioning

Partitions are partitioned tables themselves. Since our data is expected to grow over time, It can be a good idea to sub partition the tables. F.ex, The main partition can be based on event year and the sub partitions can be based on event months of event year.

Automation

Postgres does not offer automatic creation of partitions. However it offers extension like TimeScaleDB for time-series data.

TimeScaleDB Extension

With the TimescaleDB extension, we can continue to use PostgreSQL while using TimescaleDB to scale for time-series workloads. Enabling the TimescaleDB extension on new or existing Azure Database for PostgreSQL server will eliminate the need to run two databases to collect their relational and time-series data.

Why

• Simple
• Removes the need for us to create complex cron jobs or triggers to save data into the right partition
• open source
• Microsoft has partnership with timescale and therefore the extension is readily available
• We continue to use the postgressql server as before with the advantage of timescale

Partitioning Cost

TODO

References

• https://azure.microsoft.com/en-us/updates/timescaledb-for-azure-database-for-postgresql-to-power-iot-and-time-series-workloads/
• https://docs.timescale.com/getting-started/latest/

Sharding

Both Sharding and partitioning are techniques used to manage and distribute large datasets but they serve different purposes. While partitioning helps to organize data with a single database instance, Sharding involves distributing data across multiple database instances or servers.
Sharding is also known as horizontal partitioning. Each shard operates a separate db instance.
According to our data retrieval behavior for event log,

• it is not exposed for the end users,
• no update on the data will be done.
  Therefore the question arises about the cost and the need for sharding for this access pattern.

Sharding Cost

TODO

Decision

We will start with partitioning using timescaledb extension in azure postgres. Azure postgres sql supports apache license and automatic data retention is not supported in apache license. we must use "timescale" license for automatic data retention. However it is possible to manually delete the chunk based on a time, f.eks every 2nd year.

Acceptance Criteria

• A partition method is selected
• A partition key is selected
• Necessary tasks for partitioning is created

Description

See tasks

Additional Information

No response

Tasks

Acceptance Criterias

No response

Description

The auditlog component will be deployed as container app in azure. The code will be packaged as a package in github container registry.

Tasks

• Setup workflow to build and package the auditlog component

Acceptance Criteria

• Github package registry is setup for auditlog component
• Auditlog component is packaged as github package
• The package is tagged with github commit sha as the tag identificator

Description

Currently we have some K6 tests in auditlog api app that can be run after deploy in any environment. The auditlog api will have access limited only to function app that processes the authentication and authorization events. So instead of running several independent test suites against auditlog api and function app, it is a good idea to create end-to-end tests f.ex

1. The test will start at a point where the bruno tests will add a queue message to the Queue storage
2. The new message in the queue storage will trigger the function app
3. The function app will process it and store in the database.

Now to verify that the end-to-end test, we have to assert the queue message against data in the database. This can be acheived by either running some db script (needs some access setting) to fetch the data from database or via a get endpoint that can retreive the log based on userid,partyid,organisationid or date. The latter if established can also be used by the service desk team to verify some data in connection to any service desk cases.

Tasks

• Establish a GET method in authentication log api with scope authorization
  • Filters : userid, orgid, partyid, date
• Establih a GET method in authorization log api with scope authorization
  • Filters : userid, orgid, partyid, date

Acceptance Criteria

• A new endpoint is established
• Possible to filter data by userid, orgid, partyid, date

Description

Setup and implement Bruno tests for api endpoints

Tasks

• Delete K6 tests
• Setup bruno tests
• Implement test for authentication event endpoint
• Implement test for authorization event endpoint

Acceptance Criteria

• Bruno test is setup for auditlog component
• Test cases implemented for authentication event
• Test cases implemented for authorization event

Description

I sammenheng med utvikling av nye logger for autentisering og autorisasjon trenger vi en juridisk vurdering.

1. Hvilke informasjonselementer må vi logge i sammenheng med innlogging
2. Hvilken informasjon må vi logge i sammenheng med autorisasjon.
3. Hvor lenge må vi oppevare loggene
4. Hvor lenge kan vi oppevare loggene
5. Hvilke juridiske krav settes til oppevaring og tilgang til logg

Skal vi inkludere DelegationEvent log og Azure log?
Lage begrepsliste
Vurdering av behandlingsansvar?
Krav om delvis sletting av informasjonselementer, f.eks. IP-adresse?

Additional Information

Mulige informasjonselementer autentisering

• Tidspunkt
• Autentiseringsnivå
• Autentiseringsmetode
• Ip adresse
• Bruker/systemid

Tasks

• Analyser juridiske krav
• Definer juridiske krav til logg
• Overlever til utvikling

Acceptance Criterias

• Utvikling har klare krav til hva som skal og kan logges.

Description

A release routine must be setup to deploy updates to TT02/Prod environment. As of now, the release routine for Team Authorisasjon is TT02 on tuesdays and prod on wednesdays.
A github package registry will be created for TT02 on every tuesday. The package will have a release version in the format v[year].[revision] f.ex v2023.1 which means 1st release in year 2023.
The code will be tested for stability in TT02 for a week. The same package is then deployed to production.

Tasks

• Setup action to create a release version in TT02
• Setup an action to deploy to specific environment
• Setup an action to create draft release

Acceptance Criteria

• A release routine is setup using github actions

Description

Setup and implement K6 tests for api endpoints

Tasks

• Setup K6 tests
• Implement test for authentication event endpoint
• Implement test for authorization event endpoint

Acceptance Criteria

• K6 test is setup for auditlog component
• Test cases implemented for authentication event
• Test cases implemented for authorization event

Description

QA of the logging in at environment was taken as input for the discussion with the team about logging and the team came up with many good feedback points such as

• Use lookup tables for authentication type, authentication method, authentication level which can save the cost
• Use session id for a login session
• Remove column timetodelete, sanering script can calculate it from the createddatetime
• Should Refresh/Authentication implementation in <> project must be optimized? Looks like too many calls are made

Tasks

• Remove the identifier column
• Remove the timetodelete column
• Add sessionid as guid/string column (Sessionid implementation will be a separate task)
• Add lookup table for authentication event type
• Add lookup table for authenticationmethod
• Add lookup table for authenticationlevel
• Update the authentication model
• Update create table, functions script for authentication event log
• Update repository class for the new db structure
• Update the authentication component for mapping to match the new db structure
• Update unit tests
• Update K6 tests

Acceptance Criteria

• Db structure is updated
• Authentication component is updated
• Audit log database has the following new tables
  • AuthenticationEventType table
  • AuthenticationMethod table
  • AuthenticationLevel table
• authentication.eventlog has the following columns
  • sessionid
  • created
  • userid
  • supplierid
  • orgnumber
  • isauthenticated
  • eventype (a number which should be looke up to AuthenticationEventType table)
  • authenticationmethod (a number which should be looke up to AuthenticationMethod table)
  • authenticationlevel (a number which should be looke up to AuthenticationLevel table)
  • ipaddress

Description

The auditlog component will be continously integrated and deployed to all Acceptance test environments. Each time a PR is merged into the main branch, a packaging actions must be triggered. This action must package the code in to a docker image and publish into github package registry. The package(image) is tagged with the commit hash. The same image is then deployed to all the AT environments parallely

Tasks

• Setup action to deploy to all AT environments

Acceptance Criteria

• Code is continously integrated and deployed to AT environments

Description

Npgsql throws too many clients exception

Steps to Reproduce

1. Enable the auditlog feature in authorization component. Check the auditlog container app logs after an hour
2. Too many clients exception is seen

Cause & Resolution

Rewrite the postgressql connection methods to handle the connection effectively

Description

The security log component will be the component responsible for adding logs to database for authorization and authentication events.

Architecture Recommendation

• Queue Storage for high-performance logging. (no need for waiting for db write)
• Azure Function to process the events in the Queue storage
• Auditlog component to process and store the events in the database
  • An api exposed via azure container app
  • Less hassle with container app setup and easy maintenance compared to kubernetes cluster
• A postgres database to store the authentication and authorization events
• A separate table for authentication event
• A separate table for authorization event
• Write only for application user

Infrastructure Considerations

Security

• How to protect access to the event queue?
  The assumption is that we share SAS key for storage queue with the authentication and authorization component and don't need any additional measures to protect the queue.

• Hashing and signing
  Hashing of a selected set of properties together with signing the hash reduces the chance that logs have been tampered with.
  https://learn.microsoft.com/en-us/dotnet/standard/security/cryptographic-signatures
  Use SHA384 to Hash values.
  The list of values that need to be included in Hash is
  TODO

• Use RSA to sign HASH.

• Do we need to support rotation of certificates?

Database

We will use postgres database for authentication and authorization event logging.

Open Questions

• Do we need a separate database server for auditlog?

Database structure for authentication events

• Time - DateTime for when event happened. Set by producer of logevent
• UserId - The userId for the specific
• SupplierID - Supplier ID if relevant
• EventType - LoggedIn, FailedLogIn, LogOut
• Orgnumber
• AuthenticationMethod
• AuthenticationLevel

Database structure for authorization events
For authorization Events, the following events is identified :

PDP AuthorizationRequest
This is when some component requests the PDP to decide if a user/system is authorized

The suggested approach is to store separate

• subjectuserid
  The userid for the user requested
• subjectparty
  If relevant
• resourcepartyid
  The partyId for resource owner. If relevant.
• resource
  Main resource Id (app, external resource +)
• instanceid
  InstanceId if relevation
• operation
  (read, write ++)
• TimeToDelete
  Value when log should be deleted. Do we need it?
• IpAdress
  The Ipd address for the calling party. Up to
• Decision
  The whole ContextRequest. This can be used to provide details about the resource

{
  "Request": {
    "ReturnPolicyIdList": true,
    "AccessSubject": [
      {
        "Attribute": [
          {
            "AttributeId": "urn:altinn:userid",
            "Value": "1"
          },
         {
            "AttributeId": "urn:altinn:role",
            "Value": "dagl"
          },
         {
            "AttributeId": "urn:altinn:role",
            "Value": "utinn"
          }
        ]
      }
    ],
    "Action": [
      {
        "Attribute": [
          {
            "AttributeId": "urn:oasis:names:tc:xacml:1.0:action:action-id",
            "Value": "read",
            "DataType": "http://www.w3.org/2001/XMLSchema#string"
          }
        ]
      }
    ],
    "Resource": [
      {
        "Attribute": [
          {
            "AttributeId": "urn:altinn:instance-id",
            "Value": "1000/26133fb5-a9f2-45d4-90b1-f6d93ad40713",
            "IncludeInResult": true
          },
          {
            "AttributeId": "urn:altinn:org",
            "Value": "skd"
          },
          {
            "AttributeId": "urn:altinn:app",
            "Value": "taxreport"
          },
          {
            "AttributeId": "urn:altinn:partyid",
            "Value": "1000"
            
          },
          {
            "AttributeId": "urn:altinn:task",
            "Value": "formfilling"
           
          }

        ]
      }
    ]
  }
}

Partitioning of table

We should test partitioning on the table so we do not need to do what we do in Altinn 2, where we rename the table every year.

https://severalnines.com/blog/guide-partitioning-data-postgresql/#:~:text=The%20maximum%20table%20size%20allowed,a%20hundredth%20of%20that%20space.

When to not log?

Should we log a request/response if we have cached it? (we currently do not cache decisions)

Data Expectations

50.000.000 instances
50 authorizations per instance
1kb per log

2.500.000.000 log lines

2.500.000 MBytes

2.5 Terra Bytes log

Acceptance Criteria

• Database users only have write rights to database (can not update rows)
• Fields on the object AuthenticationEvent is hashed and signed with security log certificate

Description

It was agreed during the logging discussion that we implement session id to get overview of the user's activities for a given period of time. In addition the external session id, the token issuer and subscription key that was used to send api request is also logged in to the authentication event database

Tasks

• Add sessionid column
• Add externalsessionid column
• Add subscriptionkey column
• Add externaltokenissuer column
• update authenticationeventrepository class
• Update model
• Update db script for table and procedure

Acceptance Criteria

• Additional columns sessionid, externalsessionid, subscriptionkey, externaltokenissuer are added
• data is saved in the additional columns

Overordnet beskrivelse

Etablere loggtjeneste som logger hvem som har fått tilgang til, eller har utført handling en handling mot, hva og når. Denne loggen må være «write-only» med høy grad av nøyaktighet og integritet, slik at den kan brukes under etterforskning og bevis ved misbruk av løsninger eller liknende
  
 

Overordnet beskrivelse av løsning

Altinn 3 trenger logger slik at man i forbindelse med autentisering og autorisasjon kan ettergå når og av hvem en handling er utført og hvilke rettigheter vedkommende hadde på gjeldende tidspunkt. Loggingen må utføres slik at det ikke påvirker ytelsen i resten av løsningen negativt. Disse loggene må bade tilfredstille tekniske og juridiske krav

• Det etableres en ny Audit log komponent for logging av Autentisering og Autorisasjonshendelser.
• Det opprettes Kø for Autentiseringslogg og autorisasjonslogg
• Det opprettes Azure Function for å kalle Securitylog komponent og for lagring
• Komponent bør kun ha write rettighet på tabeller.

Potensiell kompleksitet tilknyttet forskjellig lagringstid på info elementene.

Hvis nødvendig må det etableres slettemekanismer etter definerte tidsperioder.

Estimat/Omfang 

Spørsmål

Description

Audit log component will be hosted as a container app. Authentication/Authorization component will write each authentication/authorization event to a storage queue. A function app is set with queue trigger such that each event is processed by the function app. The function app then sends api request to specific endpoint(Authentication/authorization) in auth-audit-log component. The auth-audit-log component write the event to the auth-audit-log database.

Tasks

• Set up a resource group for audit log application (All the new resources below will be created in this resource group)
• Setup Storage Queue
• Setup function app
• Setup auth-audit-log as container app
• Setup ny postgres sql server?
• Setup network/domain configuration for connections between function app and container app
• Setup security/network such that authentication component in platform gets access to the storage queue
• Setup security/network such that function app gets access to the storage queue
• Setup security/network such that container app gets access to the postgres sql server

Acceptance Criteria

• New resource group is created
• Storage Queue is setup
• Function app is setup
• auth-audit-log container app is setup
• postgres sql server is setup
• network/domain is setup for container app
• network is configured for storage queue
• network is configured for funciton app
• network is configured for postgres sqls erver

Description

When creating a new component responsible for security logging, we must decide whether to deploy it to Platform Cluster or as A Separate Azure Container App.

See #5 for more details

Pro

• App can be scaled independently
• Does not affect other platform components
• Can have separate access to components. Not every platform developer can access it
• Separate Keyvault access for the signing certificate
• Possible target setup for other platform components?
• Different domain with different cert

Con

• Different setup than other platform components
• Need additional key vault
• Not behind our shared
• Different domain with different cert

In scope

Decide if SecurityLog component should be deployed as a pod in the Platform cluster or as an Azure Container App.

Out of scope

No response

Additional Information

No response

Analysis

No response

Conclusion

No response

Description

Following feedback is registered after the QA of the event log in authorization

• Introduce lookup tables for decision
• Remove identity field
• Include sessionid column
• Remove timetodelete

Tasks

• Introduce lookup tables for resource, operation, decision
• Update database script
• Remove identity field
• Include sessionid column
• Remove timetodelete column
• Update authorization event model
• Add enumeration classes for decision?
• Add k6 tests for auditlog component
• Update unit tests

Acceptance Criteria

• New columns are added to the eventlog table in auhtorization schema
• Authorization component logs the necessary information for authorization event

Description

Function app changes must be continuously built and deployed to azure. The process must be implemented as a GitHub action.

Tasks

• Create a build action to build the function app on a pull request
• Implement sonar scanner for the function app
• Create deploy action to deploy the function app

Acceptance Criteria

• A deploy pipeline is created for function app

Description of the bug

Docker file for the app is missing mkdir cmd to create the configured storage folder for telemetry, causing a lot of warnings to be logged as the setup is incomplete.

Steps To Reproduce

See appinsights

Additional Information

No response