O0500 - Software Architecture (Shared) - BBR · Web viewThis document describes the software architecture of BBR 2.0 and DAR 1.0. This is done by using the concepts from Philippe

KOMBIT

Bygnings- og Boligregistret & Danmarks Adresse Register

O0500 - Software Architecture (Shared)

© Copyright 2015 Netcompany. All rights reserved.

Neither this document nor any part thereof may be passed on to others, copied or reproduced in any form or by any means, or translated into another language without the express prior permission in

writing from Netcompany.

Bygnings- og Boligregistret & Danmarks Adresse RegisterO0500 - Software Architecture (Shared)

Version: 1.7.2

Status: 05 - Godkendt

[Dokumentstatus]

Approver: Claus PedersenAuthor: René RavnHalfdan Reschat,

[email protected]

document.docxUpdated: 07/11/2017 © 2023 Netcompany Page 2 of 94


Document revisions

Version Date Author Status Remarks

0.1 25-08-2015 René Ravn Draft Document structure

0.2 12-01-2016 Alexander Freysson Draft Merge BBR and DAR

1.2 20-02-2016 Troels Bak Andersen Draft Start on version for Etape II – Delleverance 2

1.3 22-02-2016 Halfdan Reschat Draft Service Gateway (section 6.2.2) ready for review.

1.4 15-06-2016 Klaus Ulrik Bjerg Draft New document for Stage II – Deliverance 3

1.5 12-10-2016 Nils Asbjørn Joensen Final Comments handled for approval

1.6 12-10-2016 Halfdan Reschat Final Final version ready

1.7 25-11-2016 Halfdan Reschat FinalCorrections made per KOMBIT comments and comments marked as resolved/done

1.7.1 04-01-2017 Halfdan Reschat Final RetBBR and O0220 referenced

1.7.2 06-03-2017 Klaus Ulrik Bjerg Final Revised design for protected data

References

Reference Title Author Version

A0140A0140 – Use Cases (BBR)

A0140 – Use Cases (DAR)Netcompany

D0160D0160 – Brugergrænsefladedesign (BBR)

D0160 – Brugergrænsefladedesign (DAR)Netcompany

D0180 D0180 – Integration Design (Shared) Netcompany

D0180-AD0180 – Appendix A – Integration Design – Grunddataprogram (BBR)

D0180 – Appendix A – Integration Design – Grunddataprogram (DAR)Netcompany

D0180-BD0180 – Appendix B – Integration Design – Other Systems (BBR)

D0180 – Appendix B – Integration Design – Other Systems (DAR)Netcompany

DD130 DD130 – Detailed Component Design (Shared) Netcompany

DD135DD130 – Detailed Functional Design (BBR)

DD130 – Detailed Functional Design (DAR)Netcompany



DLSBBR_v*.*_20**.**.**_DLS.zip

DAR_v*.*_20**.**.**_DLS.zipNetcompany

O0200O0200 – Operations Guide (BBR)

O0200 – Operations Guide (DAR)Netcompany

O0200-ITILO0200 – ITILv3 processer og metoder (BBR)

O0200 – ITILv3 processer og metoder (DAR)Netcompany

O0400O0400 – Technical Infrastructure (BBR)

O0400 – Technical Infrastructure (DAR)Netcompany

O0220 O0220 – Capacity and Scaling (Shared) Netcompany

Glossary

Term(s) Description

Delegated role(s)

Fuldmagt

Mandate

The delegated roles that a user or system has gotten the mandate for from a different user/system that has these roles in the BBR/DAR system. In Danish, this is called “fuldmagt”.

Dokumentboks

SF1600

Print-system in Serviceplatform that can send out physical letters and well as digital ones.

National scope/permission Scope, permission, etc. that covers all of Denmark, i.e. all municipalities/kommuner.

Local scope/permission Scope, permission, etc. that covers one municipality/komme.

System client

BBR/DAR clientThe website client that users interact with the system through.

ServiceGateway

SGW

The service interface that systems integration to when calling services provided/exposed by the system.

Protected data

Classified data

Data that in BBR 1.7 was security classified in accordance with Sikkerhedscirkulæret, though now in BBR 2.0 is only considered protected and thereby does not need to obey Sikkerhedscirkulæret, only common best practices for keeping data safe.

DAF

Datafordeler

DAF (Datafordeler) is the “data distributor” in the Basic Data Program that registers replicate data to, which DAF then exposes through U-services and sends out events for when data is changed.

Basic Data Program(me)

Grunddataprogram(met)

GD

The Basic Data Programme that all registers and DAF are a part of.



RetBBRRetBBR is a separate system for citizens and SKAT employees to report corrections to BBR, which RetBBR then sends to BBR as structured messages (“strukturerede henvendelser”).

Table of Contents1 INTRODUCTION..................................................................................................7

2 ARCHITECTURAL GOALS AND CONSTRAINTS.......................................................72.1 Loosely coupled system.................................................................................72.2 Individual Scaling...........................................................................................82.3 Robustness towards failure in other systems..................................................82.4 Digitalization Strategy...................................................................................8

3 USE CASE PERSPECTIVE.....................................................................................83.1 Use cases specific to BBR 2.0..........................................................................93.2 Use cases specific to DAR 1.0.........................................................................10

4 LOGICAL PERSPECTIVE.......................................................................................114.1 Overview.......................................................................................................114.2 Logging.........................................................................................................14

4.2.1 Log types.................................................................................................................144.2.1.1 System and Revision log................................................................................14

4.2.1.1.1 General data fields....................................................................................154.2.1.1.1.1Transaction IDs.......................................................................................174.2.1.1.2 System log and Security log.....................................................................174.2.1.1.2.1Error logging...........................................................................................174.2.1.1.2.2Response time........................................................................................184.2.1.1.3 Revision log...............................................................................................18

4.2.1.2 Verification Log..............................................................................................204.2.1.3 Operation Log.................................................................................................20

4.2.2 Collecting log data...................................................................................................214.2.2.1 Splunk Forwarders..........................................................................................21

4.2.3 Logging levels..........................................................................................................214.2.4 User interface..........................................................................................................224.2.5 Storage period.........................................................................................................234.2.6 Log reports..............................................................................................................234.2.7 Log Probes...............................................................................................................24

4.2.7.1 BBR.................................................................................................................244.2.7.2 DAR................................................................................................................25

4.2.8 Logging failure.........................................................................................................264.2.9 Monitoring logs........................................................................................................26

4.3 Integration....................................................................................................274.3.1 Grunddataprogrammet............................................................................................28

4.3.1.1 BBR.................................................................................................................294.3.1.2 DAR................................................................................................................30

4.3.2 Framework architecture...........................................................................................304.3.2.1 BBR.................................................................................................................304.3.2.2 DAR................................................................................................................31

4.3.1 Existing Integrations................................................................................................314.3.1.1 BBR.................................................................................................................314.3.1.2 DAR................................................................................................................32

5 PROCESS PERSPECTIVE......................................................................................335.1 Events...........................................................................................................33

5.1.1 Generating events...................................................................................................345.1.2 Receiving events.....................................................................................................34



5.1.3 Processing events....................................................................................................355.1.3.1 Hændelsesbesked data format......................................................................37

5.1.3.1.1 Filtreringsdata...........................................................................................385.1.3.1.2 Objektregistrering.....................................................................................385.1.3.1.3 Leveranceinformation...............................................................................385.1.3.1.4 Beskeddata...............................................................................................38

5.1.4 Error handling..........................................................................................................385.2 Replication to Datafordeler............................................................................38

5.2.1 Informing DAF about scheduled downtime..............................................................405.3 Processes related to caching..........................................................................41

5.3.1 Caching/copying data from other registers.............................................................415.3.1.1 In BBR.............................................................................................................415.3.1.2 In DAR............................................................................................................41

5.3.2 Caching for DAR search functionality......................................................................425.3.2.1 Initializing the cache......................................................................................445.3.2.2 Maintaining the cache....................................................................................45

6 IMPLEMENTATION PERSPECTIVE.........................................................................466.1 Technical Architecture...................................................................................466.2 Frontend Tier.................................................................................................48

6.2.1 Website....................................................................................................................496.2.1.1 View...............................................................................................................506.2.1.2 Controller.......................................................................................................516.2.1.3 Model..............................................................................................................51

6.2.2 Services...................................................................................................................516.2.2.1 Request-response services.............................................................................52

6.2.2.1.1 Authentication workflow...........................................................................526.2.2.2 BBR inbound integrations...............................................................................536.2.2.3 DAR inbound integrations..............................................................................54

6.3 Application Tier.............................................................................................546.4 Data Tier.......................................................................................................556.5 Reporting Services.........................................................................................56

6.5.1 Report data..............................................................................................................566.5.1.1 Point in time (current) views..........................................................................566.5.1.2 Bitemporal (history) views.............................................................................56

6.5.2 Report rendering......................................................................................................566.5.3 Report authoring......................................................................................................576.5.4 Reporting architecture.............................................................................................57

6.6 InRule rule engine..........................................................................................586.6.1 Rule definition access..............................................................................................586.6.2 Rule engine scalability.............................................................................................596.6.3 Security....................................................................................................................59

6.6.3.1 IP Filtering......................................................................................................596.6.3.2 inRule Catalog Authentication........................................................................59

7 DEPLOYMENT PERSPECTIVE...............................................................................597.1 BBR...............................................................................................................60

7.1.1 BBR 1.8 and BBR – External Test.............................................................................617.2 DAR...............................................................................................................63

8 SECURITY PERSPECTIVE.....................................................................................648.1 Securing the solution.....................................................................................658.2 Authentication and authorization...................................................................66

8.2.1 Federated login through SAML tokens.....................................................................678.2.2 Authentication.........................................................................................................69

8.2.2.1 General SAML authentication.........................................................................698.2.2.2 End-user logon to System client.....................................................................70

8.2.2.2.1 Logon with NemLog-In..............................................................................708.2.2.2.2 Logon with Context Handler......................................................................718.2.2.2.3 Session management................................................................................72



8.2.2.2.4 Logout.......................................................................................................728.2.2.2.5 Report Builder authentication...................................................................73

8.2.2.3 External system logon to System Services....................................................738.2.2.3.1 System ajourføringsservices (Grunddataprogrammet).............................738.2.2.3.2 System Service Gateway, used by “Eksternt indberetningssystem”........74

8.2.2.4 System (BBR/DAR) logon on to external services...........................................758.2.3 Authorization model.................................................................................................75

8.2.3.1 Authorization in BBR......................................................................................758.2.3.1.1 Roles and privileges..................................................................................778.2.3.1.2 Data scopes..............................................................................................788.2.3.1.3 Classified data...........................................................................................798.2.3.1.4 Permissions...............................................................................................808.2.3.1.5 Authorization model overview..................................................................80

8.2.3.2 Authorization in DAR......................................................................................818.2.3.2.1 Roles and Rights.......................................................................................83

8.2.3.3 Delegation of roles (”fuldmagt”) - both BBR and DAR....................................848.2.3.3.1 Delegation and classified data (BBR)........................................................848.2.3.3.2 Delegation in the System client................................................................848.2.3.3.3 Delegation for “Eksternt Indberetningssystem” (the System Service Gateway)..................................................................................................................85

8.2.4 Access control module.............................................................................................858.2.5 Reporting Services security.....................................................................................87

8.2.5.1 Report structure.............................................................................................878.2.5.2 Data filtering (BBR)........................................................................................878.2.5.3 Report access roles........................................................................................87

8.2.5.3.1 Report query role......................................................................................878.2.5.3.1.1Authentication........................................................................................878.2.5.3.1.2Authorization..........................................................................................888.2.5.3.1.3Report access.........................................................................................888.2.5.3.1.4Classified data access............................................................................888.2.5.3.1.5System access process...........................................................................888.2.5.3.2 Report administrator role..........................................................................888.2.5.3.2.1Authentication........................................................................................898.2.5.3.2.2Authorization..........................................................................................898.2.5.3.2.3Report access.........................................................................................898.2.5.3.2.4Classified data access............................................................................898.2.5.3.2.5System access process...........................................................................89

8.3 Personal sensitive and classified data.............................................................908.3.1 BBR..........................................................................................................................908.3.2 DAR..........................................................................................................................90

8.4 Security overview relative to requirements.....................................................908.4.1 General requirements..............................................................................................908.4.2 Persondataloven......................................................................................................958.4.3 Sikkerhedsbekendtgørelsen.....................................................................................95



1 IntroductionThis document describes the software architecture of BBR 2.0 and DAR 1.0. This is done by using the concepts from Philippe Kruchten 4+1 architectural view model where security perspective is included as an independent view. First an overview of the use cases for the system, and then change perspective of how to interpreter the system. Figure 1 illustrates this concept and this process is reflected in the following chapters. Since BBR and DAR have many similarities they are described in this document, where BBR and DAR are referred to as the “System”. In this document, BBR is the 2.0 version except when specified otherwise, e.g. when focus is on the changes from when upgrading BBR 1.7 to 2.0.

Figure 1 - Perspectives

The different perspectives in the software architecture of the System is:

- Use case perspective: Describes the use cases and identifies the interested parties. This is a summary of [A0140].

- Logical perspective: Describes the logical system.

- Process perspective: Describes the special processes regarding the system.

- Implementation perspective: Describes the different components and how they are combined. Also describes the software used in the solution.

- Deployment perspective: Describes the overview of the technical architecture and the server’s role.

- Security perspective: Describes how security perspectives influences the architecture.

The rest of this document will go through these perspectives one by one.

2 Architectural goals and constraintsThis section aims to cover the architectural goals and constrains of the system.

The system is a part of a larger public government sector platform, both the central government and in the general municipality platform. Therefore, the system has several architectural targets that the system aims to fill. The System is primarily in the public government sector platform.



2.1 Loosely coupled system The system must be built with loosely coupled components, which interact through precise and controlled interfaces. Similarly, the system must have loosely coupled connections to surrounding systems. These systems have a thigh business relation, but their integration to each other must be defined by interfaces.

2.2 Individual ScalingThe System is completely scalable. Every defined load step is supported and the System can be adjusted as needed. The System is furthermore ready to implement eventual options increasing the capacity of the System.

The System components support both horizontal and vertical scaling, so it will be ready to further scaling beyond the defined frames. Because of this, the System is adjustable after demand.

More information about scaling can be found in [O0220].

2.3 Robustness towards failure in other systems The System is secured against changes or crashes in external services, since it is loosely coupled. This means that integrations-components only have access to the System through internal business-services that only contains system-relevant information. This means that the internal services does not depend directly on the integrations.

2.4 Digitalization StrategyThe System upholds the Fælleskommunale Digitaliseringsstrategier (FÆKDIG) and Fællesoffentlige Digitaliseringsstrategi (FOFDIG), which is, for instance, done via:

Common public systems like Beskedfordeleren, Serviceplatformen and Grunddataprogrammet with associated registers

Whenever it is in the Systems best interest to comply with the technical and business-standards, which have been defined within the scope of the framework architecture and Grunddataprogrammet with corresponding data-exchange and integrations.

The System uses Kommunernes Arkitekturråds godkendte Fælleskommunale Arkitekturprincipper (KLAFA). The System uses the defined business-components, business-services and business-processes in the framework architecture. This is done via:

As much as possible are integrations to external systems within the used framework architecture. For example:

o The widespread use of the KOMBIT supporting systems, where functionality from Adgangsstyring, Beskedfordeler and specialist systems are used extensively.

Furthermore is Serviceplatformen used where possible. Every integration, if possible, go through Serviceplatformen, so the reusability of these interfaces is maximized.

Upholding the technical and business-standards, requirements to data exchange and the integrations defined from the Systems best interests.

As much as possible use the terminology suggested by the information models throughout the System



3 Use case perspectiveThis chapter describes the system from the perspective of the user, both relevant parties and use cases. The use cases in this perspective consist of the use cases from BBR 2.0 and DAR 1.0. This will only be an overview of the use cases, for more details see [A0140].

3.1 Use cases specific to BBR 2.0There are 10 participants in these use cases, 6 users and 4 systems. Furthermore, it is required that BBR 2.0 can integrate up to Støttesystem Klassifikation to publish codelists.

In Figure 4 - A map of all the use cases specific to BBR 2.0 is shown all the use cases for BBR 2.0 and how the participants interact with them.

Figure 4 - A map of all the use cases specific to BBR 2.0

Users

- BBR User: Responsible for maintenance (registration) of certain BBR information.

- BBR Registerfører: Responsible for maintenance (registration) of BBR information and ensure quality of registrations.

- BBR System role administrator: Responsible for administration of system roles in BBR.



- BBR Administrator: Responsible for configuration of BBR in own municipality.

- User of Eksternt Indberetningssystem: Receive message or BBR messages or messages in Dokument-boks with changes of BBR-data.

- Useradministrator: Make sure that governmental users can use BBR.

Systems

These system actors use the system. For a detailed description of the users, see [A0140] (BBR).

Grunddataregister: Can be any of the three Grunddataregisters (DAR, Matriklen and Ejerfortegnelsen) and has to both update and be kept updated.

