Architektúra verejnej správy

Stretnutie

Architecture Review Board

Dátum stretnutia

21.02.2023

Miesto stretnutia

MS Teams

Vypracoval

Anton Svetlošák

Prítomní:

anton.svetlosak@mirri.gov.sk

vladimir.kovac@mirri.gov.sk

marian.nagy@mirri.gov.sk

Miroslav.liska@mirri.gov.sk

Daniel.mikulka@mirri.gov.sk

Viktoria.sunderlikova@mirri.gov.sk

peter.stavny@slovenskoit.sk

radovan.kulin@slovenskoit.sk

viliam.tokarcik@slovenskoit.sk

peter.zovak@nases.gov.sk

stefan.szilva@nases.gov.sk

lenka.mitakova@nases.gov.sk

1. Zápis zo stretnutia

I

Integrácie MUPVS na eDesk – definícia ako sa budú služby eDesk využívať v rámci mUPVS a SVM.

Riziko, že to eDesk zvládne. Definovať, ktoré API eDesku budú volané, ako často.

Zvažujú sa alternatívy:

• EKR bez zmeny
• Kombinácia EKR a KSDR
• EKR so zmenami
• EKR na základe eventov
• Kombinácia vyššie uvedených

Prečo nie KSDR – nie sú tam historické dáta. Je potrebné migrovať historické dáta do KSDR.

Zmeny na EKR nacenené od GT – sú veľké, lebo definícia od SKIT zahŕňa aj nový eDesk.

EKR limitácia v objeme správ 100 000 ks za 2 hodiny – treba preveriť. Správa ma max. Veľkosť 50MB.

GetMessages – bude vždy potrebné dotiahnuť z EKR.

Prvá analýza sa urobila pre schránku light, teraz je sa analýza doplnila o full scope. V rámci mUPVS sa bude pracovať len na jednoduchej schránke pre fyzické osoby. V SVM je na začiatku potrebné len rozšírenie o light rozhrania.

Štatistiky NASES: najviac správ bude do 360Kb, menej ako 2% majú viac ako 5MB.

Rado: Potrebné upresniť alternatívy. Na ARB preberieme tieto alternatívy a vyhodnotia sa.

I

CAMP – použitie OnBehalfOf

SKIT navrhuje zaviesť nový atribút OnBehalfOf vo volaní služieb zaregistrovaných v CAMP. Gestor služby by sa sám rozhodol pri implementácii / definovaní svojho API, či tento atribút umožní používať.

Technické účty zastupujúce identitu na ÚPVS – SKIT navrhuje v CAMP nahradiť používaním zastupovania zákonným zástupcom, v mene ktorého by sa aplikácia automaticky prihlasovala. V prípade viacerých zákonných zástupcov by sa vybral prvý.

Rozsah oprávnení pre aplikáciu – by bol daný ApplicationID aplikácie na základe registrovaných aplikácií, pričom v CAMP by sa dalo určiť, či dané ApplicationID má alebo nemá právo volať dané API. Detailnejšie oprávnenia si musí riešiť daný backend na základe ApplicationID a/alebo samotného JWT tokenu.

JWT aj ApplicationID budú prechádzať až po backend (API).

Autentifikácia aplikácií / systémov

Pre autentifikáciu bude postačovať autentifikácia aplikácie (lebo je priradená na konkrétnu identitu), nie je potrebné autentifikovať teda subjekt.

ApplicationID (UUID) bude naviazané na konkrétnu organizáciu vždy a bude generované na strane CAMP v developer portáli.

mTLS – CAMP bude poskytovať službu pre vygenerovanie certifikátu na základe CSR (v certifikáte bude ApplicationID), následne certifikát zaregistruje cez ServiceDesk organizácia na aplikáciu – ApplicationID.

JWT – OpenID connect server v rámci projektu CAMP vygeneruje cez GUI v ServiceDesk “secret” na dané ApplicationID a ukladá si ho. Aplikácia si ho ukladá a používa pri autentifikácii.

API key shared Key – vygeneruje sa v CAMP – API key pre ApplicationID, následne používateľ môže zvoliť privátny kľúč ktorý vloží do CAMP – používa sa symetrické šifrovanie.

Pre odosielanie správ bude treba vyriešiť QAA Level 3 pre tieto prostriedky.

Dnes autentifikačné certifikáty na UPVS nie celkom dosahujú QAA Level 3, avšak do 1. októbra 2023 musí MIRRI posúdiť tieto autentifikátory.

P.Stavný pripraví podklady pre PS4 – protokoly pre autentifikáciu (technické špecifikácie – RFC/ISO/normy) + na aký účel slúžia. Plus popísať proces registrácie a používania autentifikátorov. Plus popis obsahu JWT.

Udeľovanie oprávnenia inej osobe – mimo scope CAMP

Keď sa dve osoby dohodnú, vygeneruje sa token plnomocenstva, ktorý sa dá použi pre volanie API a pre vydanie access/refresh tokenu.

Oprávnenie by mohlo byť časovo obmedzené alebo aj jednorazovo (do návrhu ešte SKIT doplní aj jednorázovú možnosť).

Ide celkovo o pracovné návrhy SKIT, je potrebné zvážiť tento koncept.

I

       2. Otvorené otázky a riziká

2.1

O

2.2

O

2.3

O

     3. Úlohy

          Zodpovedný

Termín

Stav

3.1

U

3.2

U

3.3

U

      4. Závery

4.1

Z

4.2

Z

4.3

Z