Datafordeler: Distribute data from Grunddataregisters to external systems and among the Grunddataregisters including exchanging Hændelsesbeskeder when an event occurs in one of the Grunddataregisters.

Eksternt Indberetningssystem: Makes sure that users of Eksternt Indberetningssystem can perform their tasks (register and search).

Støttesystem Administrationsmodul: Receives system roles from BBR and use these to set up fælleskommunale systems Security Token Service and Context Handler.

Støttesystem Klassifikation: Enable that BBR can publish its codelists.

Støttesystem Organisation: Currently not used in BBR.

3.2 Use cases specific to DAR 1.0There are 12 participants in these use cases, 8 users and 4 systems. Figure 5 below describes the different participants in the use cases of DAR 1.0 and how the participants interact with the System.

Figure 5 - A map of all the use cases specific to DAR 1.0

Users

- DAR User: Responsible for maintenance (registration) of certain DAR information.



- DAR System role administrator: Responsible for system roles.

- DAR National Administrator: Responsible for configuration of DAR nationally.

- DAR Local Administrator: Responsible for configuration of DAR in own municipality.

- User of citizen and business (Eksternt Indberetningssystem): Sends change requests in DAR.

- Useradministrator: Make sure that governmental users can use DAR.

- DAR Quality Assurance: Ensures the quality of data via available reports.

- DAR Spelling Checker: Ensures the name of streets are spelled correctly.

Systems

These system actors use the system. For a detailed description of the users, see [A0140] (DAR).

Grunddataregister: Can be any of the Grunddataregisters and has to both update and be kept updated.

Datafordeler: Distribute data from Grunddataregisters to external systems and among the Grunddataregisters including exchanging Hændelsesbeskeder when an event occurs in one of the Grunddataregisters.

Eksternt Indberetningssystem: Makes sure that users of Eksternt Indberetningssystem can perform their tasks (register and search).

Støttesystem Administration module: Receives system roles from DAR and use these to set up fælleskommunale systems Security Token Service and Context Handler.

4 Logical perspectiveThis chapter describes the logical architecture of the System. An overview of the logical architecture of the System is provided in section 4.1. The System logging functionality is described in section 4.2. The System integrations in context of external systems are described in section 4.3.

4.1 OverviewThe logical architecture is divided into components and layers, strictly separated like the target architecture. This layer-separated architecture ensures that there are clear boundaries between the layers, which in turn means that the components can be replaced and changed without it necessarily having any consequences for the rest of the layers. This is illustrated in Figure 6 for BBR and DAR. After the figures, each of the components are described.



Figure 6 - Logical architecture for the system



Name Description

Authentication & authorization Authentication and authorization of the security-model.

System client The web-based System client for the municipalities.

Service Gateway Ekstern Integration endpoints for Eksternt indberetningssystem.

Service Gateway Grunddata Integration endpoints for Grunddata-registers.

Service Gateway Rammearkitektur Integration endpoints for Fælleskommunale Rammearkitektur.

Service Gateway Eksisterende

Separate integration endpoints for the existing services, which uses the existing authentication system, e.g. FIE.

Service Agent(s) Initiator(s) of outgoing integrations from a layer in the logical architecture.

Rapport rendering Shows the different types of rapports

Rapport services Generation and edit of rapports

Service interfaces Consists of contracts and models for integrations and outputs.

Batch Consists of scripts and services, which can be timed jobs with business logic used for updating and keeping up-to-date.

Business Layer Consists of the business logic with related entities and models

Data Access Layer

Consists of data logic to the data layers and the related service agents to the integrations

Data Layer Consists of the data of the system in SQL databases, whereas data that is not stored in the system is integrated to for instance external Grunddataregister.

The System is divided into component-layers that ensures that the areas that often change are kept separate. This can be seen with the separation of the business logic component. By isolating the business logic is it ensured that changes will not affect the rest of the System, which will both minimize expenses, increase the quality whenever a change is implemented and the gives the possibility of testing the components.

The Service Gateway components are loosely coupled to the rest of the System via internal business services, which consists of system relevant information, in the service oriented architecture the System is a part of. This ensures a loose coupling between the external exposed integrations and the internal services. This is obtainable since the System does not recycle formats or contents of the data from external interfaces. What is done instead is to pick relevant data for each service and forward it to the System. Furthermore, this loose coupling ensures robustness towards changes in the existing interfaces. This can be achieved since the internal service layer is not dependent on the format that is sent through the integrations, and changes to these formats does not have any direct impact on the



rest of the System. Only the integrations in the component need to be modified. The system interfaces are described in [D0180], where both internal and external interfaces have been gathered.

The loose coupling gives the best grounds for robustness related to changes and a cost effective handling of external interfaces in the System.

The System is one logic instance divided into smaller logical parts making the System smooth and robust. This means it is the same logical system used among all the interfaces. Data restriction for the users is done by role management together with the data model in the database. All data and business logic processes are gathered in one logic instance. This ensures that security through roles restrict the actual data.

4.2 LoggingThis chapter describes how the logging will function in the System logically. The technical details governing collection and management of log files and other similar files are described in [O0200].

In general, the logging solution will provide a high level of Confidentiality, Integrity, and Availability:

The different logs will be protected at varying degrees. All production logs will be kept at continuously backed up RAID drives. The revision log will be kept securely with read access only provided to selected users. The logging tool will only have appending rights.

The logs will be backed up and kept in accordance with the agreement.

The relevant logging entries will be made available through Splunk using forwarders.

4.2.1 Log types The System has four different types of logs. They are:

System log – collects all technical logs from various subsystems

o Security log – This is a separate subset of the system log. It contains information regarding log in.

Revision log – collects information about the use of the System

Verification log – collects information regarding deployments, patches and general changes to the state of the System and the network.

Operation log – collects information about the underlying systems the Application is running on, such as operating system, networking equipment, etc.

The Verification log and Operation log are part of the operations contract.

All logs are written to per environment, meaning that all environments have their own log files.

4.2.1.1 System and Revision log

The two main log files, seen from the application’s point of view are the System Log and Revision Log. These log files are specified in detail in the following sections.

An overview of the two logs are provided in Figure 7.



Figure 7 – System and Revision log

The Application layer is responsible for logging to the System and Revision logs. This is done at two levels. Reading data is done for inbound service requests when they are received. Creating and updating data is done for a transaction at unit of work level. For a specification of what is logged for specific read and write see the field specification in section 4.2.1.1.2

Access forbidden and Access denied are logged using the dk.nita.saml20 and IAuditLogger interface to the Security log.

4.2.1.1.1 General data fields

A number of general logging fields have been proposed in the requirements specification. This section reproduces this list of fields accompanied with comments regarding the usage and the reason for omission if omitted.

Generally, the IDs in this list will only be filled out when available.

Felt ID Content (Danish description) Comment

Reason for omission

Log ID Unikt id for log besked Guid is used. -

Kald ID Unik identifikation af selve forespørgslen

Guid is used.

The ID is kept internally in the Frontend, Backend, and Service Gateway and does not cross machine boundaries

-

Transaktions IDGlobalt unikt id som generes af det system, som initierer kaldet, og

Guid is used – and is defined at the beginning of the call in either the

-



propageres tværs over andre fagsystemer og maskingrænser.

Frontend or the ServiceGateway. There is no agreement with other systems to include this in service interfaces, so it only exists internally in the System.

Aftale ID

Unikt ID, som identificerer den aftale, som anvendes i forbindelse med forespørgsel

Omitted in accordance with workshop ”TA.8 - Logning, svartidsmålinger iht. Servicemål, browsere, mm”.

These IDs does not exist for the integrations implemented by the System

KaldersAftale ID

Unikt ID, som identificerer kalders aftale, som anvendes i forbindelse med forespørgsel

Omitted in accordance with workshop ”TA.8 - Logning, svartidsmålinger iht. Servicemål, browsere, mm”1.

These IDs does not exist for the integrations implemented by the System

ParametreParametre som er anvendt ved forespørgsel

Filled out for integrations. For User Search the Søgekriterier is used (Revision log)

-

Tidspunkt Tidspunkt for logning Timestamp. -

Service ID ID, som identificerer den kaldte service

Filled in for system to system calls.

The called url is logged. -

IP Adresse

IPv4 eller IPv6 adresse, som entydigt identificerer enheden i et netværk.

The IP address of the Server -

MaskinnavnMaskinnavn for enhed, som genererer logbeskeden

The hostname of the machine. -

Bruger IDUnik identifikation af brugeren, som udfører kaldet

ID from STS token RID/PID.

Filled in for users.-

IT-System IDUnik identifikation af det IT-System som udfører kaldet

Filled out with the name of the system instantiating the call.

Mainly BBR or DAR.

In the service gateway the external system.

-

Organisation ID Teknisk nøgle, som identificerer

Municipality code (Kommunekode) and CVR

-

1 https://goto.netcompany.com/cases/GTO460/KMTBBR/DocumentLibrary/90%20-%20Mødereferater/Afklaringsfase/15092015%20-%20TA.8%20-%20logning,%20svartidsmålinger.docx



organisationen, som brugeren er tilknyttet

number is used in this System. Never filled out for private users.

Organisationsenhed ID

Teknisk nøgle for den organisatoriske enhed som brugeren er tilknyttet

Omitted in accordance with workshop ”A.8 - Logning, svartidsmålinger iht. Servicemål, browsere, mm”.

Not relevant for the System.

In addition to the above the specific roles of the user will be logged. The individual rights associated with the roles will however not be logged.

4.2.1.1.1.1 Transaction IDsWhen a process begins a unique “transaction ID”, which is a GUID, is generated. This generated GUID is used henceforth throughout the entire process, including all relevant system calls. This will make it possible to compare logs across the System as well as external systems.

When one system wishes to make call to another system, both the transaction ID and the calling system’s GUID is included in the call. The System’s logging will be implemented in such a way that, if a function being logged receives a transaction ID, this GUID will be used in all function calls in that function, including external calls to other systems that support it. This makes all calls, including calls to external systems that support this, traceable.

This situation is the ideal approach. The cross system tracking is however dependent on the defined interfaces. If no transactions ID is available through the interface, then a new one is generated.

4.2.1.1.2 System log and Security log

This section describes the System log specific fields accompanied with information about type or format.

The Security log is a subset of the System log and contains all information regarding log in attempts, certificate errors, authorization errors, authentication errors, and other security related events.

These fields will be filled out in addition to the general logging fields. They will however only be filled out when an error occurs in the System. The system log is used for other purposes than documenting errors occurring in the System. Under these circumstances, the error specific fields will not be filled out.

4.2.1.1.2.1 Error logging

The following fields are filled out when experiencing an Error.

Field Content (Danish description) Type/Format

Loglevel Betydnings- eller alvorlighedsgradTRACE, DEBUG, INFO, WARN, ERROR, FATAL

Logbesked Selve log indhold String with arbitrary data

FejlkodeSeparat attribut som identificerer selve typen af fejl String



The definition of the Log levels types are defined in section 4.2.3.

4.2.1.1.2.2 Response time

In the context of response time, these attributes will be logged:

Field Content Type/Format Comment

Forespørgelsesstørrelse Størrelse af forespørgelsen Number

Filled out for external request only – The logged unit is in KB

Svarstørrelse Størrelse af svaret Number

Filled out for external request only – The logged unit is in KB

Svartid Svartid på forespørgelsen NumberMeasures the response time for a given request

Operation Navnet på den kaldte operation StringFilled out with the name of the operation called

Kaldt System Navn på det kaldte system StringFilled out with the name of the called system.

StatusStatus på kaldet til det eksterne system Number

The status of the external call

The response times are logged in the system log to ensure that total response times can be deducted the time used by external systems. This provides traceability and foundation for the response time measurements.

4.2.1.1.3 Revision log

The revision log differs substantially from the other log types, in that it is only accessed in special cases and only by specific users. This is because it contains information about the actions of every user in the System, any of which may be linked to or even include confidential information.

In order to limit access to the revision log, it will not be exposed to Splunk. Instead, the revision log is going to be an xml based file with user management and auditing. This ensures full control over who can access the log.

As previously stated all create, read, and update operations are logged in the revision log. See Figure 7 – System and Revision log. Combining the log files with the bitemporal data provides complete knowledge regarding access to data as well as data changes made via the systems framework2.

The log system itself only has the rights to write new log entries. However, it may not read, edit, or delete any log entries. It will be however possible, via a specific procedure from the service catalog, to request old log entries in the revision log be deleted, as per applicable laws.

In cooperation with KOMBIT, Netcompany will elect a few national administrators that will have the rights to read the revision log. These administrators will only have access to read the revision log. They will not be able to grant other users the same rights. All attempts to access the log, as well as all granted access, is logged. This log can only be accessed by the elected national administrators. 2 This is in the context of the main BBR and DAR objects which are bitemporal.



A number of Revision log specific fields have been suggested in the requirements specification. This section reproduces this list of fields accompanied with comments regarding the usage and the reason for omission if omitted.

FieldContent (Danish requirement description)

Comment Reason for omission

ApplicationIdentifikation af applikationen, samt evt. Komponent

BBR and DAR respectively -

Komponent Navn på den kilde, som danner logbesked

The name of the component in which the logging occurs -

Borger IDUnik identifikation af borgeren, som der arbejdes med

Not relevant for BBR and DAR

Searches for a specific user is not possible

Søgekriterier (Valgfri)Anvendes, hvis borgers unikke identifikation ikke er tilgængelig.

The search criteria’s submitted from a user search is logged.

Elastic search (DAR) searches are not logged since the data are publicly available.

Sags ID Unik identifikation på en given sag.


BBR and DAR is not a casework handling system

Tilstandsskifte (Valgfri)

Beskrivelse af tilstandsskift i en pågældende sag



Aktør (Valgfri) Ændringer i sagsbehandler



Note (Valgfri)Mulighed for valgfrit at logge ekstra information



RegistreringsTidspunkt -

The registration time of a create or update transaction.

Only filled out for write operation.

Objekt Id -

The ID of the Object being created or updated.

Only filled out for write operation.

Objekt type - The name of the BBR or DAR entity being created or updated.



Only filled out of write operation.

4.2.1.2 Verification Log

The purpose of the verification log is to monitor changes made to the System. This process is covered by the operations contract.

The verification log is handled as a Netcompany Toolkit list. A reduced example of such a toolkit list is shown below (more details in [O0200-ITIL], chapter 6 and 7):

Sags ID Titel Status Oprettet Prioritet Ansvarlig

KMTBBR-1 Service Window for BBR Wednesday 15st June from 05:30 – 06:00 CET 10 - Ny09-06-2016

08:30 D - LavNetcompany Person

A number of other fields are logged in addition to the above in the toolkit. These are available in detail view. An example of such a list can be found here for BBR:

Verification Log

Log entry - Firewall changes

In addition to the process, being documented as defined above deployments to the server will be logged and these entries will be forwarded to Splunk.

4.2.1.3 Operation Log

The operation log is used to monitor the System and its surroundings. This is done using the Windows System Event log, which logs information regarding the System and applications. Generally, these logs are kept locally on each machine and are available to KOMBIT by service request to Operations.

The Windows System and Application event log are monitored for certain events, which will trigger a predefined task in the Toolkit. These logs will be backed up daily to the log drive on each server.

The Windows System and Application event logs are furthermore monitored and relevant entries will be forwarded to Splunk.

Furthermore, all network components are monitored and their log files are sent directly to Splunk.

4.2.2 Collecting log dataSystem log data will be collected and aggregated by an agent and indexed in Splunk. The indexed log data can be analysed and aggregated to generate reports and raise alarms. Parallel to the agents, log data of the raw log files are backed up via server backup. The raw files are available to KOMBIT by request to Operations.


https://goto.netcompany.com/cases/GTO460/KMTBBR/Lists/Tasks/DispForm.aspx?ID=212&Source=https%3A%2F%2Fgoto.netcompany.com%2Fcases%2FGTO460%2FKMTBBR%2FLists%2FTasks%2FAlle%2520OP%2520sager.aspx%23InplviewHashbdb3a153-570f-4fde-a912-187c1573884e%3DCascDelWarnMessage%253D1-SortField%253DCreated-SortDir%253DDesc-FilterField1%253DCaseType-FilterValue1%253DChange&ContentTypeId=0x010800B8AF5508C2F1694FAAB94937CF3559D7

https://goto.netcompany.com/cases/GTO460/KMTBBR/Lists/Tasks/Alle%20OP%20sager.aspx


Figure 8 – Logging structure

Figure 8 – Logging structure shows a flow chart of how logging works in the System.

The log files are stored locally on the servers, which utilize redundant raid drives. These servers are furthermore backed up.

The Revision log is kept securely and access attempt to it is logged.

The Operation logs and Verification logs are a part of the infrastructure and are therefore documented in [O0200].

4.2.2.1 Splunk ForwardersThe Agent will collect system log entries and further forward these to Splunk. The splunk forwards are services which run on the individual instances. These services are responsible for monitoring and forwarding the log entries to Splunk. The Agent will be configured such that only relevant logging entries are forwarded to Splunk.

Each forwarder continuously forwards entries and marks their progress. If a forwarder is stopped, for whatever reason, then they will continue after being restarted.

The forwards will be monitored and will be restarted if an error occurs. Upon restart, the forwarded will continue from their last log entry.

4.2.3 Logging levelsSettings, including logging levels, can be set in a configuration file. The System supports setting the logging level without restarting the System and setting logging levels for each of the logs. Furthermore, logging levels, which are given in Table 1 - Logging levels, can be set per log type.

Log level UseALL Used in case one wants everything logged. It may be advantageous to split the logging up such

that warnings and errors are logged to one place, whereas lower levels of logging such as information are logged to another. However, this setting will log both to one place.

TRACE Used for development and debugging at a low level. It may for instance be useful if one wants to find an error in an external component to find out exactly what is going on. Not for use in production.

DEBUG Used for debugging and development. It may for instance be useful to check the parameters



internally in a function along with the local variables available there. Not for use in production.INFO Used for general logging of information. This includes transactions, calls to external interfaces,

and correct user login.WARN Used to log events that may be worrying, but which the System can handle without needing any

attention. This may be incorrect user login.ERROR Used for logging actual bugs or problems in the System, causing some operation or other to fail

to complete. Does not log user errors – only system errors, such as a networking problem. FATAL Used for logging a severe problem with the System, requiring that the System terminates

immediately. This may include loss or corruption of data.OFF Turns off all logging in its entirety. Not even application crashes are logged. Not recommended.

Table 1 - Logging levels

4.2.4 User interface

The Splunk logging component collects and handles the logs, which the System generates. Technically, logs are written to files on the local drive on whichever subsystem is recording them. They are then found and transferred by the Splunk agent. An exception to this is the Revision log, which will not be forwarded.

By posing a simple set of rules for parsing, Splunk is able to aggregate and present the logs. An example of a real-time log analysis can be found on Figure 9 – Splunk searchError: Reference source not found.

Figure 9 – Splunk search

The log files themselves are written in an XML format that Splunk can easily parse as a standard option.

4.2.5 Storage period

A procedure, given special permissions, makes sure to delete log events when they reach a certain age. The same applies to Splunk’s index-database. Here, log information is deleted after a certain desired time period. All logs are protected against changes or deletion via the user rights systems in the environment the System runs on. This prevents unintentional changes to the log data.

Log Storage period



System log 6 months

Security log 6 months

Revision log 6 months

Verification log 6 months

Operation log (Drift log) 6 months

The Revision logs and Security logs are kept in separate log files. After a certain time period, they will be deleted via a specific procedure.

The verification log is in addition to the log files also documented in the toolkit which is not deleted after 6 months.

4.2.6 Log reports

Splunk reads the log files almost real-time and makes the contents immediately available for alert systems, analysis, dashboards, and specialized visualizations. This makes it possible to generate log reports. For instance, these log reports can give information about a user’s activity in a given time period. Likewise, it is possible to narrow the search to a specific time interval or a particular user.

When logging the user Interface, it is essential that the entire experience, which is dependent on the System, is logged. This necessitates an “outside – in” measurement of the System, including Firewall, Switch, and Load Balancer.

For the proposed System, this cannot be computed on the server-side alone. For this reason, probes must generate timestamps, which can then be transferred over to Splunk. Here, the data may be analysed as report data, for instance.

Figure 10 – Logning af svartider i brugergrænseflade

Figure 10Error: Reference source not found shows how this logging is going to be handled both for probes and for users. For more information on log probes, see section 4.2.7. The start and final timestamps are saved with the relevant use case attached. When the result for the request has left the System, the final timestamp is saved.

The user interface can log the time taken using this data. Because of this, it will be easy to make a timely visual- or databased analysis of the time taken for every case via Splunk.



4.2.7 Log ProbesResponse time measurements taken continually for the System as described in figure Figure 10Error: Reference source not found. “Users” in that context can refer to either an actual human user or to a probe. A probe is a program periodically automatically that is designed to start an event that will measure the time it takes to use the System as if it were a user. This act will also generate a log event, just as it does when performance is measured for a regular user. It is a simulation of a search and attempts to recreate the use cases as best as possible.

The following sections defines the use cases which will be used for the logging probing mechanism and thus the resulting response time measurements.

4.2.7.1 BBR

The following table describes the Log probe services used for BBR.

Service Description Use case Category

Get Bygning

Get all the data needed for the Bygning page aggregated into 1 object. This calls 20+ backend services, many of them in parallel, and aggregates the data into one object containing information from Bygning, Etage(s), Opgang(s), Enhed(s), Grund, Jordstykke, Husnummer and Ejendomsrelation

UC01 Complex

Create Bygning

Creates a complete Bygning hierarchy (including Etage, Opgang and Enhed objects) in Master data, including performing the business validation via Rule Engine for each created object

UC01 Complex

Search by ID

Searches a given table for a given UID and returns the full result hierarchy the object is placed in. Used in many scenarios to generate object hierarchies.

UC03 Medium

Search by Husnummer Id

Search for BBR objects by Husnummer. Very common search when using the quick-search or address based search

UC03 Medium

Get Opgang Get all the data needed for the Opgang page UC01 Simple

Get Vejnavn suggestions

Gets auto-complete suggestions for a partially type Vejnavn

UC03 + Quicksearch

Simple

4.2.7.2 DAR

The following table describes the Log probe services used for DAR.



Service Description Use case Category

Get DAR objectsGet all the DAR objects within a bounding box (around 400 in central Copenhagen). It is normally used on zoom level 7 or more.

UC01-08 Complex

Search for DAR objects

Search for a specific DAR object by searching for its street name or address. UC01-08 Medium

Show Adresseopgave overview

Getting a list of Adresseopgave list (from Copenhagen, depends on the current number of open AdresseOpgave)

UC10 Medium

Search for Adresseopgave

Search for a specific Adresseopgave by search for its id. UC10 Simple

Get Husnummer object Get a Husnummer object. UC01, 02,

07, 08 Simple

Get Reserveret vejnavn object Get a Reserveret vejnavn. UC03, 04 Simple

Get Navngiven vej object Get a Navngiven vej object. UC05, 06 Simple

4.2.8 Logging failure

In the event of a failure in the logging mechanism the logging system will, to the best of its ability, log this as an event in the log. Based on the failure’s significance, the System might raise an alert. As with every other alert, it is possible to specify who to notify and how. This might be via e-mail, for instance.

Failure to write to one of the log files will result in a log entry being written to Windows Application log. This logging entry in monitored by operations. Upon such a logging error an alert is raised and a Critical toolkit entry is created.

4.2.9 Monitoring logsThe System logs are monitored for anomalies based on a baseline. The anomalies are investigated and appropriate actions are taken. The baseline is based on observations over a period time. Any outliers, which significantly differs from the baseline, are treated as anomalies.

This baseline is determined once the system is running and will be evaluated on a continues basis as necessary.

An example of such anomalies is unsuccessful access attempts. Both successful and unsuccessful login attempts are logged and monitored.They will be identified based on baseline.

4.3 IntegrationThe majority of this chapter is divided into two parts, one for BBR and one for DAR.



The System is integrated with other systems. Figure 11 (for BBR) and Figure 12 (for DAR) illustrates the System in context of external systems. For a detailed description of the System integrations see [D0180] and the [D0180-A], [D0180-B] documents for BBR or DAR.

cmp Systemkontekst

BBR

Eksisterende Integrationer::

Dansk StatistikEksisterende Integrationer::

Certificeringscenter


Eksternt Indberetningssystem

Eksisterende Integrationer::FIE

Eksisterende Integrationer::Plansystem.dk


Skat, MBBL og SocialministerietEksisterende

Integrationer::Statens Arkiver

Grunddataprogram::Datafordeler

Grunddataprogram::CPR

Grunddataprogram::CVR

Grunddataprogram::DAR

Grunddataprogram::Ejerfortegnelsen

Grunddataprogram::Matriklen

NemLogin::STSNemLogin::FBRS

NemLogin::IdP

Adgangsstyring::STS

Adgangsstyring::Context Handler

Støttesystemer::DokumentBoks

Støttesystemer::KlassifikationRammearkitektur:

:Serv iceplatformen

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

Figure 11 - BBR system context



Figure 12 – DAR system context

The systems can be grouped into three major parts.

Grunddataprogrammet

Framework architecture (Rammearkitektur)

Existing Integrations

In the following sections the major parts is examined in the perspective of the System.

4.3.1 GrunddataprogrammetThe Datafordeler (DAF) is a central hub of all the system in Grunddataprogrammet. It exposes two types of services

Replicate of data: The datafordeler keeps a copy of all data in the authoritative registers. This is handled by exposing a service for synchronization and a service for querying the data.

Event notification: Distribute event notifications to the registers in Grunddataprogrammet when data has changed according to subscriptions set up in the Datafordeler.


cmp Grunddataprogram

Matriklen

DAR

CPR

Ejerfortegnelsen

CVR

Datafordeler Systemkontekst::BBR NemLogin::FBRS

NemLogin::IdP

NemLogin::STS

«use»

«use»

«use»«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»


Figure 13 – A logical perspective of the services exposed by the Datafordeler.

Figure 13 shows the logical perspective of the system in relation to DAF and other registers and other non-register consumers. Other authoritative registers are the systems part of the Basic Data Program that replicates data to DAF (BBR, DAR, MU, DAGI, EJF, EBR, GeoDK, CVR, CPR, etc.), while the “DAF consumer systems” are all other systems and users in the world that in any way use DAF for anything, but aren’t themselves Basic Data Program registers.

For a more detailed overview of the integrations with Grundataprogrammet and its various registers, see [D0180]. For details on the design of components handling DAF related integrations, see [DD130] chapter 1 and 2.

4.3.1.1 BBR

Figure 14 shows the context of BBR relative to other systems in grunddataprogrammet.

Figure 14 - BBR in context of Grunddataprogrammet

Data is accessed by the system from other registers via Datafordeler. Similarly, other systems may access the system, which may expose some of its data, through DAF. In addition to integration via DAF, DAR and Matriklen do also access one another directly without involvement of DAF. These are Ajourføringsservices (Mutual update services).



NemLog-in will be used for authentication and authorization of users and systems. More on this is described in section 8.2.

4.3.1.2 DAR

Figure 15 shows the context of BBR relative to other systems in grunddataprogrammet.

Figure 15

Data is accessed by the system from other registers via Datafordeler. Similarly, other systems may access the system, which may expose some of its data, through Datafordeler. There is, however, the exception of BBR and Matriklen, which will access DAR outside Datafordeler, and DAGI, which will access DAR outside Datafordeler. These are Ajourføringsservices (Mutual update services).

NemLog-in will be used for authentication and authorization of users and systems. More on this is described in section 8.2.

4.3.2 Framework architectureThis section describes the framework architecture and the services it exposes to the System. For a more detailed examination of integrations to the framework architecture, refer to [D0180].

4.3.2.1 BBR

BBR uses the services made available by the framework architecture, see in figure 16. The system is not an active part of the framework architecture for other systems, only as a user.



cmp Rammearkitektur

Grunddataprogram::BBR

Adgangsstyring::STS

Adgangsstyring::Context Handler

Serv iceplatform::DokumentBoks

Støttesystemer::Klassifikation

Støttesystemer::Beskedfordeler

«use»

«use»

«use»

«use»

«use»

Figure 15 - BBR in context of the framework architecture

4.3.2.2 DAR

DAR uses the services made available by the framework architecture, see in figure 17. The system is not an active part of the framework architecture for other systems, only as a user.

Figure 17

4.3.1 Existing IntegrationsThis section describes the existing integrations that are continued in the System. For a more detailed examination of existing integrations, refer to [D0180-B].

4.3.1.1 BBR

BBR 1.7 have a range of integrations to other systems. Not all these integrations have been continued in BBR 2.0. The continued integrations are shown in Figure 168.



cmp Eksisterende Integrationer

Danmarks Statistik

SKAT & UIBM

FIE

Certificeringscenter

Statens Arkiver

Plansystem.dk

Grunddataprogram::BBR

Eksternt Indberetningssystem

«use»

«use»

«use»

«use»

«use»

«use»

«use»

Figure 168 - BBR in context of Existing Integrations

As seen in 18 are most of the the external integrations outbound, and does therefore not require that services are made available for external parties. FIE and the external reporting system sends data to the system.

4.3.1.2 DAR

DAR 0.9 has a range of integrations to other systems. Not all these integrations have been continued in DAR 1.0. The continued integrations are shown in figure 19.



Figure 19 – DAR in context of Existing Integrations

As seen in Figure 169 most of the external integrations are outbound, and does therefore not require that services are made available for external parties. The external reporting system sends data to the system.

5 Process perspectiveThis section describes central processes of the system.

5.1 EventsEvents are messages in an Event-Driven Architecture. EDA is based on an asynchronous message-driven model of communication. EDA is like SOA an architecture that supports communication at an “enterprise” level. The advantages of EDA include, that it is a suitable architecture for supporting near real-time communication and updates via the opportunity to subscribe to relevant events (hændelser) across different processes. EDA allows information to be communicated across different processes, that takes place in different organizational entities and IT systems, in a way that supports loosely coupled processes through quick and efficient communication of relevant events. Data that is communicated through events can be utilized in multiple ways. It can be a prompt to fetch additional data which the messages is referring to, or it can be utilized by itself.

In order to support an Event driven architecture both the Datafordeler and Støttesystem Beskedfordeler is introduced as centralized distribution hubs. Datafordeler is for Grunddataprogrammet and Beskedfordeler is for Rammearkitekturen. They both use the same event structure. They both do the same, but for different systems. Therefore, this section will only cover Datafordeler.

Each system can publish events that other systems can subscribe to and each system can setup individual subscriptions to relevant events. There are two kinds of events (Hændelsesbeskeder), Forretningshændelser (business events) and Datanære Hændelser (data events). A business event is solely defined by the register and can be related to anything that occurs in the register. A data event is directly related to an update to a given datarow. There is no description of why this change occurred, but only that it occurred. A data-event contains an ID to the relevant datarow, and furthermore it can include the complete updated row. Currently all events in grunddataprogrammet only contains the ID. The data format of a general event in the Grunddataprogram is reviewed in section 5.1.3.1.

The overall infrastructure for events in Grunddataprogrammet is shown in Figure 17 and for the Fælleskommunale Rammearkitektur in Figure 18.

Figure 17 – Event infrastructure for the Basic Data Programme



Figure 18 – Event infrastructure for the Fælleskommunale Rammearkitektur

All received events are saved and processed by the System. This is covered in 5.1.2. Generating of events from the System is covered in 5.1.1.

5.1.1 Generating eventsDAF is responsible for creating data events when a register updates a record on DAF replica. Section 5.2 covers this, and the current section therefore will not cover the data events.

BBR and DAR, as well as the rest of the GD registers, only create/trigger data events and not business events. For this reason there is not gone into the mechanisms needed for handling business event, though concerning receival, it would be more or less identical to receiving data events.

5.1.2 Receiving eventsA hændelsesbesked can contain different types of data. The types are divided into business and data related events, where business describes business events in the external dedicated systems, and data event describe a reference to a changed row in the external source system. This section describes the processes for receiving events (hændelsesbesked).

It is essential that the System can support a high flow of events from Datafordeler and Beskedfordeler. In order to maintain speed, control and flexibility the receiving component of events uses a decoupled sequence from the processing component. The handling of events in the system must be handled in such a way that events can be received fast, and does not interrupt the rest of the system. This decoupling process is illustrated in Figure .



Figure 21 - Decoupled sequence between receipt and processing

The Service component receives event via PUSH and only persist the event in the Hændelsesdata-queue, returns an acknowledgement to the Datafordeler, and is now ready to receive another event. It is ensured that the acknowledgement of the receipt of the hændelsesbesked if only given after the data is persisted successfully in Hændelsesdata.

When the Service component receives the forretningshændelse as hændelsesbesked, it validates the sender and the event structure of the hændelsesbesked. When both are validated successfully the event is persisted. If any of the validations fail, the system returns an error message to the Datafordeler and is logged accordingly.The Hændelsesdata is a table in the data layer of the system (see section 4.1). When the event is persisted in the receiving process, the table Hændelsesdata is accessed. When new Hændelsesdata is created from a received event, there is no need for a concurrency control lock, as no other process is working on this new data and data is not related to each other. Multiple received events can be persisted with new data in Hændelsesdata at the same time.

5.1.3 Processing eventsWhen processing an event, it will be determined which use case functionality matches the type of event. Different events updates/handles different part of the System. Figure 23 shows the processing flow of events as a circular sequence.



Figure 2319 - Event processing

When multiple event processors operate on the same table (Hændelsesdata), the system must be managed to maintain consistency. This is done by locking the data, which it operates on, before the data is processed. This pattern prevents multiple processes to work on the same data source at the same time, and thus prevent data conflict when updating it. When the event processor is done, the data can be updated and the lock can be freed as illustrated on Figure .

Figure 24 - Hændelsesdata locking

Hændelsesdata must be locked pessimistically. Each event processor can only update and delete Hændelsesdata that it is sure it’s the only one to alter.

The fundamental lock mechanism on Hændelsesdata uses the stored procedure sp_getapplock (Transact-SQL) on the SQL Server. This is a safe, fast and reliable lock mechanism, which only locks the used data and is bound to the application resource object across all app servers.

5.1.3.1 Hændelsesbesked data format

The physical data model for a Hændelsesbesked is the same, whether it is caused by a Datanærhændelse or a Forretningshændelse. The current version is “Grunddata-besked version 1.0”3.

3 http://data.gov.dk/grunddatabesked/grunddatabesked.pdf


Get next event for

processing

Possible fetch data

from external

data source

Process event

Change event status


Figure 205 - A logical partition of the elements an event consists of.

The elements that are most interesting for BBR and DAR are listed and described in the following subsections, see [DLS] for details.

5.1.3.1.1 Filtreringsdata

The Filtreringsdata element is mandatory and contains the general data that is necessary to evaluate the event relative to the filtration expression in a subscription in the Datafordeler. It consists of some preset fields and any number of registered objects (Objektregistrering) affected by the event and any number of related objects (Relateret objekt) not affected by the event.



5.1.3.1.2 Objektregistrering

The Objektregistrering element is a reference to an element affected by the event. The event can omit a reference to an object if it is caused by a Forretningshændelse, and it can have a reference to more than one object affected by a Datanær hændelse.

5.1.3.1.3 Leveranceinformation

The Leveranceinformation is mandatory and contains the technical data about the event. Data contains information about the sender and its route from the sender to the latest receiver.

5.1.3.1.4 Beskeddata

The Beskeddata is optional and can contain individual and private data about the event additional to the preset fields. It contains a reference to a data scheme and the actual data. The data can either be an Objektreference, see section 5.1.3.1.2, or a Binary Large Object, i.e., a payload that contains data as described by the data scheme and any additional agreement between the sender and receiver.

Datafordeler cannot use the information in Beskeddata from subscription filtration expressions.

5.1.4 Error handlingDuring processing of events, there is no user interaction. If an error occurs, the system must be able to report the problem somewhere. The error is logged, like other errors in the system, regardless if the error occurred due to handling of an event or a user interaction. Furthermore, if an event cannot be processed, the event is put in a queue where a manual error handling can be done before retrying again.

The system has an administrative view where events that cannot be processed is gathered, see [D0160] for details. This view displays both received events from Datafordeler and events that cannot be delivered to Datafordeler. In this view, a System role administrator (see section 3) can click a button to make the system retry processing the event.

5.2 Replication to DatafordelerAs part of Grunddataprogrammet, the System replicates data to Datafordeler (DAF), which then shares this data with any system or person who requests it. In addition to other systems being able to retrieve System data from DAF, a system can also subscribe to certain types of events triggered by a change to System data.

Figure 216 shows the exchange of information in connection with changed data. The systems collaboration in the figure are the System, DAF, and other external systems – both subscribers and non-subscribers. The figure is followed by a description of each part of the process.

Figure 216 – Process for registering system data updates in DAF



The DAF data update process goes as follows, with additional information about the System’s integration to DAF in D0180 section 4.2.

A1: The System sends an update to DAF with the updated objects. One or more of these updated objects also contain information about whether the updated object is an indication of a new object, a changed object, or a deleted object4; this information is later used by DAF to generate hændelsesbeskeder. At this point the update is queued at DAF and waiting to be processed. Due to the asynchronous communication pattern, DAF only informs the System than the update has been received and not processed; the System has to request a receipt at a later point (A2) in order to know whether DAF was able to successfully process and save the update.

B: DAF processes the data update and saves the updated objects to the DAF database. After the data update is saved, a receipt for the update is ready to be retrieved by the System, indicating how the update went. Retrieval of the update receipt is not included in the figure.

A2: The System requests a receipt for whether DAF was able to successfully process and save the update.

C: After (B) will each updated object accompanied by an event type (“CreateEvent”, “UpdateEvent”, or “DeleteEvent”) create a hændelsesbesked. These hændelsesbeskeder are then pushed to other systems that have subscriptions for updates with the matching object type, event type, and possibly other filters as well. Objects that are not accompanied by an event type does not trigger hændelsesbeskeder.

D/E: At any time after the update has been processed and saved (B) – even before the hændelsesbeskeder have been distributed to subscribers – any other system, subscribed or not, can retrieve the updated object from DAF.

Through this process, System data is replicated to DAF wherefrom the data can be accessed and hændelsesbeskeder are sent out. More information about DAF and the integration between DAF and the System can be found in [D0180] section 4.2.

5.2.1 Informing DAF about scheduled downtimeThis section will describe the process of informing DAF about scheduled downtime. The service DeliveryDisturbance is used for this purpose. The technical details about the integration are described in [D0180].

According to the documentation of the service, DAF should be informed about downtimes, if the System deems it relevant for the users of the System’s data. Figure 227 shows the process of reporting a scheduled downtime to DAF. The process will be run manually by a Jenkins administrator when the System is known to be unavailable.

4 Note that this is a logical Create, Update or Delete. DAF will keep bitemporal data, which means that records physically are only inserted and updated, never deleted.



Figure 22 – The process of reporting a delivery disturbance to DAF

Details about the process is described below.

A: A Jenkins administrator is starting a parametrized build when a window of downtime of BBR is known in advance, e.g. before a deploy of the application. The build takes string parameters {“StartDateTime”, “EndDateTime”, “DescriptionCode”, “DisturbenceIdentifier”}, which are fed to a Windows batch job.

B: The Windows batch job takes the parameters and will make a request to DAF based on the following rules:

o If DirsturbenceIndentifier is set, it is parsed as an integer and a request to AlterDisturbance is made, otherwise a request to ReportDisturbance is made.

o StartDateTime and EndDateTime are parsed to DateTime objects. If the parse is successful they are formatted as UTC timestamps and send with the request, otherwise the job is terminated.

o If StartDateTime is not set the current time is used, and if EndDateTime is not set, the StartDateTime incremented with a set amount of time is used instead. The set amount of time should reflect how long the deployment of the application usually takes.

o If DescriptionCode is not set 1 is used.

C: The return values from the request is logged in the console. If a request to ReportDisturbance was made, then an integer DisturbenceIdentifier was returned, and this can be used by the administrator to alter the reported disturbance at a later time.

5.3 Processes related to caching5.3.1 Caching/copying data from other registers

5.3.1.1 In BBRIn order to search data from other registers and combine the results with data from BBR, the system needs a local cache to query. This is done for several DAR entities as well as MU Jordstykke. Read more about this register object caching/copying in [D0180-A] and [DD135].

To keep the local cached data up to date, the event-based mechanism is used.



sd Hændelser

DatafordelerSystemet DAR

Proces Event()

Entity Updated()

Read Entity()

Push Event()

Read event()

Update Entity()

Event Recieved()

Figure 238 - Data events from DAR

DAR updates Datafordeler with new information. Datafordeler publishes an event to BBR how then fetches the updated entity and updates the local cache using the new information.

Keeping data in sync between systems in Grunddataprogrammet also requires Ajourføringsservices. This is described in 4.3.1 and the technical information is in D0180.

5.3.1.2 In DARIn order to search data from other registers and combine the results with data from DAR, the system needs a local cache to query. This is done for several DAGI entities. Read more about this register object caching/copying in [DD135].

To keep the local cached data up to date, the event-based mechanism is used.

Figure 249 - Data events from DAGI



DAGI updates Datafordeler with new information. Datafordeler publishes an event to DAR who then fetches the updated entity and updates the local cache using the new information.

Keeping data in sync between systems in Grunddataprogrammet also requires Ajourføringsservices. This is described in 4.3.1 and the technical information is in D0180.

5.3.2 Caching for DAR search functionalityThe DAR type ahead search box searches for entities from multiple repositories at the same time, while showing results on the fly as the user types the query string. This requires a new lookup for every user input, which could put a big load on the backend server. The Elasticsearch5 engine, a distributed, RESTful search and analytics engine, is used to cache results from querying the relevant repositories and manage searching across multiple sources.

Only entities with attributes searchable from the search box are cached, as these are the ones the type ahead functionality is supporting. The entities that are currently supported

Adresse

Husnummer

ReserveretVejnavn

NavngivenVej

SupplerendeBynavn

Adresseopgave

Figure shows the process of searching for entities with Elastic search.

Figure 30 – Searching with Elastic Search

The Elastic Search service runs on the DAR Application server and is reached through the NEST ElasticClient. The client is used both when querying the service when the user types in a search, and when the cache is initialized or is updated.

A Jenkins job will initialize the database by running a Shell script that connects to the DAR Application server and runs the ElasticSearchCacher executable. In the production environment a batch job will initiate the executable.

5 https://www.elastic.co/products/elasticsearch



When an object that is cached by the Elasticsearch changes, the cached version need to be updated. This is done by implementing and using ElasticSearchManager alongside business managers that are responsible (via repositories) for saving objects in the DAR local database.

Figure 3131 shows an overview of the most important actors and classes relevant to caching entities from the Husnummer table.

Figure 31 – Actors and classes relevant for caching Husnummer

5.3.2.1 Initializing the cache

This section describes how the Elastic search cache is initialized. The same process is used when the cache is updated at a configurable interval to ensure that there are no outdated data in the cache.

Elastic Search has two indexes that are used for the caching and uses an alias to specify the one that is in use by the application. When the cache is to be updated, the index not in use is cleared and re-indexed with updated data. When the process is done, the alias of the two indexes are swapped. This



ensures that the Elastic Search service is still active during the initialization. Figure 32 shows the process of updating the Elastic Search cache.

Figure 32 – Initializing the Elastic Search cache

5.3.2.2 Maintaining the cache

When objects are created or changed in the DAR database the Elastic Search cache needs to be updated to present real-time data.

shows this process when e.g. the Husnummer is created or changed.

Figure 33 – Maintaining the Elastic Search cache after a DAR object change


HusnummerController Manager/Repository ElasticClientUser

Add/Update Husnummer

Add/Update Husnummer

return updated Husnummer

Insert/Update Husnummer document in cache in use

return success message

Update database

ElasticSearchManager

return update confirmationAlert ElasticSearchManager


A new or an updated version of a Husnummer model is posted to the HusnummerController. This data is sent to the HusnummerService and eventually to the manager to update the database. After the Husnummer entity is created or updated, it is translated to an Elastic search document and send it to the ElasticClient by ElasticSearchManager to either insert or update the index in Elastic Search. The Elastic Search index in use is updated to ensure real-time data for the search functionality.

When an object change in an external source and the Elastic Search cache needs to be updated, this happens via the same process. Figure 3434 shows an example of this, where a SupplerendeBynavn is changed in DAGI, and the local cache in DAR is updated from a data change event received from the Datafordeler.

Figure 34 - Maintaining the Elastic Search cache after an external object change

6 Implementation perspectiveThis chapter describes why the different software technologies were chosen and the layers of the different components.

6.1 Technical ArchitectureThis section covers the technical architecture in general. The following sections covers the individual parts of the solution in detail.



Figure 255 - Technical architecture

The solution is built on modern, public available and standardized technologies, all of which were chosen as the most optimal way to reach the business goals of the System.

a) ASP.NET MVC is responsible for the User Interface. ASP.NET MVC is optimal for a specialized and configurable user interface, creating a user-friendly and effective experience for the end-user.

b) Integration to other services is implemented using Windows Communication Foundation (WCF). External services likewise use WCF framework to host services for external users. WCF is also the framework for communication between frontend and application tier.

c) For accessing data in the data storage tier, the Entity Framework is used. A modern Object Relation Mapping framework developed by Microsoft.

d) The database engine is a Microsoft SQL Server Standard Edition. A reliable and scalable database engine, which supports the other parts of the architecture.

e) The system is running in Internet Information Server, which is included in Windows server 2012 R2.

f) Batch processes uses Windows Services as a platform. This is included in Windows Server.



Figure 266 - The technology stack

Implementation of the authentication protocol uses OIOSAML and OIOIDWS library that the Danish government has published.

6.2 Frontend TierThe Frontend Tier consists of two parts

Website - ASP.NET MVC application

Services – IIS WCF based Service Gateway

Because this is a website, the front-end is usable in the newest versions of modern Browsers, such as Microsoft Internet Explorer 11, Google Chrome, or Mozilla Firefox. For this reason, any SBC, VDI, and RDS environments from e.g. Citrix, Microsoft, or VMWare that are capable of presenting the user with such a web browser will be able to use the website in exactly the same way as a natively running system would.

In the event of a browser update, the system will be usable provided the browser does not deprecate open web standards in use when the system was deployed. This is considered an unlikely event.

Because the application is web based, the browser takes care of printing. This uses open standards. In other words: “if your office can print web pages, it can print this”.

A load balancer is used to distribute load between web servers with similar parts (Website or Services). The load balancer will use SSL offloading with sticky sessions to properly route requests. It will also use probes to verify if machines are operational and route traffic only to the ones that are.

The load balancer-based configuration of the Frontend Tier ensures scalability since servers for each part (Website and/or Services) can be upgraded, added or removed within the tier as required, without affecting other parts of the System.



6.2.1 Website

Figure 277 – MVC components and their implementation in BBR.



Figure 288 – MVC components and their implementation in DAR.

Microsoft ASP.NET MVC 5 is based on Model-View-Controller architecture pattern, ensures a clear separation of presentation layer (view), data (model) and business logic (controller).

6.2.1.1 ViewIn this layer are Views and Partial Views located. This is the presentation layer for the application. Views are complete screenshots shown to the users and can consist of one of more Partial Views. The ASP.NET MVC adhere to reusability in every layer, and this is the case for Views. A Partial View uses UserControl that can be used in many different Views. Since Views can consist of many Partial Views, this makes it possible reuse existing Partial Views in new Views. ASP.NET is built to handle many Views. Aside from adding reusability to the System, it also ensures that parts can easily be replaced without having an influence on performance.



Figure 299 – Views (Visning) are screenshots and Partial Views (Delvisning) are part of it.

6.2.1.2 Controller

Controllers handle the coupling between the presentation layer and the model layer containing data. A controller can e.g. handle validation of form-entries, handle external requests and most importantly, retrieve data that needs to be shown in the View in the presentation layer from the model layer.

6.2.1.3 Model

The integration layer in the model connects to the business logic in the application layer. A WCF service is used to make this integration. The purpose of the Model is to deliver the data that is shown in the View.

6.2.2 ServicesA Service Gateway (SGW) component will be used in both BBR and DAR to provide services to external systems. These external systems can generally be categorized as:

Grunddata register

o BBR: DAR, MU

o DAR: BBR, MU

Datafordeler

Eksternt indberetningssystem

Other, non-grunddata, external system

o BBR: FIE, OIS

o DAR: AWS, CPR

The SGW is deployed in the presentation tier (frontend zone) and communicates internally with application-tier services. An overview of the deployment and the application-tier service categories are illustrated in Figure . Further details are in section 6.2.2.2 and 6.2.2.3.



Figure 40 - SGW deployment

BBR and DAR will each deploy a SGW exposing gateway services to the external systems categorized above. The SGW will support services using the standard request-response pattern.

6.2.2.1 Request-response servicesIncoming service requests will be required to use a SGW endpoint. The SGW will then forward the request to the internal Application tier. The SGW will share data and service contracts with the application tier.

The SGW functionality for request-response pattern will be based on the ASP.NET WCF framework.

When processing service requests, the SGW handles authentication, e.g. validation of embedded security token, client certificate or client IP address. Similarly, the SGW separates the external communication protocol from the protocol used by the internal application tier services. Both SOAP and REST services (with XML or JSON payload data) are handled by the SGW.

6.2.2.1.1 Authentication workflow

When receiving a service request from an external system, SGW will verify the provided STS token or client certificate, submit a request to internal application tier and forward the response to the external system. The workflow is presented on the following diagram.

Figure 41 - Valid token

Likewise, if the provided security token or certificate is rejected, an appropriate error response is returned to the external system.



Figure 42 - Invalid token

6.2.2.2 BBR inbound integrations MU and DAR will access Ajourførings services. DAF will access Hændelses service and Data Sampling service. Eksternt Indberetningssystem will access Client services (services also used by Frontend). FIE and OIS will access “Other services”. The Service Gateway will provide external endpoints for all these services as illustrated in Figure .

Figure 43 - The external integrations to BBR

Refer to [D0180] for details about the published services.



6.2.2.3 DAR inbound integrationsMU and BBR will access Ajourførings services. DAF will access Hændelses service and Data Sampling service. Eksternt Indberetningssystem will access Client services (services also used by Frontend). AWS and CPR will access “Other services”. The Service Gateway will provide external endpoints for all these services as illustrated in Figure 44.

Figure 44 – The external integrations to DAR

Refer to [D0180] for details about the published services.

6.3 Application TierThe application tier implements the main core of business logic. This application exposed to the rest of the application by a number of WCF interfaces. This way the application tier controls exactly which part of the logic can be access by the frontend. The WCF interfaces cannot be exposed to the internet directly but must be exposed by a frontend tier.



Figure 30 – BBR & DAR application layer

As seen in Figure 30 he application layer consists of four loosely coupled components. This configuration gives a system that is robust towards changes and replacement of single components. The business logic layer is called by the model in the presentation layer and is responsible for upholding the business rules of the System.

Repositories are responsible for integration between business logic layer and integration layer/data layer with a 1:1 coupling between integrations and the external services. This coupling ensures the System against changes in the external services, since it is only the integration layer that have access to these services.

6.4 Data TierAs data tier, the system uses Microsoft SQL 2014 Standard edition in a cluster setup. The cluster is configured as an Active-passive failover cluster, a build-in clustering feature of SQL 2014.

The data tier stores both the entities in the system and the events that the system handles. The event handling is described in section 5.1.



6.5 Reporting ServicesReporting Services Report Server, a component of SQL Server 2014 Standard Edition, is used by the System to design, distribute and render reports to end-users. The rendering and distribution parts are client-server and web-based and provides seamless integration with the System Client. The report design functionality is based on a Windows desktop client application, Report Builder, and special care is needed to integrate this client in the System layered architecture.

Report Server is located a dedicated server in the Application Tier. In order to comply with the required 3-layered System architecture and security requirements, Reporting Services Report Viewer functionality in the Frontend Tier will proxy report request to Report Server, which will render the report and query the SQL database. Furthermore, Remote Desktop Services and its subcomponents are used to support remote access by report administrators to the Reporting Services Report Builder application.

6.5.1 Report dataThe database for reporting is placed in the Data Tier as described in section 6.4 on a separate SQL instance for reporting. Being placed on a separate SQL instance allows separate control of the resources (compute, memory) allocated for reporting by the database server.

Tables, views and user defined functions for reporting are replicated from the application database to the separate database used for reporting. Reports therefore works on the same data model as the rest of the system.

As described in section 8.2.5 report users will only have direct access to predefined views that will restrict the access to data and not the tables themselves.

6.5.1.1 Point in time (current) viewsViews that represent the current time valid data will be available for reports. These will be built on a layer of Table Valued User Defined Functions that operate/filter bitemporal data on a point in time. The views will filter away classified rows depending on the AD identity used to perform the query, see section 8.2.5 for details about report security.

Joins between the point-in-time views can be defined using the graphical Report Builder Query Designer.

6.5.1.2 Bitemporal (history) viewsViews with the full bitemporal history will be available for reports. The views will filter away classified rows depending on the AD identity used to perform the query, see section 8.2.5 for details about report security.

Data queries for reports that display historic data from a single bitemporal view can be defined using the graphical Report Builder Query Designer. Data queries for reports that require joins between bitemporal views will need to be defined using SQL syntax because of limitations in the graphical Query Designer.

6.5.2 Report renderingReports are rendered by Reporting Services Report Server which stores report definitions and configuration in Report Server specific databases in the SQL instance for reporting. Rendered reports are exposed to users via Report Viewer functionality placed in the Frontend Tier. The frontend web application code integrates with Report Viewer and ensures that Reporting Services uses the appropriate AD identity (and its resulting data access restrictions) when rendering reports.

6.5.3 Report authoringThe Report Builder application is placed on a single Remote Desktop server in the Backend Tier. The Report Builder is available to authorized users via Remote Desktop Gateway in the Frontend Tier.



The Report Builder Query Designer tool aids the report author in the definition of “virtual” datasets used by the report. For complex queries, such as bitemporal joins, the Query Designer tool is not adequate and such queries must be designed by the report author using standard SQL syntax.

6.5.4 Reporting architectureThe architecture is illustrated (in context of BBR, but similar for DAR) in the following figure.

Figure 317 - Reporting architecture in context of BBR

As depicted in the figure above, another endpoint (rd.bbr.dk) beside the Frontend website (kommune.bbr.dk) and Service Gateway (sgw.bbr.dk) are required for reports.

Marked with a green color in the diagram, the Report Viewer component in the Frontend website will use the Report Server SOAP API to render reports. The frontend website will integrate with Report Viewer to convert from token based identity to AD identity required by Reporting Services.

Marked with yellow/orange color in the diagram, the Remote Desktop Web Access page (rd.bbr.dk/rdweb) is hosted on the web server. When users have logged in here they can access Remote Desktop Gateway (rd.bbr.dk), also hosted on the web server, via Terminal Services Client. This allows logged-on users to effectively run the Report Builder tool inside the Application layer, thereby having access to both Report Server (which maintains report definitions) and Database data (the predefined views from section 6.5.1) as needed.



6.6 InRule rule engineBBR uses the inRule rule engine for business rule validation of domain objects (and their relations) on data changes. DAR will not use inRule.

InRule is a rule engine that allows to define and execute business rules against domain objects (entities). Rules are defined and maintained using a desktop application (irAuthor) and then persisted using the catalog service (irCatalog). The rules are executed on application servers in the Application layer by the embedded inRule rule execution engine that runs the rules in the same context as other business logic. The rule execution engine regularly pulls a fresh copy of the rule definitions from the catalog as necessary.

Rule definitions for development and test are kept and maintained in catalogs on the external test environment catalog service. After verification, rules are promoted to a separate catalog to be used on preproduction and production environments.

The catalog service can host multiple catalogs, and catalogs can be shared between development and test environments. The following catalogs are defined:

DEV: Development and internal test (shared)

EX: External test

P: Preproduction and production (verified and promoted rules)

The server file system is used to store rules for preproduction and production. The reason for this is twofold:

1. Production is not dependent on stability of the Catalog web service and database.

2. Deployment of rule definitions to production can be automated.

6.6.1 Rule definition accessThe following diagram provides an overview of how the rule engine in different environments will access the rule definitions.



The inRule Catalog Service will be accessible from the Internet (please see Security section for information on how the service will be secured) so that rule definitions can be modified by authorized users from SKAT using the irAuthor application.

6.6.2 Rule engine scalabilityThe rule engine architecture is vertically and horizontally scalable – application servers can be upgraded or/and added to the system to match load.

6.6.3 SecurityAccess to inRule Catalog service will be secured using following measures:

IP Filtering

inRule Catalog Authentication

6.6.3.1 IP Filtering

Only allowed IP addresses will be able to access Service Gateway. If a request will come from any other network, it will be denied.

6.6.3.2 inRule Catalog Authentication

inRule Catalog features a built-in user access control mechanism that not only allows to manage user accounts and privileges, but also tracks every change and allows “promotion” of rule sets – staging – between environments (if rules prove to be correct on TEST environment, they can be promoted to PREPROD environment etc.).

7 Deployment perspectiveThis chapter provides an overview on the deployment of the components in the System. Further details about the technical infrastructure can be found in [O0400].

All system components will be deployed to virtual machines hosted by Netcompany. The virtual machines will be duplicated to provide failover redundancy. The Remote Desktop host server, used while designing reports, will not be duplicated as this is not required for the Report Builder tool.

Component diagrams together with a description of the components are presented in the following sections.



7.1 BBR

Figure 51 - BBR Deployment perspective



Server Components

WFE

Frontend application Microsoft Remote Desktop Gateway Microsoft Remote Desktop Web Access Microsoft Report Viewer

WSE Service Gateway application

RDSH Microsoft Remote Desktop Session Host Microsoft Report Builder

APP Backend application Batch jobs (Batch job engine) Redis

SSRS Microsoft SQL Server Reporting Services

DB

Microsoft SQL Servero BBR DBo BBR Reporting DBo SSRS DBo InRule Catalog DB

AD Active Directory Controller

The technical infrastructure is described in detail in [O0400].

7.1.1 BBR 1.8 and BBR – External TestBBR 1.8 External Test environment is initially composed of only two BBR 1.8 specific servers and one AD server. To provide more flexibility, AD sever is shared between BBR External Test environment and BBR 1.8 External Test environment, they also share same domain.

BBR External Test environment perspective is the same as BBR 1.8.



Server Components

WFE

Frontend application Microsoft Report Viewer Service Gateway application B&D Service Gateway application Backend application Batch Jobs (+ Batch job engine) Redis Microsoft SQL Server Reporting Services InRule Service

DB

Microsoft SQL Servero BBR DBo InRule Catalog DBo BBR Reporting DBo SSRS DB

AD Active Directory Controller (shared for BBR 1.8 and 2.0)



7.2 DAR

Figure 52 - DAR Deployment perspective



Server Components

WFE

Frontend application Service Gateway application Microsoft Remote Desktop Gateway Microsoft Remote Desktop Web Access Microsoft Report Viewer

RDSH Microsoft Remote Desktop Session Host Microsoft Report Builder

APP

Backend application Batch jobs (Batch job engine) ElasticSearch Redis

SSRS Microsoft SQL Server Reporting Services

DB

Microsoft SQL Servero DAR DBo DAR Reporting DBo SSRS DB

AD Active Directory Controller

The technical infrastructure is described in detail in [O0400].

8 Security perspectiveThis chapter undergoes the security perspective of the solution. This includes securing the system against unauthorized access as well as authentication and authorization of users.

There is gone through the following security perspectives:

General security across the solution (8.1)

Authentication and authorization (8.2)

o SAML token federated login (8.2.1)

o Authentication (8.2.2)

SAML authentication in general (8.2.2.1)

End-user logon to the system client/site (8.2.2.2)

External system logon to the system services (8.2.2.3)

o Authorization (8.2.3)

BBR-specific authorization (8.2.3.1)

DAR-specific authorization (8.2.3.2)



Delegation of roles/“fuldmagter” (8.2.3.3)

o Role-based control of access to data and functionality (8.2.4)

o Security for Reporting Services (8.2.5)

Sensitive and protected data (8.3)

Contract security requirements (8.4)

8.1 Securing the solutionGiven that the client is web-based, it might be possible to navigate in the application by manually editing the URL in the client browser. The System prevents unauthorized access to any functionality or data belonging to any of its subsystems or applications by rigorously checking and enforcing permissions on any foreign request, including page and service requests.

Input parameters are validated in multiple layers before performing updates in the datastore. This makes it impossible to manipulate the application’s data by changing the URL, effectively making any form of data injection impossible.

The system is designed and built such that it minimizes the risk for unauthorized access or leak of sensitive information. The System is built on the following principles:

Separation of various components. This is ensured by having loosed coupled components with strictly predefined interfaces with only the necessary data included. These are executed independently of one another and only share data when necessary for functionality.

Running processes with the fewest possible privileges – The System will be run using the webserver Internet Information Services (IIS). In IIS the System is itself split up into multiple different components, each of which are run in their own application pool. This means that if one process is compromised, it does not automatically compromise the entire System since the processes run isolated from each other, so even if one process is comprised this does not give access to other processes. The System is designed to be run in the context of an application pool identity which is only given the minimal set of rights needed to run it.

No unnecessary connections – A firewall is established in the operating environment that assign every subsystem their own zone (VLAN). Every single subsystem thus has a separate front-end, back-end and database zones. All connections between the zones are blocked by the firewall excepting the connections specifically opened so that the different layers may communicate.

Minimal access to information about the System’s internal structure and functionality – The System is designed such that HTTP headers and other outside communication only gives precisely enough information for the receiving end to be able to react specifically to that type of communication and nothing more. The System will never unnecessarily expose information such as the database connection string, the IP’s of other servers in the System, and so on. Internet Information Services will be configured in such a way that no information is given about which version is being used. Likewise, JavaScript, HTML code, etc. will be cleaned of developer comments, SQL code, test/debug code, or any other information which would give an intruder any insight into how the system is constructed.

The System is placed in the operating environment behind a firewall. This firewall ensures that only relevant ports are open to the System. The firewall is configured such that only a few explicitly allowed connections are allowed – both in-bound and out-bound. The servers and environments upon which the System run are entirely dedicated to the System.

The client uses session cookies to keep track of browser sessions. Session ID’s in the System are based upon session cookies generated by ASP.NET. Session cookies are randomly generated and have a length of 120 bits. In practice this means that they are very difficult to guess, which prevents that a session can be hijacked.



Furthermore, the ASP.NET platform’s session cookie management is configured to “secure” and “HttpOnly” to protect against Cross Site Scripting (XSS) attacks and to ensure that session cookies are all sent via HTTPS. All session related traffic between server and client uses the HTTPS protocol. Assuming the encryption is strong enough, this will prevent a variety of attacks both on users and on the System itself.

To address whether the encryption is strong enough, Datatilsynet and NIST have a set of guidelines for strong encryption. They recommend either a 3DES or AES algorithm with a key of at least 128 bit. These are standard in the .NET platform and a very widely used.

Communication between the System and any outside services, including exposing the user interface, will use HTTPS. SSL/TLS and SSH connections are designed to ensure the integrity and confidentiality of the service call and all relevant data in transit. The System will ensure, by validating the partner’s public keys, that the user system and the service provider mutually authenticate one another.

In practice, the System will be set to use TLS v1.2 and no other transport layer encryption by default, because it is considered entirely secure. Enabling an older version of TLS or SSL is not recommended, even if it is supported. This particularly applies to TLS v1.0/SSL v3.0, as that configuration is vulnerable to a well-known attack known as POODLE.

Establishing a connection to another service will also comply with the security requirements set by the service provider. This complies with the regulations set by the “fælleskommunale sikkerhedsmodel” security model.

8.2 Authentication and authorizationThis section first describes the authorization model for the System (roles and privileges, data scopes etc.) and then how authentication and access control according to the authorization model is performed.

The authorization and authentication mentioned here only applies to claims-based access to the system through SAML tokens. This covers

1. End-user access to the client

2. External system access to services exposed by the System

a. System ajourføringsservices in Grunddataprogrammet

b. System Service Gateway for Eksternt indberetningssystem

3. System access from the System to external systems in Grunddataprogrammet as well as Den Fælleskommunale infrastruktur

The remaining integrations (Datafordeler and all existing integrations) use individual and non-claims based authentication mechanisms that do not include roles, data scopes or other authorization information, based on

OWSA Model T6

Username/password (only used by external provided services)

IP whitelisting

Public accessible, non-secured (only used by external provided services)

Authentication for each of these will be described in [D0180] under the specific integration, and each integration will be tailor-made to provide exactly the access required for the individual external system. Some of these systems may rely on the security model described here in the respect that they

6 https://digitaliser.dk/resource/4349



use a system-specific security role to access the System backend – such details will be described in [D0180].

8.2.1 Federated login through SAML tokensThe system uses federated login through SAML tokens for both end-user login and system-user login (ingoing as well as outgoing).

The SAML tokens can be issued from two sources, depending on where the end-user or system-user resides:

1. NemLog-In (including NemLog-In IdP, NemLog-In STS and NemLog-In FBRS):

Used for all authentication and authorization of users and systems in government authorities (myndigheder) and municipalities that uses NemLog-In as well as for private citizens and companies that interact with the system through Eksternt Indberetningssystem.

The NemLog-In system is running in production and the System does not require any changes to that system other than configuration of new end-points, role definitions and system users.

2. Access Control in Den Fælleskommunale Rammearkitektur (including Context Handler IdP, STS and Administrationsmodul)

Used for all authentication and authorization of users and systems in the municipalities, whether they interact directly with the System Client or through Eksternt Indberetningssystem.

The System will require the Adgangstyring STS to be extended with support for “identity based web service authentication” in order to be used for Eksternt Indberetningssystem.

Figure 53: Illustration of how the System uses two different Identity Providers for login

The actual SAML 2.0 login process for end-users and systems is described in section 8.2.2.

For both NemLog-in and Adgangsstyring the System integrates with three subsystems:

NemLog-In FBRS / Access Control Administrationsmodul:

o These are browser-based administration modules where roles for the System are defined, both roles for the System client as well as roles for Eksternt



Indberetningssystem/Service Gateway and roles for system integration with Grunddataprogrammet.

o The modules also allow the individual municipalities and public authorities to assign System roles to user groups and users as well as delegating roles to users in other organizations.

o There is no direct integration with these modules, but the System role administrators can download role lists from the System client and manually update the role definitions in the two administration modules based on this.

NemLog-In IdP / Access Control Context Handler with federated IdP:

o The actual Identity Providers that handles end-user logon and supplies claims based OIOSAML tokens that include end-user’s assigned System roles, delegated roles and ”fuldmagter”. The System client uses this token to determine roles and data scopes as part of the logon process.

NemLog-in Security Token Service / Access Control Security Token Service:

o Handles system-to-system logon (web services) via claims based OIOSAML tokens, again including assigned System roles so that the System services can use this token to determine roles and data scopes for the service call.

Figure 54 – System roles and rights handling in relation to the Basic Data Program

Details on the concrete mappings between roles and rights can be found in [DD135].

8.2.2 AuthenticationThis section describes how the System authenticates both end-users and system users when accessing:



a) The System UI Client

b) The System Services

1. System Ajourføringsservices

2. System Service Gateway for “Eksternt Indberetningssystem”

c) When the System authenticates when accessing external services protected by SAML tokens

The authorization model is explained in section 8.2.3.

8.2.2.1 General SAML authentication

There is no anonymous access to the System UI Client, the System Ajourføringsservices or the System Service Gateway. In all three cases, access is only granted when end-users or system-users present a valid SAML token to the System – how this is done through Identity Providers and STS’s is described in the following sections.

Both the Context Handler IdP and NemLog-In IdP, and their corresponding STS’s, follow the Danish OIOSAML specification for SAML 2.0 tokens, and they will both deliver user information as well as authorization information in the SAML token, including roles, scopes on roles and delegated roles (“fuldmagt”). This means there is no need for SAML Attribute Queries and no direct integration calls to the Identity Providers when receiving or validating a token.

Only tokens signed digitally with certificates from either Context Handler IdP, NemLog-In Idp or their corresponding STS’s are accepted by the system. Technically the System will contain a “white-list” of approved Identity Providers and STS’s that are accepted to use, so that it will be possible to add future SAML 2.0 logon providers.

Validation of signatures, certificates, tokens, and so on means the following controls must be carried out:

Verification of a cryptographic hash (a signature) by recalculating it on the data. This ensures data received has not been changed between signing and arrival.

Verification of the trust chain for the certificate which has been used to generate the verified signature. Whether the certificate is issued by a trustworthy Certification Authority (CA) is also checked.

Verification that the certificate used to generate the signature is valid, i.e. that the time of signing is not after the certificate has expired or before it was to be taken in use.

Verification that the certificate used to generate the signature is valid for the purpose of the transaction being carried out. For example, a regular SSL certificate cannot be used to sign other certificates.

Verification that the certificate used is not blocked by checking the block list. This verification can be carried out by checking DanID’s block list.

Whether or not to trust the certificates used is managed by Microsoft Certificate Store, which is an integrated part of Windows and can be used in the .NET platform.

Local certificates from the Context Handler and Security Token Service are stored, alongside private keys, in the system’s Microsoft Certificate Store. It will only be possible for verified administrative operations personnel to change this Certificate Store, and only the System’s own components will have read access to this data, so that these components can ascertain the validity of the tokens given to it within the framework architecture.



To the extent that local copies of metadata can be stored in the filesystem or databases, this will likewise happen in areas of the system that can only be accessed by verified administrative operations personnel. Here, too, the System’s own components have explicitly given read access.

Upon receiving a security token the System will validate that the token has the level of assurance required to achieve access to the System. SAML’s use of assurance levels are based on NIST 800-63, which defines the levels 1 through 4, where 1 is weakest and 4 is strongest.

The required level of assurance will be determined according to the business needs and in accordance with “Den fællesoffentlige referenceramme for autenticitetssikring”. By default, the required level of assurance will be set to 3 for all external interfaces unless something else has been explicitly requested. This means that there will be a secure authentication mechanism as well as transport layer encryption in use.

8.2.2.2 End-user logon to System client

As already mentioned, end-user logon to the System client is done through SAML 2.0 SSO and users can choose between two Identity Providers (IdP):

1. NemLog-In IdP

2. Context Handler in Den Fælleskommunale Rammearkitektur

To support the use of SAML 2.0 login the System will use the OIO-SAML.NET component, which is maintained by Digitaliseringsstyrelsen. All user tokens used in the system will be handled in accordance with the OIOSAML profile version 2.0.9 (OIOSSO). This includes the requirements on the topic of content, which is described in OIOSSO section 7.1 and 7.2, which will be enforced. The “OCES attribute profile” and “Persistent Pseudonym Attribute Profile” (OIOSSO chapter 8 and 9) will not be supported for login via the Context Handler. KOMBIT’s attribute profile will be used instead.

The subject element in SAML Assertions uniquely identify the user as a member of an authority. The element is parsed in accordance with the guidelines given by KOMBIT. That is, the element is expected to contain a NameID element encoded as an X.509 Distinguished Name with the elements:

Country (C) – ISO country code

Organization (O) – CVR number for the authority context the token was provided by.

Common Name (CN) – The name of the employee.

Serial element – an ID (text string) which uniquely identifies the employee in the authority.

The format attribute of the NameID element is given as urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName. The elements in Subject DN are separated by a comma and does not have a white-space between the elements.

Upon logging into the user interface the user will be asked which Identity Provided (IdP) the user wishes to use. The possible choices are given by a list. The user can also check a checkbox to mark that the choice of IdP should be remembered for future login. When this checkbox is checked, the chosen IdP will be saved in a cookie on the user’s unit provided it is permitted by the user’s browser. If the user’s browser blocks cookies the choice of IdP will only apply to the current session.

8.2.2.2.1 Logon with NemLog-In

Figure 55 illustrates the login process for NemLog-in.

Assigning user system roles (privileges) happens in NemLog-in’s common user rights management system, FBRS. IdP will, when creating a token, fetch a list from FBRS with the assigned privileges for the current user. This information is then included in the created token, which will be used for authorization of the user by the System.



Figure 55: Logon using NemLog-In FBRS

8.2.2.2.2 Logon with Context Handler

The cooperation between the System, the Context Handler, and the authority’s Identity Provider and User catalogue is described in figure 56.

Figure 326: Access control for the System Client

1. The user attempts to access the System client using their browser, but they do not have a token and therefore cannot immediately gain access to the System.

2. The System client automatically requests a token for the user from the Context Handler.

3. The Context Handler decides which Identity Provider the Authority is using.

4. The user authenticates himself with the authority’s Identity provider. This will usually happen automatically via Single Sign-On if the authority’s environment supports it.

5. When the user is validated by the Identity Provider, the Identity Provider will ask the User Catalogue for the relevant job function roles for the authority. The user catalogue returns the job function roles which are assigned to the user.



6. The Identity Provider issues a token to the Context Handler with the user’s identity and job function roles.

7. The Context Handler exchanges, with the help of “Støttesystem Administrationsmodul”, the user’s job function roles to system roles, including data access restrictions (= the municipality’s CVR number) for the System. If the user has any assigned roles from another municipality, then these roles are sent alongside municipality’s CVR number as a data access restriction.

8. The Context Handler issues a new token to the System client along with the user’s identity, system roles, and data access restrictions.

9. A session is established. The System will enforce the rights in accordance with the system roles and data access restrictions given in the issued token.

By using the Context Handler, it is ensured that any user from the municipalities can use Single Sign On with the system in the same way they do with every other system in the frame architecture. Login is therefore only necessary exactly once via the authority’s Identity Provider. In most cases it will happen automatically when the user logs in to their PC.

8.2.2.2.3 Session management

The session management of the System is based on ASP.NET Session State and Forms Authentication. These are standard technologies on the Microsoft platform. The combination of the two technologies give a robust, scalable, and secure session management system.

ASP.NET Session State and Forms Authentication supports cryptographically secured sessions with configurable lifespan as well as session expiry after a configurable time period of inactivity. The configurable time period can be adjusted to support a different timeout depending on the authority.

The System uses OIOSAML.Net for federation with the Context Handler and therefore appears as a service provider in accordance with the SAML AuthnRequest and SingleLogout profiles.

Sessions time out per the system wide timeout setting sat in the configuration file. This configuration can be changed during a service windows and changing it will result in all active sessions being closed, thereby making all new sessions follow the new timeout setting.

8.2.2.2.4 Logout

The System can both receive and send Logout requests as per the Single-Logout profile. As such, it can be both an initiating or non-initiating part of logging out. For receiving Logout requests from the Context Handler or NemLog-in IdP a SOAP based SAML endpoint will be set up.

The user interface in the System Client has a logout button. This button will be easily accessible from all areas within the application. The user can log out of the System and initiate an SAML Single Logout (sending a LogoutRequest) by clicking on the “log out” button. This system is part of a service oriented architecture, and the user’s interaction with the system may include that the session has been through a multitude of different systems.

Therefore, in order to log the user out entirely of their session across all the systems they were using, the System client must send a LogoutRequest to all other systems, notifying them that the session has been terminated, which in turn allows all involved systems the possibility to terminate the session amicably.

8.2.2.2.5 Report Builder authentication

Access to the subsystems facing web users is granted solely on the basis of the received token. For access to the Reporting Services Report Builder application, temporary personal Active Directory logins are created “just-in-time”, i.e. they are created or enabled for the actual session on request and are disabled again after a short period of validity.



The Report Builder application does not participate in the SAML based logout (or login) and users need to log in/out of a Report Builder (Remote Desktop) session explicitly. See section 8.2.5 for further details.

8.2.2.3 External system logon to System Services

External systems can access the System through two WS-Trust SAML token-based service end-points:

1. System ajourføringsservices (Grunddataprogrammet): API specifically designed for Grunddataprogrammet.

a. Login is performed through NemLog-In STS with system-users.

2. System Service Gateway, used by “Eksternt indberetningssystem”: Generic API to be used by external applications in general.

a. Login can be performed both through NemLog-In STS and through the STS within Adgangsstyring in Den Fælleskommunale Rammearkitektur.

b. In both cases the identity based web service model is used where the external system obtains a token from the STS on behalf of the end-user who uses his own roles and scopes to access the Service Gateway.

No systems in Den Fælleskommunale Ramme-arkitektur integrate directly with the system.

The System uses the WCF platform’s support of WS-Trust in order to support receiving SAML.

8.2.2.3.1 System ajourføringsservices (Grunddataprogrammet)

Other systems in Grundataprogrammer can log on the System’s services by first fetching a security token from Grundataprogrammets Security Token Service (NemLog-in STS) in order to gain system access, after which access to the System can be granted using said token, as illustrated on Figure 57.

Figure 33: Login for systemer i Grunddataprogrammet

Systems in Grunddataprogrammet will always be coupled with an authority through its authority’s CVR entry, and will therefore not have any of the data access restrictions that normally only to municipalities.

Role assignment for system access is administrated via NemLog-in’s user rights management where system users will be set up for web service access.



8.2.2.3.2 System Service Gateway, used by “Eksternt indberetningssystem”

The systems that need to create or update data in the System can integrate with the System and work as an “Externt indberetningssystem” which then communicates with the System through a System Service Gateway (a webservice interface) as illustrated on Figure 34.

Access (arrow 4) to the System Service Gateway from such an Externt indberetningssystem can happen on behalf of a user (arrow 1). The access control will depend on whether the user acts on behalf of a municipality (arrow 2b) or not (arrow 2a). Either way, tokens issued by the Security Token Service (STS) will in that case be used to enforce the rights given to the user. The main difference between the two situations is that, for users from a municipality, the Fælleskommune Rammearkitektur STS is used (arrow 2b), but otherwise NemLog-in’s STS is used (arrow 2a). It is also possible to invoke the services using rights granted to the calling system rather than a user.

Figure 34: Login for Eksternt indberetningssystem

Please note that Den Fælleskommunale Rammearkitektur’s STS does not support the identity based web services at this time. In other words, it is not possible via STS to have a token issued on behalf of the user that is logged in. That functionality has been marked as a wish to expand Den Fælleskommunale Rammearkitektur. Only when this functionality is implemented will users working for municipalities be able to use their login from Den Fælleskommunale Rammearkitekturs Adgangsstyring for Eksterns indberetningssystem. In the meantime, they can only use NemLog-In just like other authorities, companies, and citizens.

For Eksternt indberetningssystem the following are supported: NemLog-In Erhvervsfuldmagt, municipal delegation, and private delegated roles on the behalf of citizens.

In all three cases STS will have issued a token to the System Service Gateway on behalf of the user that logged on. From the token it will be possible to determine assigned private or organization delegated roles in NemLog-In as well as any municipal delegations for municipals. Organization delegated roles will be scoped using the given CVR number for the organization that issued the delegated roles while personal delated roles will be scoped using the given CPR number that issued the delegated roles.

Technically the identity based model for NemLog-In STS has a small inconvenience in this case, because the Eksterne indberetningssystem in step 3 receives a token to the System Service Gateway



which is encrypted. This means that the Eksterne Indberetningssystem cannot determine which roles the end user has in the system nor can it determine what delated roles the person can make use of as a direct result.

To solve this problem the System Service Gateway will make a service available which Eksternt indberetningssystem can call so that it may find out the user’s roles and delegated roles. Eksternt indberetningssystem can ask the user to choose delegated roles and then update its user interface to reflect the user’s real options in the System. All services will also allow setting who Ekstern indberetning is acting on behalf of (if the user has chosen to use delegated roles) and the System Service Gateway will thus both verify that the user has these delegated roles in their token and also log both who has made the change and who the change was made on behalf of.

8.2.2.4 System (BBR/DAR) logon on to external services

The System obtains SAML tokens for WS-Trust logon when calling registers in Grunddataprogrammet as well as SF1600/Dokumentboks in Den Fælleskommunale Rammearkitektur.

When calling external services in Grunddataprogrammet, the NemLog-In STS is used to provide a system user token for login to external services.

When calling external services in Den Fælleskommunale Rammearkitektur, the Adgangsstyring STS within Den Fælleskommunale Rammearkitektur is used to provide a system user token for login to external services.

The System uses Digitaliseringsstyrelsens OIOIDWS.NET implementation in order to have SAML Security Tokens from STS issued to it ahead of calling services with access restrictions (with the help of a RequestSecurityToken message in accordance to the OIO WS-Trust profile). Besides this, the system makes sure to cache these SAML Security Tokens (and automatically renew them as they expure) such that every single service call does not require a new security token to be used.

Call to STS are signed with the OCES certificate required by the agreed upon in the service agreement. The certificate is specific for the System and therefore authenticates the System to the service provider. The certificate is kept in the Windows Certificate Store on the servers that the System run on. Only the relevant service accounts are assigned access to the certificate’s private key.

The issue of the used service is authenticated via the service provider’s host/domain certificate. This certificate is assumed valid and registered in Støttesystem Adgangsstyring.

All service tokens used in the System will be handled in compliance with “OIO Profile for Identity Tokens” and Liberty Basic SOAP binding.

8.2.3 Authorization modelThe authorization models used in BBR and DAR are described in this chapter.

8.2.3.1 Authorization in BBR

End-users and system-users are granted access to the System data according to the following dimensions:

1. Roles (systemroller):

Roles are defined within the System and each role will provide a specific set of permissions (none, read, read-write) on entity fields within the System.

Users are assigned a set of roles by local user administrators, either locally for municipalities through Adgangsstyring or through NemLog-in FBRS for other public authorities as well as private companies.

2. Data scopes:



Data scopes are used to further limit access to data objects, based on where the user (or his delegated access) originates from:

i. Government authority scope (Myndighed): Users have access to System data across all Municipalities

ii. Municipality scope (Kommune): Users from a Municipality can access data only within their own Municipality

iii. Owner scope (CVR/CPR): Private companies and citizens. No filtering in data.

3. Classified data:

Some types of objects in BBR can be marked as protected (“sikkerhedsklassificeret”), which means that the object attributes are masked according to the attribute “K”-value and whether the user has access to protected data.

In integrations and exports to external systems, except exports to State Archives, attributes on protected objects are masked according to the attribute “K”-value.

End-users and system-users are assigned a set of roles (in either NemLog-In FBRS or Adgangsstyring Administrationsmodul depending on where the user originates), and the corresponding CRUD privileges then apply to the system according to the data scope of the user (determined by where the user originates).

For system-users, classified objects fields are always masked. For end-users, the masking of classified objects depends on whether the end-user has access to protected data.

The various types of authorization are depicted in the figure below.

Figure 35 – Authorization model with CRUD privileges to objects and fields mixed with data scopes (and security classifications)

End-users furthermore have the option of using delegated roles (“fuldmagt”) within NemLog-In or through the context selector in Adgangsstyring. This means that a role from a Government authority, Municipality or even private company or citizen can be given to another user from a different organization – allowing them to access the System on their behalf. When logging in, the user will then have to choose whether to log in as himself or on behalf of the delegated access. If delegated access is chosen, the user will get access according to the delegated roles and the data scope of the delegation. Access to classified objects during delegated access requires specific security approval of the end-user in the system, in context of the delegation origin.



8.2.3.1.1 Roles and privileges

As mentioned above, security within the System is based on a set of roles (“systemroller”) that each map to a set of CRUD privileges on the System objects and fields. This is exposed in an administrative UI for role definitions, where roles can be created, updated and deleted and where the mapping to CRUD privileges on objects and fields is maintained. In Figure 36 is shown how the mapping between role and field permissions worked on BBR 1.7.

Figure 36 – Excerpt of the role <-> field permission mapping from BBR 1.7

The initial role/field permission matrices were created by Netcompany in cooperation with KOMBIT, based on the corresponding matrices from BBR 1.7. If user has multiple roles assigned, privileges are merged in additive manner.

Note, that modifying the CRUD privileges of a given role can affect UI, use cases and system integration, as you can potentially remove privileges that are required for the system code to function, which will then cause the user interface to fail for the users. The recommended approach will be to test all role/CRUD privilege modifications in test environments and deploy them to production in a controlled manner.

The roles are exposed one-to-one into Adgangsstyring Administrationsmodul and NemLog-In FBRS so that the local user administrators in Municipalities and Government Authorities can assign the roles to their users:

a) In Adgangsstyring Administrationsmodul only roles relevant to municipalities will be exposed

b) In NemLog-In FBRS both roles relevant to Municipalities and Government Authorities will be exposed.

o The roles are primarily relevant to Government Authorities, but Municipalities may decide to use NemLog-In some of their users or may want to delegate roles to Government Authorities or employees in private companies.

o Note, that this will not be a security risk as roles are only applied according to the data scope of the end-user’s organization, so a user from a municipality will have an empty data scope on any role designed only for Government Authorities.

Role assignment is done by:



a) Adgangsstyring Administrationsmodul: The System roles are mapped to “jobfunktionsroller” which are used in the everyday user administration of a given Municipality.

b) NemLog-In FBRS: The roles can either be assigned directly to the end-users or assigned through user groups.

Ownership related roles designated for private companies and citizens will be kept internal in the System and are not handled via Adgangsstyring or NemLog-In. Note, that exposing the general roles to private companies and citizens is not a security risk as they are only applied according to the data scope of the end-user’s organization. However, the presence of the general roles would likely confuse the private companies.

Technically, the System roles (”systemroller”) cannot be digitally transferred into neither Adgangsstyring Administrationsportal or NemLog-In FBRS as this is not supported by the two platforms. The System role administration UI will therefore provide export of roles to Excel-readable CSV, but it is a manual task to transfer these roles into Adgangsstyring Administrationsportal and NemLog-In FBRS whenever roles are added, removed or change names. Note, that modifying the CRUD privilege mapping of a role has no impact on Adgangsstyring Administrationsportal and NemLog-In FBRS and does not require any synchronization.

8.2.3.1.2 Data scopes

As described above, user administration is delegated to the individual municipalities, government authorities and private companies, and role assignment is therefore performed locally by each organizations local user administrator.

To ensure that users cannot access data that their organization is not entitled to, the System uses data scopes to specify the kind of role.

When administrating the role definitions (“systemroller”) inside the System, each role must be marked with a type of data scope:

1. Government Authority scope (Myndighed): Requires the user to come from a Government Authority (CVR) with access to the System.

The user will get the role’s associated field permissions across all Municipalities.

2. Municipality scope (Kommune): Requires the user to come from a Municipality (CVR). Can contain both a local and a national field permissions set:

Local: The user will get the associated field permissions, but only on entities related to the specific Municipality ID (Kommunenummer).

National: The user will get the associated field permissions across all Municipalities. This is used to provide certain read-only access across all System data to municipality users.

3. Owner scope: Only applicable via service-based access to the system. Requires the user to come from a private company (CVR) or to be a private citizen (CPR). Users that does not belong to the first two types of data scopes will be assigned all defined roles with the owner scope type. Contains a national field permissions set:

National: The user will get the associated CRUD privileges across all of the System. This is used to provide certain read-only access across all System data.

To determine whether an end-user or system-user comes from a Municipality or a Government Authority with access to the System, the System contains a CVR list that can be administered from the role administration UI. On this list, the role administrator can insert, update and delete CVR entries, and for each one mark if it represents either a Government Authority with access to the System or a Municipality, in which case the Municipality ID (kommunenummer) must be entered. This list enables



the System to map an incoming user token to the three data scopes above (as all employee logins contain a CVR in their token).

If a user is assigned a role that is not marked with his type of data scope, the CRUD privileges will not apply to any entities, i.e. the role will not provide any access at all. This would be the case if e.g.

a) A System role is created only for government authorities, but a Municipality decides to assign to an employee in NemLog-In FBRS (the role would not be available in Adgangsstyring Administrationsportal, but the Municipality could choose to log in through NemLog-In instead).

b) A System role is created for government authorities and/or municipalities and a private company decides to assign it to an employee in NemLog-In FBRS.

As data scopes are determined exclusively by looking at CVR numbers, the system will not use lookups into Støttesystem Organisation within Den Fælleskommunale Rammearkitektur.

8.2.3.1.3 Classified/protected data

BBR contains data about buildings and other entities that are considered protected. Each attribute on protected objects are masked depending on the user’s access to protected data. Entities that can be protected have a security flag in the Logical Data Model (D0130), which can be either true or false, depending on the object classification (protected or not).

To end-users without access to protected data, and to external integrations, the attributes of protected objects are masked according to K-value in lookups, queries, updates, reports etc.

A user has access to protected data if either

the user is member of the FBE role, or

the user is member the “Registerfører” role and marked as approved for protected data

In order to be marked as approved by an administrator, the user needs to log in to the BBR client at least once beforehand. See more about this in [D0160].

To keep a tight control of approval and access to protected data, the list of approved users are kept inside BBR, rather than relying on the delegated, local user administration in NemLog-In and Adgangsstyring. This was decided to prevent local administrators approving users by mistake and to be able to extract the list centrally from BBR.

Approved users can only use NemLog-In to access unmasked protected data, and they will be identified by their CVR + RID on the list of approved users (but name and e-mail will also be shown on the list). The process of adding a user to the list will be similar to ”erhvervsfuldmagt på personniveau” in NemLog-In FBRS (LINK). It will be necessary for the user to have already accessed the BBR client in order for BBR to search for the user and validate the CVR + RID combination. Therefore, details (CVR, RID, name, email if available) of logged-in users will be stored in the BBR database in order to provide the data for the CVR + RID validation.

Security-approval does not change the way the other dimensions of the authorization model work – the security filter is simply applied to the query, lookup, report etc. before applying roles, field permissions and data scopes.

Fields on protected objects are handled similarly to the BBR 1.7 model, where all fields in the Logical Data Model are classified with ”K”-values.

“K”-value Read/write (user) Read (user) System to system integration/exports7

K1 Users with access to protected data access

Field is masked Field is masked

7 Except State Archives, where no masking of protected data is performed


https://hjaelp.virk.dk/sites/default/files/giv_en_erhvervsfuldmagt_paa_personniveau.pdf



Field is masked Field is masked


Field is not masked

Field is not masked

In practice, this means that the following applies for fields on protected objects:

1. FBE role and approved “Registerfører” role users can read/write fields with K1. For other users and integration/exports, the field value is blank/masked and blocked for update.

2. FBE role and approved “Registerfører” role users can read/write fields with K2. For other users and integration/exports, the field value is blank/masked and blocked for update.

3. Fields with K3 can be read/write by FBE role and approved “Registerfører” role users. For other users, the field value is visible but always blocked for update. For integration/exports, the field value is visible.

Energy consumption data related to a protected BBR entity (either Grund, Bygning, Enhed or TekniskAnlæg) are marked as protected when stored by BBR.

8.2.3.1.4 Permissions

Each role can have multiple permissions associated concerning scope (Local – within user’s kommune, National – outside user’s kommune). Permissions are used to limit access to specific functionalities (in both the application and frontend tier). If user has multiple roles assigned, permissions are merged in additive manner.

8.2.3.1.5 Authorization model overview

The diagram below illustrates the relationships between roles, privileges, scopes and the runtime user identity as described in the previous sections.



Figure 61 - Relationship between user identity, roles, privileges and fields in BBR

The resulting privilege on a field in a BBR data entity is calculated based on the user’s roles and scope. The privilege calculation is additive, implying that the maximum asserted privilege by any assigned role is used.

For data outside the users defined data scope, the calculated national privilege is used. For data that is within the data scope, the maximum privilege defined by either local or national calculated privilege is used.

For classified objects, the K-value in combination with either the user having the FBE role or existence of the user’s RID/CVR combination in the BeskyttetDataBruger table will dictate the user’s access to a specific field on the entity.

8.2.3.2 Authorization in DAR

DAR uses a different authorization model than BBR. It is based on the following dimensions:

1. Roles (“systemroller”):

Roles are defined within the System and each role will provide a specific set rights in the system.

Users are assigned a set of roles by local user administrators, either locally for municipalities through Adgangsstyring or through NemLog-in FBRS for other public authorities as well as private companies

2. Role classification:

Role classifications are used to restrict who a role can be assigned to. This is a property on a role.



i. Government Authority (“Myndighed”): This is used to define that a role can only be assigned to users acting on behalf of a government authority.

ii. Municipality (“Kommune”): This is used to define that a role can only be assigned to users acting on behalf of a municipality.

iii. External (“Ekstern”): This scope is used to define that a role is only applicable to users that are not acting on behalf of from government authorities or municipalities.

It is based on a standard roles/rights matrix in which each role is assigned zero or more rights. These rights are then enforced in the application. A role either has a given right or not; there are not different levels of relationship; read and write will be represented as separate rights.

Vej og by

Adresseanvendelse

Adressemyndighed

Opgave godkender

Add Navngiven Vej xUpdate Navngiven Vej xUpdateRetskrivningskontrol

Add Supplerende Bynavn xUpdate Supplerende Bynavn xAdd Reserveret Vejnavn x xUpdate Reserveret Vejnavn x xSee Adresseopgave data from own Kommune x x x

Figure 62: Example of a roles/rights matrix. This does not represent the final relations, but is just used to illustrate the concept.

When a user is logged in the roles are filtered based on their role classification so all roles related to classifications that do not match the user’s current scope will be removed.

All rights apply only to the municipality of the current working scope unless they explicitly state otherwise (e.g. “See internal data for all Kommune”). There will only be created the needed add/update permissions, and these will not apply to other than the scope’s own municipality. This means that if a government authority needs write access to domain objects (such as Husnummer, Adresse etc.) they need to get a “fuldmagt” from that municipality, or a specific right has to be implemented that gives access to the domain objects but for all municipalities and this right is then given to the required government authority roles.

End-users and system-users are assigned a set of roles (in either NemLog-In FBRS or Adgangsstyring Administrationsmodul depending on where the user originates), and the corresponding rights then apply to the system.

End-users furthermore have the option of using delegated roles (“fuldmagt”). This means that a role from a Government authority, Municipality or even private company or citizen can be given to another user from a different organization – allowing them to access the System on their behalf. When logging



in, the user will then have to choose whether to log in as himself or on behalf of the delegated access. If delegated access is chosen, the user will get access according to the delegated roles.

Note, that modifying the rights of a given role can affect UI, use cases and system integration, as you can potentially remove privileges that are required for the system code to function, which will then cause the system to fail. The recommended approach will be to test all role rights modifications in test environments and deploy them to production in a controlled manner.

8.2.3.2.1 Roles and Rights

The roles consist of these properties:

Name: The display name of the role. This is the name that is used in the UI and internally in the application

RoleId: The ID of the role

Role Classification: The role classification the role belongs to.

Additionally, the names of the roles will be different across environments, as both IdP systems enforce uniqueness of role names across service providers.

The rights simply consist of a name which is displayed in the UI and an ID which is used internally. The access to an operation is based on the sum of your rights of all your roles.

Figure 373 The relationship between roles and rights in DAR

The roles are exposed one-to-one into Adgangsstyring Administrationsmodul and NemLog-In FBRS so that the local user administrators in Municipalities and Government Authorities can assign the roles to their users:

a) In Adgangsstyring Administrationsmodul only roles relevant to municipalities will be exposed

b) In NemLog-In FBRS both roles relevant to Municipalities and Government Authorities will be exposed.

o The roles are primarily relevant to Government Authorities, but Municipalities may decide to use NemLog-In for some of their users or may want to delegate roles to Government Authorities or employees in private companies.

Role assignment is done by:



c) Adgangsstyring Administrationsmodul: The System roles are mapped to “jobfunktionsroller” which are used in the everyday user administration of a given Municipality.

d) NemLog-In FBRS: The roles can either be assigned directly to the end-users or assigned through user groups.

Technically, the System roles (”systemroller”) cannot be digitally transferred into neither Adgangsstyring Administrationsportal or NemLog-In FBRS as this is not supported by the two platforms. The System role administration will therefore provide export of roles to Excel-readable CSV, but it is a manual task to transfer these roles into Adgangsstyring Administrationsportal and NemLog-In FBRS whenever roles are added, removed or change names. Note, that modifying the rights mappings of a role has no impact on Adgangsstyring Administrationsportal and NemLog-In FBRS and does not require any synchronization.

8.2.3.3 Delegation of roles (”fuldmagt”) - both BBR and DAR

The System will support delegation of roles (“fuldmagt”), both for System users in municipalities and public authorities and for the private companies and citizens who propose updates to their owned properties in the System.

When an end-user receives a delegated role, it means that he is able to access the System with another data scope than his own (which typically means another CVR number, except delegation for private citizens where it is another CPR number).

8.2.3.3.1 Delegation and classified data (BBR)

For security reasons, classified data is never shown through delegated access, meaning that a non-approved user can never see classified data through delegation. Even a security-approved user cannot access classified data while accessing BBR on behalf of delegated roles, unless the user furthermore is explicitly permitted to access classified data in the delegated data scope.

8.2.3.3.2 Delegation in the System client

Employees in a Municipality can delegate a System role to employees in another Municipality, to employees in a public authority or even to employees in a private company (e.g. a surveyor), and thus allow the external employee to access and update the System on behalf of the Municipality.

Delegation between Municipalities is performed within Adgangsstyring in Den Fælleskommunale Rammearkitektur, where the local user administrator in Municipality A can decide to delegate a System role to Municipality B. The local user administrator in Municipality B can then assign the role to end-users in Municipality B.

Delegation to employees in public authorities or private companies is done within NemLog-In FBRS “erhvervsfuldmagt”, where the local user administrator in the Municipality can delegate a role either

a) To a specific external employee in NemLog-In (CVR + RID), or

b) To the local user administrator in the external organization who can then assign the role to his employees (like in Adgangsstyring in Den Fælleskommunale Rammearkitektur).

Similarly, a public authority with access to the System can delegate a role to employees in another public authority, a municipality or a private company. They can only setup delegation through NemLog-In FBRS, so if they delegate a role to a Municipality the Municipality user must use NemLog-In to act on behalf of the public authority. Note, that in this case, the external employee would access the System on behalf of the public authority, so there would not be any filtering on Municipality ID.

Both Adgangsstyring in Den Fælleskommunale Rammearkitektur and NemLog-In FBRS transmit delegated roles to the System in the same way. When an end-user logs in (using either Context Handler IdP in Adgangsstyring or NemLog-In IdP) the SAML token sent to the System will contain both



the end-users own roles (with his own CVR number as scope) and all his delegated roles (with the CVR number from which they were delegated as scope).

Whenever the System client detects a login containing delegated roles, the user will be redirected to a screen allowing the user to choose whether to act as himself or on behalf of another specific CVR. When the user has chosen which scope (=CVR) to use, the user is given access as if he was originating from this data scope and only with the security roles that belong to this scope. The UI will show clearly that he is acting on behalf of another organization (as illustrated below for BBR) and so will all logs and history.

Figure 38 – Using the BBR client on behalf of another organization through delegated roles (“fuldmagt”). See [D0160] for the most up-to-date screenshots.

The access control module in the System client will ensure that the user always acts on behalf of exactly one municipality/public authority at a time. This ensures that roles assigned by different authorities cannot be combined in the same action, even when the user can act on behalf of several organizations.

8.2.3.3.3 Delegation for “Eksternt Indberetningssystem” (the System Service Gateway)

It is also possible to use delegation for the Service Gateway. Similarly to the System client, the access control module of the System Service Gateway will also ensure that the user always acts on behalf of exactly one municipality/public authority at a time (to ensure that roles assigned by different authorities cannot be combined in the same action). The specific details of how the System Service Gateway handles this is described in section 8.2.2.4.

RetBBR does not use delegation as it calls BBR based on system-system roles.

8.2.4 Access control moduleThis section describes how access control according to the authorization model is performed based on the information from the SAML token obtained during authentication.

As mentioned earlier, both the Context Handler IdP, NemLog-In IdP, and their corresponding STS’s, will both deliver user information as well as authorization information in the SAML token, including roles, scopes on roles and delegated roles (“fuldmagt”).

Sample role: user has rights in authority with CVR 29188505: can read full information.


<PrivilegeList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://itst.dk/oiosaml/basic_privilege_profile"> <PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier:29188505" xmlns=""> <Privilege> http://data.gov.dk/roles/local-dar/usersystemrole#vej_og_by_1 </Privilege> </PrivilegeGroup></PrivilegeList>


The first task of the access control module is that whenever delegated roles are present, the access control module must ensure that only one data scope (=one CVR or CPR number) is active at a time. As mentioned earlier, this is done by

a) The System UI client redirects the end-user to a screen where he chooses who to act on behalf of (=CVR number)

b) Ajourføringsservices throw a security error if they detect any delegated roles, as this concept does not apply to the NemLog-In system-users used for this integration.

c) The System Service Gateway has a mandatory “scope” field on all services, forcing the “Eksternt Indberetningssystem” to make their end-user choose whom to act on behalf of before calling a service. The only service that does not have this mandatory “scope” field is the user-info service that allows “Eksternt Indberetningssystem” to check who the end-user can act on behalf of.

The access control module then creates a security context containing:

1. Exactly one active data scope, which can be

a) A Municipality Scope (CVR)

b) A public authority scope (CVR)

c) An owner scope (CVR or CPR)

2. The set of roles in the SAML token that all belong to this data scope and that are of the correct data scope type in the System role model. The combined set of CRUD privileges on objects and fields for the roles is calculated based on the roles.

3. A flag for whether the end-user is security-approved or not

This security context is systematically used by

The System Client for

o hiding functionality regarding entities the end-user does not have access to or functionality that requires specific role membership

o making specific fields on entities hidden or read-only in the UI depending on the combined set of CRUD privileges

Ajourføringsservices and Service Gateway for

o Propagating any security errors detected by the Backend Layer

The Application layer for validating access when retrieving and updating data

o When retrieving data, the security context is used for filtering of entities according to active data scope, CRUD privileges and the users security-approval status

The retrieved fields are furthermore decorated according to CRUD privileges (i.e. fields are marked as read-only, hidden or update-able) (BBR only)

o When updating data, the security context is used for validating, that the user is allowed to create or update a given entity and that the user is not trying to update or create a field he does not have the right CRUD privilege for.

For BBR, this requires the create/update API’s to distinguish exactly which fields the user has updated rather than sending the entire list of fields on a given entity every time. The reason for this is that CRUD rights can differs per attribute of an object and not just by object.



8.2.5 Reporting Services securityIn this section the security of Reporting Services is explained. Reports use a replicated database to access the System’s data – which always is read-only, meaning that only read-rights are relevant regarding creating new report and running existing reports. Though, in addition to creating and running reports, the accessing of the Reporting Services and Reporting Builder is the more complex security aspect, which this section focuses on – in section 8.2.5.3.

8.2.5.1 Report structure

To manage access to reports, a flat folder structure in Reporting Services Report Manager will be used. There will be

One shared folder with predefined reports that will be accessible by all report users.

One shared folder with custom reports that will be accessible by all report users.

A folder for each authority or municipality for storing custom organization-specific reports.

8.2.5.2 Data filtering (BBR)

A set of fixed internal Active Directory accounts will be predefined and used by the system for querying and filtering report data such that

One account for each authority that can read unclassified data across municipalities

One account for each municipality can read unclassified data from that municipality

One account for each municipality can read classified and unclassified data from that municipality

One account for each authority that can read classified and unclassified data across municipalities

Access to data will be limited by setting up database views that will filter data based on the Active Directory account used to access the database. Filtering will skip classified rows in output (no filed-level masking will be used in reports). These views will be the only database objects accessible to these fixed AD accounts. The specific AD account used will be chosen by the System based on its lists of Authorities, Municipalities and security approved users combined with the current user’s CVR / RID tokens.

8.2.5.3 Report access roles

There are two separate roles (use cases) than can be granted for accessing reporting services:

Report query user

Report administrator

8.2.5.3.1 Report query role

Report query users can view predefined and custom municipality-specific reports via the website. The Reporting Services Report Viewer web control will be embedded in the Frontend website for this purpose. The Report Viewer control is a standard component in Reporting Services that allows users to view a report and optionally export it in formats such as PDF and CSV.

8.2.5.3.1.1 Authentication

Users will be authenticated using their usual IdP as used for accessing the system UI.



8.2.5.3.1.2 Authorization

Users with Rapportforespørgerrolle or Rapportadministratorrolle roles will be authorized to access Report query functionality.

8.2.5.3.1.3 Report access

Report query users will be able to access reports from the folders with predefined reports, custom shared reports and municipality-specific report folder of their municipality (matching the user’s CVR number with the folder CVR number).

8.2.5.3.1.4 Classified data access

Access to classified data in reports will be controlled by whether the user has access to protected data (see section 8.2.3.1.3).Depending on classified data access, corresponding AD identities will be used by the System to access Reporting Services and to authenticate to the Database. SQL views designed for reporting will be the only database objects accessible to these AD accounts. The views will filter classified data based on the AD identity used for the query.

8.2.5.3.1.5 System access process

The process of accessing the system as report query user is presented on the figure below:

Figure 65 - Report query user system access process

The Reporting Services SOAP API is used by the Frontend web site to fetch the list of available reports (depending on the users CVR token) for a user. The system converts the users token based identity to an Active Directory based identity (that can read unclassified data or both classified and unclassified data, in one specific or all municipalities). This identity is used by Reporting Services to generate the selected report and query the database.

8.2.5.3.2 Report administrator role

Report administrators will be able to edit and create reports using the Reporting Services Report Builder application via Remote Desktop Services. A Report administrator will be able to publish municipality specific reports to any municipality he chooses.



8.2.5.3.2.1 Authentication

The users will be authenticated using NemLog-In on the Frontend website. Users will be authenticated using temporary personal AD credentials when accessing Report Builder.

8.2.5.3.2.2 Authorization

Users with Rapportadministratorrolle roles will be authorized to access Report Viewer.

To login to the Remote Desktop Web Access page, a personal Active Directory account will be created/activated for each report administrator by the system (Active Directory Account Management Service). AD credentials for Remote Desktop Web Access will be handed out to the Report administrator via the Frontend website.

A daily job (executed at midnight) will deactivate all report administrator AD accounts in order to enforce daily NemLog-In role verification. Thereby preventing users with a revoked Rapportadministratorrolle from accessing Report Builder.

Access to Report Builder via Remote Desktop will be limited to 10 concurrent users.

8.2.5.3.2.3 Report access

Report administrators will be able to access (read) predefined reports, shared reports (read/write) and municipality-specific reports (read/write) of all municipalities. It will be possible for report designers to publish a report in any municipality-specific folder, thereby enabling the required easy sharing of custom reports between municipalities. This access right includes update and delete rights to existing reports in municipality-specific folders.

8.2.5.3.2.4 Classified data accessReport designer users will not be able to access classified data from the database. SQL views designed for reporting will be the only database objects accessible to report designer users.

8.2.5.3.2.5 System access process

The process of accessing the system as report administrator is presented on the figure below:

Figure 396 - Report administrator system access process

The report administrator logs in on the Frontend website via NemLogin/STS. The user can access an administrative page/UI for users with the report administrator role where the user requests Report Builder access. This will create or reactivate the users personal AD account and display a link to Remote Desktop Web Access along with the required credentials.



The user then logs in to Remote Desktop Web Access and starts a remote desktop session where Report Builder can be started and work with existing or new reports in Reporting Services.

8.3 Personal sensitive and classified data8.3.1 BBR

As the production data contains Personal sensitive data and military classified data these data are not allowed to be processed in non-production environments.

The test data that the system will contain will not contain any classified data. When generating test data, classified data will be removed and random selection of data will be marked as classified in order to test functionality regarding classified information.

For the personal sensitive information, if any, the data will be scrambled in non-production environments. Personal sensitive information will be handled in accordance with Persondataloven. For more info, see 8.2.3.1.3 Classified/protected data.

In cooperation with KOMBIT, a review of the system will be made to Datatilsynet in form of a data handling agreement.

8.3.2 DARDAR does not contain any personally sensitive or classified data.

8.4 Security overview relative to requirements8.4.1 General requirements

Note: The requirements are written in Danish originally. In order to preserve the integrity of them, this will not be changed. This can, in some ways, be seen as a summary of many of the previous points.

Requirement/Krav Response

Id: 72

Tokens skal udveksles over transportmekanismer, der sikrer konfidentialitet ved brug af stærk kryptering. Det henvises til Datatilsynets definition af stærk kryptering.

This is handled through the authentication process described in section 8.2.3.BBR and DAR do not implement any token providers, and the token providers provided by other projects only work at all using transport layer security. This we’re covered.

Id: 73

Signaturer, certifikater og security tokens skal sikkerhedsvalideres af Systemet før brug. Der må kun accepteres SAML tokens, som er digitalt underskrevet med Context Handlerens eller Security Token Servicens certifikat. Certifikater skal generelt spærretjekkes mod DanID.

This is handled through the authentication process described in section 8.2.3.BBR and DAR do not implement any token providers, and the token providers provided by other projects only work at all using transport layer security. This we’re covered.

Id: 75

Systemet skal beskytte de lokale trust stores (f.eks. lokale kopier af metadata og certifikater fra Context Handler og Security

Secure because the system uses the Microsoft Certificate Store. Only admins may access it as well as specific IIS processes specifically allowed to access them.STS tokens are cached in memory only and



Token Service) mod uautoriseret adgang.

Det er Leverandøren af Systemets ansvar, at trust stores beskyttes tilstrækkeligt.

NEVER written to disk. They are thrown away when they expire or when the computer or program restarts or encounters a critical error – whichever comes first.In other words, the system relies on modern, secure operating system architecture to obfuscate the memory space the STS tokens are situated in, making it unreadable by other users on the systems or externally. The use of C# and .NET virtualization also ensures that memory overflows cannot expose these tokens or certificates from within the program.

id: 154

Såfremt Systemet er webbaseret skal Leverandøren sikre, at Systemet ikke kan manipuleres gennem manuel retning i URL.

The system is based on MVC, which means that every single page is generated through a web request response. Before any response is sent on ANY call in the system, an authentication check is performed as described in chapter 8.2.3.Additionally, F-Secure Cyber Security Services (aka. Karhu) checks for these kinds of vulnerabilities, and an extensive scan of the system will be carried out before it enters production.

id: 155

Systemet skal sikre mod uautoriseret læk af følsomme informationer blandt andet ved at:

sikre adskillelse mellem forskellige dele af Systemet således, at enhver given del af Systemet ikke nødvendigvis har adgang til alle andre dele af Systemet. Eksempelvis skal hele Systemet ikke have adgang til nøgler eller personfølsomme oplysninger.alle dele af Systemet afvikles med mindst mulige privilegier således, at de kun har adgang til in-formationer og funktionalitet, der er nødvendige for at kunne udføre deres opgave.sikre, at Systemet ikke kan oprette unødige forbindelser ud af Systemet, f.eks. ved at opsætte en firewall, der hindrer oprettelse af forbindelser til internettet.sikre, at følsomme informationer sikres under lagring, f.eks. ved kryptering og fysisk sikringForhindre, at detaljeret information om Systemets interne virkemåde ikke er nemt tilgængelige, eksempelvis udvikles kommentarer, version af software, navne på funktioner og variable, kildekode for scripts).

Servers with direct access to any personally identifiable information will be scrambled when viewed any other way due to the use of RAID8. It is therefore not possible to directly open the files.The system is run under IIS, which has minimal privileges and can only see the certificates it needs to see.MS SQL Server is run as a non-admin user.The systems are separated by having them on different virtual machines.There is rigid firewalling between each of the components in the hosting solution. Only ports that NEED to be open are open.Users logging into the system cannot start or stop the services unless they have local server administrator privileges, and none of them can be started or stopped through the network, even if they could get through the firewall.The system ensures both SOFTWARE AND PHYSICAL SECURITY. Physical security is taken care of by guards at the operation site. The software security is taken care of by scrambling the volume using RAID.The system ensures that it does not disclose information about how it is running. This can be checked by F-SECURE.

8 https://en.wikipedia.org/wiki/RAID


https://en.wikipedia.org/wiki/RAID


Getting around these security measures is technically possible, but it requires literally carrying the entire server setup, in all its myriad complexity, physically out of the room PAST THE PHYSICAL GUARDS OR hacking into the SQL server’s admin from the outside, which is impossible due to the firewall (and even if it wasn’t, it requires knowing that user’s username/password).Additionally, the system administrator can delegate himself to rights to mess things up. The SQL server administrator MUST be trusted by KOMBIT



id: 156

Systemet skal sikre integritet af informationer blandt andet ved at:

sikre mod uautoriserede ændringer af informationer (fra Brugere, fra andre dele af Systemet og fra eksterne parter)informationer ikke overskrives ved en fejl (eksempelvis ved at skrivebeskytte informationer, der ikke skal opdateres)indarbejde kontrolprocedurer (f.eks. at afstemme informationer fra forskellige kilder)automatisk tjekke og opdage uautoriserede eller ukorrekte ændringer (f.eks. ved at brug af ændringslogs, tjeksum, signaturer mv.påkræve godkendelse af væsentlige ændringersikre mod uautoriserede ændringer af Systemet selv (både software og hardware)

If the database is scrambled by a RAID system that requires login to change, and only PET/KOMBIT/NC approved personnel have access to the machine, everything is fine – it is not possible to read or change the data at all unless you can access the system.Only the database administrator and the application, and nobody else, not even KOMBIT&NC approved personnel in general, are allowed to change the table values at all with their accounts. This is handled via log-in and user accounts.Additionally, RAID scrambled backups are available in case of fatal error.

id: 157

Systemet skal sikres mod uautoriseret adgang til informationer ved blandt andet at:

være bygget ud fra ’defence in depth’-princippet således, at Systemets sikkerhed ikke baseres på enkelte sikkerhedstjek eller enkelte sikringsmetoder, men derimod multiple lag af kontroller, der supplerer hinanden. Dette betyder bl.a., at systemer bag firewalls skal sikres som om, at firewall’en ikke var til stede således, at de er robuste overfor penetrering af firewall eller insiderangreb.Systemets defaultindstillinger og opførsel er sat til at være sikker (default to secure)foretage hærdning af hardware, operativsystemer, middleware, der kræves for at Systemet kørerimplementere fejlhåndtering for alle fejlscenarier således, at en fejl aldrig fører til et sikkerhedsbrud.

The system has a port mapping that maps everything insecure to using transport between all layers of the application – both inside the firewall and outside.Furthermore, the application will not be available at all on an insecure channel, so it will obviously default to secure as it can’t do anything else.

id: 158

Systemet skal sikre, at forbindelser med Systemet foregår på en velkontrolleret måde blandt andet ved:

kun at udstille de specifikke services, der er behov for (eksempelvis gennem konfiguration af Systemet og/eller brug af

Operations only hosts a particular application on one particular virtual machine by default, covering this issue.



firewalls)alene at udstille services baseret på dokumenterede, testede og godkendte snitfladerat være isoleret netværksmæssigt fra øvrige systemerat køre på servere (fysisk eller virtuelle), der er dedikerede til en given funktionalitet

id: 159

Systemet skal sikre mod uautoriserede forbindelser fra systemer blandt andet ved at:

Antage, at alle eksterne forbindelser som udgangspunkt er usikreforetage autentifikation og adgangskontrol ved oprettelse af alle forbindelserimplementere stærk inputvalidering for informationer, der modtages fra et eksternt system, med henblik på at undgå URL-, Form- og SQL injection, Cross Site Scripting og lignende angrebgentage valideringsskridt løbende og oprettelse af nye forbindelser

The system carefully checks all forms are valid and also data wash and generally not trust other clients. In corporation with F-SECURE, the system is ensured to not have any known vulnerabilities.

id: 160

Alle informationer, der sendes ind og ud af Systemets, skal beskyttes passende mod udefrakommende angreb eksempelvis ved at anvende krypteringsprotokoller og/eller foretage fysisk sikring.

The system is physically secured and will run entirely via TLS v1.2, unless a specific service required another version. TLS v1.0/SSLv3 are banned outright, however.

id: 161

De krypteringsprotokoller, som Systemet anvender til at beskytte informationer under transport, skal være alment og offentligt anerkendte og afprøvede. Algoritmer og nøglelængder skal vælges, så de er passende stærke til at beskytte informationer i det tidsrum, som informationerne påkræver det i henhold til retningslinjer fra Datatilsynet og NIST.

The system will use TLS v1.2 and AES_128 cryptography. This is approved by Datatilsynet and NIST.

id: 162

Systemet skal beskytte sessioner mod overtagelse (session hijacking eller session cloning) bl.a. ved at:

sikre, at session ID’er ikke nemt kan gætteskryptografisk beskytte trafikken mellem servere og klientersætte evt. anvendte sessioncookies til at

Cookies will be set to HttpOnly and Secure in the web log



holde browsere til ”secure” og ”httponly” således, at de hverken kan sendes over ukrypterede forbindelser eller tilgås fra JavaScript

8.4.2 PersondatalovenIn accordance with Persondataloven, the following measurements are taken for the system:

- The solution will be hosted in Denmark, as is standard in NC Hosting.

- Datatilsynet, via KOMBIT, will need to approve this design. This is standard contract fare.

- The system only collects data necessary for it to do its designated purposes and does not collect additional, unnecessary data from other system or users.

- The purpose of this project will not change. It is, and will continue to be, the BBR and DAR registries until it is decommissioned far in the future.

- We have several entries in the database that need to be hidden. It will never be shown on any external service. Not in Total Data Export, not in synchronizations, and certainly not in web requests.

- The system performs extensive data cleaning of all incoming data

- Data will accumulate due to bitemporality and this cannot be avoided – however the purpose of this project is to accumulate data, and this is deemed okay.

- All data is be safely removed and destroyed from the system when the project is no longer operational, though external systems might still have copies.

8.4.3 SikkerhedsbekendtgørelsenData that in BBR 1.7 was security classified in accordance with Sikkerhedscirkulæret, though now in BBR 2.0 is only considered protected and thereby does not need to obey Sikkerhedscirkulæret, only common best practices for keeping data safe.


Documents

O0500 - Software Architecture (Shared) - BBR · Web viewThis document describes the software architecture of BBR 2.0 and DAR 1.0. This is done by using the concepts from Philippe