Dit document bevat de oude document die vroeg in het Koppeltaal 2.0 project gemaakt zijn, exclusief de opmerkingen.

DAI - Eisen (en aanbevelingen) aan domein, applicatie en applicatie-instantie statussen - [review]

001. Een Domein kan de volgende status hebben:

a. Aanmaken - Domein registratie is nog niet volledig afgerond en getest.

b. In onderhoud - Het domein wordt buiten gebruik gesteld. Eerst MOETEN alle Applicatie-Instanties op status "In onderhoud" staan. Opmerkingen:

i. Bij "In onderhoud" worden er geen launches en/of notificaties uitgevoerd. Zie ook opmerking als Applicatie-Instantie op status "In onderhoud" staan.

c. Actief - Het Domein is in gebruik.

d. Afgesloten - Domein wordt niet gebruikt. Kan alleen na "In onderhoud" en als alle Applicatie-Instanties op status "Afgesloten" staan. Opmerkingen:

i. Alleen Systeembeheerder kan nog terug naar status "Actief" zolang de gegevens NIET verwijderd zijn.

ii. Indien NIET alle Applicatie-Instanties op status "Afgesloten" staan, meldt dit via foutmelding.

iii. Bij status "Afgesloten" MOETEN alle (zichtbare) velden die hier op betrekking hebben niet-muteerbaar zijn in de beheerschermen.

002. Een Applicatie kan de volgende status hebben:

a. Aanmaken - Applicatie registratie is niet volledig afgerond en getest.

b. Actief - Applicatie mag gebruikt worden.

c. Afgesloten - Applicatie mag NIET gebruikt worden. Opmerking:

i. Alleen Systeembeheerder kan nog terug naar status "Actief" zolang de gegevens NIET verwijderd zijn.

ii. Alle Applicatie-Instanties MOETEN dan afgesloten zijn. Indien NIET alle Applicatie-Instanties op status "Afgesloten" staan, meldt dit via foutmelding.

iii. Bij status "Afgesloten" MOETEN alle (zichtbare) velden die hier op betrekking hebben niet-muteerbaar zijn in de beheerschermen.

003. Een Applicatie-Instantie kan de volgende status hebben:

a. Aanmaken  - Registratie van authenticatie middelen moet afgerond worden.

b. Actief  – Applicatie-Instantie is actief in een Domein met status "Actief" en bij een Applicatie met status "Actief"

c. In onderhoud – Applicatie-Instantie tijdelijk gestopt. Domein kan op status "In onderhoud" gezet worden. Zie punt 12.

d. Afgesloten – Applicatie-Instantie is uitgeschakeld. Opmerking:

i. Terug naar naar status "Actief" is alleen mogelijk zolang de Applicatie-Instantie NIET is verwijderd.

ii. Bij status "Afgesloten" MOETEN alle (zichtbare) velden die hier op betrekking hebben niet-muteerbaar zijn in de beheerschermen.

004. Bij het verwijderen van een Domein, Applicatie of Applicatie-Instantie houden we geen status bij en alle geregistreerde gegevens worden verwijderd. Alleen uitvoerbaar door Systeembeheerder.

005. Een Domein mag alleen verwijderd worden, als de status op "Afgesloten" staat EN alle Applicatie-Instanties niet geregistreerd (status is "Aanmaken") of verwijderd zijn. 

006. Een Applicatie mag alleen verwijderd worden als status op "Afgesloten" staat EN  alle  Applicatie-Instanties  niet geregistreerd (status is "Aanmaken") of verwijderd zijn.  

007. Een Applicatie-Instantie mag alleen verwijderd worden als status op "Afgesloten"  staat. 

008. De status van een Domein wordt door een Domeinbeheerder of Systeembeheerder vastgelegd en beheerd.

009. De status van een Applicatie wordt door een Applicatiebeheerder of Systeembeheerder vastgelegd en beheerd.

010. De status van een Applicatie-Instantie wordt door een Domeinbeheerder of Systeembeheerder vastgelegd en beheerd in samenspraak met een applicatiebeheerder.

011. Als Systeembeheerder de status wijzigt van een Domein, Applicatie of Applicatie-Instantie mag de Applicatiebeheerder of Domeinbeheerder beheerder dit NIET overrulen/wijzigen.

012. Bij Applicatie-Instantie met status "In onderhoud" is het niet mogelijk om gelanceerd te worden EN worden er geen notificaties verzonden naar de desbetreffende Applicatie-instantie.  (zichtbaar via ActivityDefintion.endpoint.status=suspended)

013. Bij elke statuswijziging MOET een reden opgegeven worden.

014. Elke status wijziging of verwijdering van Domein, Applicatie of Applicatie-Instantie MOET gelogd worden met reden, datum/tijdstip, rol en naam van uitvoerend persoon.

BEB - Beheren van entiteiten en bevoegdheden - [review]

Hier een korte samenvatting van wat conclusies en wensen voortgekomen uit discussie met testteam.

Het verlenen van toegang tot resources moet goed geregeld zijn. Het is een proces waar alle belanghebbenden baat bij hebben. Hoe groter de organisatie, hoe meer applicaties er in gebruik zijn, hoe belangrijker een formeel autorisatieproces wordt. Dit proces moet duidelijk, effectief en efficiënt zijn.

a001. Voordat bevoegdheden worden vastgelegd moeten eerst de entiteiten (applicaties of personen), (applicatie en gebruikers) rollen, autorisatieregels en domeinen worden vastgelegd. Er zijn al meerdere applicatie- en beheerdersrollen beschreven en vastgelegd door de architecten. Als we een vaste set aan (applicatie) rollen definiëren, kunnen we autorisatieregels samenstellen omdat we al grotendeels weten welke FHIR resources we gebruiken binnen Koppeltaal. De entiteiten, rollen, autorisatieregels en domeinen kunnen door Support (de systeembeheerder)  worden opgevoerd. Dit is een domein- en applicatie onafhankelijke taak.

a002. Een domein bevat (minimaal) de volgende gegevens/attributen:

a. Een unieke domein identifier

b. Een (leesbare) naam voor het domein

c. een (logische) domein naam voor een URL

d. Contact gegevens voor het domein

i. contactpersoon

ii. e-mail adres/telefoon

e. Type domein (nader uitwerken)

003. Een entiteit (applicatie) bevat (minimaal) de volgende gegevens/attributen:

a. Een unieke entiteit identifier

b. Een (leesbare) naam van de entiteit

c. Een (logische) naam van de entiteit

d. Toekennen van 0 of meer rol identifiers.

e. Contact gegevens voor de entiteit

i. contactpersoon

ii. e-mail adres/telefoon

a004. De autorisatieregels bevatten wie (eigenaar of iedereen) de toegestane CRUD operaties op de FHIR resources mag uitvoeren. Elke vastgelegde rol krijgt een verzameling autorisatieregels.

a005. Een (applicatie) rol bevat (minimaal) de volgende gegevens/attributen:

a. Een unieke rol identifier,

b. Een (leesbare) naam

c. Een (logische) naam

d. Een verzameling autorisatieregels.

a006. Er mogen geen afhankelijkheden in een rol vastgelegd worden naar andere digitale identiteiten. Voorbeeld: Rol X bepaalt (Grant) een autorisatieregels voor Rol Y waar een ander digitale entiteit aan is gekoppeld.

a007. De invulling van één domein en de uitgave van digitale identiteiten (voor applicatie instanties – client id’s) gebeurt door de domeinbeheerder.

a008. Het toekennen van bevoegdheden aan digitale identiteiten (applicatie instanties) of het intrekken van bevoegdheden, gebeurt via het toekennen van een (applicatie of gebruikers) rol aan een digitale identiteit. Dit wordt door de domeinbeheerder uitgevoerd. Het intrekken van bevoegdheden gebeurt dus door de digitale identiteiten (applicatie instantie) zijn rol te ontnemen.

a. Je kan een entiteit (applicatie) certificeren voor meerdere rollen, maar een applicatie instantie heeft maar één (actieve) rol binnen een domein.

1.Hiermee kan de systeembeheerder aangeven welke rollen er zijn weggelegd voor de applicatie
Controleren of we bij de beheerschermen kunnen aangegeven dat een applicatie meerdere rollen kan hebben.

2.De domeinbeheerder kan uit de aangegeven rollen, één rol selecteren/activeren voor een domein voor de applicatie instantie. Hierdoor maak je dus niet de fout dat de domeinbeheerder een andere rol kiest dan wat de systeembeheerder aangeeft.
Een lijst van rollen voor de domeinbeheerder moet dus opgebouwd worden uit de selectie die een systeembeheerder heeft gemaakt op een ander beheerscherm. 

b. De gehele toegangscontrole van een entiteit is gebaseerd op een rol. Hierbij worden entiteiten niet rechtstreeks geautoriseerd op resources, maar krijgen uitsluitend rechten in de vorm van een groepslidmaatschap, op basis van een rol die ze vervullen binnen één domein. 

c. Een applicatie instantie krijgt alleen een (actieve) rol als deze aan een domein is toegekend. 

d. Het daadwerkelijk toekennen van rechten (en daarbij behorende permissies) aan een entiteit en het verstrekken van gerelateerde objecten (tokens e.d.) heet provisioning.

a009. Een digitale identiteiten (applicatie instanties) bevat (minimaal) de volgende gegevens/attributen:

a. Een uniek (uitgegeven) client identifier

b. Een (leesbare) naam

c. Een (logische) naam

d. Een entiteit (applicatie) identifier

d. Een JWKS_URI. Is een unieke resource identifier dat refereert naar een applicatie JSON Web Key Set bestand dat (roulerende) publieke sleutels van de applicatie bevat.

e. Een domein Identifier.

f. Rol Identifier. Deze wordt pas vastgelegd nadat de domein en entiteit identifiers bekend zijn bij deze digitale identiteit. 

g. Endpoints (lijst van endpoints die gebruikt worden door de applicatie instantie, zoals lanceer of notificatie endpoints)

i. Endpoint.identifier (globale identifier, bruikbaar over domeinen heen)

ii. Endpoint.name naam van het endpoint

ii. Endpoint.status: active | off | test

iii. Endpoint.period.start: dateTime (startdatum dat endpoint actief is)

iv. Endpoint.period.end: dateTime (einddatum dat endpoint actief is)

v. Endpoint.connectionType: notification | launch | fhir-rest

vi. Endpointaddress: url (technisch basis adres van het endpoint)

vii. Endpoint.header: string (header info, zodat men security tokens kan meesturen, tijdens communicatie)

Hier het gehele plaatje in Archimate. Het model beschrijft de samenhang en relaties tussen de verschillende (uitgewerkte) begrippen op basis van definities. Er zijn 2 relaties in dit model opgenomen, namelijk specialisatie (driehoek) en aggregatie (ruitje). Let op het model is geen datamodel. In een datamodel zouden de relaties andersom getekend worden.

Enkele definities:

• Applicatie. Software of (geautomatiseerd) proces.

• Persoon. Een persoon (van vlees en bloed) die rechten en plichten heeft.

• Endpoint. Een endpoint kan gedefinieerd worden als een applicatie instantie dat inkomende berichten ontvangt en uitgaande berichten verzendt naar het netwerk waarmee het is verbonden.

• Entiteit. Een herkenbaar en onderscheidbaar iets dat relevant is voor identificatie en toegangscontrole waarbij een digitale identiteit kan behoren.

• Digitale identiteit. Een verzameling gegevens (attributen) die een (digitale) representatie zijn van een entiteit. Een entiteit kan meerdere digitale identiteiten hebben.

• Authenticatiemiddel. Een fysiek of digitaal middel op grond waarvan authenticatie van een entiteit kan plaatsvinden; bijvoorbeeld een (authenticatie) token van een Digitale Identiteit met een vastgesteld betrouwbaarheidsniveau.

• Domein. Afgrenzend gebied van entiteiten en de daaraan gerelateerde diensten/voorzieningen die onder één domein valt.

• Rol. Het hebben van een rol is een eigenschap van een entiteit en bepaalt het gedrag van de digitale identiteit.

• Autorisatieregel. Aan de hand van de autorisatieregels kan een entiteit bepaalde handelingen uitvoeren gebaseerd op zijn rol en digitale identiteit.

• Resource. Eenheid van informatie waartoe een entiteit toegang zou kunnen krijgen.

• FHIR Interactie. Soort van toegang of de interactie op informatie.

BRL - Beheerdersrollen [draft]

Hier een samenvatting over de beheerdersrollen en daarbij behorende schermen wat voortgekomen is uit de discussie met het testteam.

Met behulp van verschillende beheerschermen kan VZVZ een flexibele structuur definiëren voor een fijnmazig toegangs- en gebruiksbeheer van Koppeltaal. Één of meer systeembeheerders die tijdens het voorbereidingsproces van Koppeltaal zijn geconfigureerd, bevinden zich bovenaan in de (beheerders)hiërarchie. Deze systeembeheerders kunnen verantwoordelijkheden delegeren aan andere type beheerders, terwijl ze toch de algehele controle behouden.

De verschillende beheerdersrollen bieden Koppeltaal de volgende belangrijke voordelen:

• Gecontroleerde decentralisatie van beheerdersverantwoordelijkheden

• Snel overzicht van product toewijzingen, per gebruiker en per product

001. We onderscheiden drie rollen voor beheerders:

a. Systeembeheerder. Dit is de supergebruiker voor Koppeltaal en deze kan alle beheertaken alleen via beheerschermen uitvoeren. Een systeembeheerder is hier geen beheerder die toegang heeft tot servers of databases. 

b. Domeinbeheerder. Deze beheerder beheert de domeinen die aan hem of haar zijn toegewezen en voert ook alle bijbehorende beheertaken uit.

c. Applicatiebeheerder. Deze beheerder beheert applicaties die aan hem of haar zijn toegewezen en voert ook alle bijbehorende beheertaken uit.

002. Volgende algemene regels/voorwaarden die gelden:

a. Voor elke entiteit (record), die onder beheer valt, zoals rollen, domeinen, applicaties, instanties, etc., wordt door het (beheer) systeem een uniek logische id aangemaakt en uitgegeven, om de entiteit uniek te kunnen identificeren

b. Een uitgegeven logische id is NOOIT en te nimmer wijzigbaar

c. Een eenmalig toegewezen beheerdersrol aan een gebruikersaccount mag NOOIT gewijzigd worden

d. Een gebruikersaccount KAN maar 1 rol hebben

e. Autorisatie (toegewezen rechten op beheerdersfunctionaliteit) van gebruikersaccounts is gekoppeld via de beheerdersrol , NOOIT direct op gebruikersaccounts zelf.

f. Andere systeemvelden, die nodig zijn voor werkende beheerschermen (te bepalen door Itzos), worden nooit beheerd (gemuteerd) door de 3 beheerdersrollen.

g. Elke wijziging die via een (beheerder) scherm wordt doorgevoerd moet door het systeem gelogd worden (wie, wanneer, wat).

003. Systeembeheerder moeten de volgende beheeractiviteiten kunnen uitvoeren:

a. Beheren (aanmaken, wijzigen en beëindigen) van applicatie rollen. Applicatie rollen kunnen NIET beëindigd worden als deze aan een applicatie zijn toegekend.

b. Beheren (aanmaken, wijzigen en beëindigen) van de autorisatieregels behorende bij een applicatierol. Autorisatieregels behorende bij een applicatierol kunnen NIET beëindigd worden als deze aan een applicatie zijn toegekend.

c. Aanmaken/Registreren van een nieuwe applicatie (software product bij Koppeltaal). De volgende items worden (minimaal) bij een applicatie geregistreerd: 

i. applicatienaam

ii. startdatum

iii. selecteren van applicatie rollen bij de applicatie.

iv. het (beheer)systeem registreert en levert een

1.logische id

2.technische naam (wordt uit applicatienaam en logische id samengesteld) en

3.status 'Aanmaken'

4.aanmaakdatum

d. Beheren en aanpassen van applicatie rollen bij de applicatie

e. Aanmaken/Registreren van een nieuw domein. De volgende items worden (minimaal) bij een domein geregistreerd:

i. domeinnaam

ii. startdatum

iii. het (beheer)systeem registreert en levert een

1.logische id

2.technische naam (wordt uit domeinnaam en logische id samengesteld) en

3.status 'Aanmaken'

4.aanmaakdatum

f. Aanmaken van een nieuw account voor beheerders. De volgende items worden (minimaal) bij een account geregistreerd:

i. dit betreft het invullen (of selecteren^[1]) van de gebruikersnaam van de beheerder

ii. het e-mailadres van de beheerder

iii. mobiele nummer

iv. startdatum

v. selecteren van de beheerdersrol

1.Als beheerdersrol een 'Applicatiebeheerder' is, dan MOETEN de applicaties geselecteerd en gekoppeld worden aan het beheerdersaccount

2.Als beheerdersrol een 'Domeinbeheerder' is, dan MOETEN de domeinen geselecteerd en gekoppeld worden aan het beheerdersaccount

vi. het (beheer)systeem registreert en levert een

1.status 'Actief'

2.einddatum van het beheeraccount op precies 1 jaar in de toekomst (Security eisen).

3.aanmaakdatum

4.e-mail bericht naar het ingevulde e-mailadres van de (aangemaakte) beheerder om het wachtwoord aan te maken / te laten resetten.

5. Optioneel: een SMS bericht naar het mobiele nummer om aan te geven dat een account is aangemaakt, maar dat de instructies in de e-mail opgevolgd moeten worden om het account te activeren

a. Voorkeur heeft overigens een authenticator app zoals Microsoft Authenticator voor 2FA (2 Factor Authentication)

g. Een beheerder mag NOOIT zijn eigen (beheerder) account beëindigen

h. Optioneel: Mogelijkheid om te filteren of sorteren op veldnaam bijvoorbeeld op

i. gebruikersnaam van de beheerder

ii. beheerdersrol

iii. startdatum/einddatum/aanmaakdatum

iv. e-mailadres

i. Optioneel: Mogelijkheid om te selecteren/filteren om logregels te archiveren. Specificaties moeten hiervoor nog verder uitgewerkt worden

j. Alle beheertaken van de domein- en applicatiebeheerders.

004. Domeinbeheerder moeten de volgende beheeractiviteiten kunnen uitvoeren:

a. Alle details beheren van zijn/haar domein.

i. Hier bij kan de Domeinbeheerder NIET de logische id, technische naam, en aanmaakdatum wijzigen van een geregistreerd domein

b. Inzien applicatie connectieaanvragen voor het domein, gegroepeerd op status ('Open' bovenaan, daaronder 'Geaccepteerd', daaronder 'Geweigerd') en gesorteerd op aflopende datum (nieuwste aanvraag boven) met per aanvraag 'Open' de gegevens van de contactpersoon van de applicatie en de gekozen applicatie rol van de applicatie instantie. Goed- of afkeuren van deze applicatie connectieaanvragen met status 'Open'.

c. Inzien applicatie instanties die in het domein zitten inclusief details van die applicatie instanties, zoals (één) geselecteerde applicatierol uit de lijst van applicatie rollen van een applicatie, endpoints, etc.

d. Beheren configuratie/instellingen applicatie instanties die in het domein zitten.

e. Inzien subscriptions (applicatie instantie abonnementen) in het domein gegroepeerd op combinatie status ('Actief' bovenaan) met details zoals criteria (trigger condities)  en channel.endpoints.

i. Op dit moments kan de domeinbeheerder NIET handmatig subscriptions toevoegen, wijzigen en/of beëindigen. Als domeinbeheerders wel subscriptions KUNNEN toevoegen en wijzigen MOET het (beheer) systeem controleren dat de URL van de channel.endpoints overeenkomt met een (notificatie) endpoint van een applicatie instantie in dat domein.

f. Inzien van de logging m.b.t. op detail wijzigingen in een domein en domein beheerdersaccount.

005. Applicatiebeheerder moeten de volgende beheeractiviteiten kunnen uitvoeren:

a. Alle details beheren van zijn/haar applicatie (software product bij Koppeltaal)

i. Hier bij kan de Applicatiebeheerder NIET de logische id, technische naam, en aanmaakdatum wijzigen van een geregistreerde applicatie

b. Doen van applicatieconnectie aanvraag voor een domein met daarin een geselecteerde applicatie rol voor de applicatie instantie.

i. De applicatiebeheerder ziet hier een lijst met domeinen (alleen met status 'Actief 'en 'In onderhoud' en moet daar één van kiezen).

ii. Het (beheer) systeem geeft deze applicatieconnectie aanvraag status 'Open'.

c. Inzien applicatie connectieaanvragen voor de applicatie, gegroepeerd op status ('Open' bovenaan, daaronder 'Goedgekeurd', daaronder 'Geweigerd') en gesorteerd op aflopende datum (nieuwste aanvraag boven) met per aanvraag 'Open' en 'Geaccepteerd' de gegevens van de contactpersoon van de applicatie.

d. inzien applicatie instanties die in het domein zitten inclusief details van die applicatie instanties, zoals (één) geselecteerde applicatierol uit de lijst van applicatie rollen van een applicatie, endpoints, etc.

e. Beheren configuratie/instellingen applicatie instanties die in het domein zitten.

f. Inzien subscriptions (applicatie instantie abonnementen) in het domein gegroepeerd op status ('Actief' bovenaan) met details zoals criteria (trigger condities)  en channel.endpoints.

i. Op dit moments kan de domeinbeheerder NIET handmatig subscriptions toevoegen, wijzigen en/of beëindigen. Als domeinbeheerders wel subscriptions KUNNEN toevoegen en wijzigen MOET het (beheer) systeem controleren dat de URL van de channel.endpoints overeenkomt met een (notificatie) endpoint van een applicatie instantie in dat domein.

g. Inzien van de logging m.b.t. op detail wijzigingen van een applicatie (instantie) en applicatie beheerdersaccount.

^[1] Als Itzos zelf al gebruikersnamen moet aanmaken voor de technische werking, dan verwachten we hier een lijst met aangemaakte gebruikersnamen die verder nog niet actief zijn.

BSC - Beheerschermen [draft]

Itzos heeft de opdracht gekregen om Koppeltaal beheerschermen te bouwen. Vanuit VZVZ hebben we de wensen, welke functionaliteit we willen zien per beheerdersrol (systeem, domein of applicatie), beschreven in BRL - Beheerdersrollen. Deze pagina beschrijft welke schermen we willen hebben. Voor alle schermen geldt dat de rol van de beheerder die het scherm gebruikt, bepaalt welke 'Beheer' functies de beheerder ziet of kan gebruiken. 

De volgende beheerschermen worden in hiërarchische volgorde behandeld:

Beheerschermen Loggingview AuditEvents

Concept v0.2, datum 17-4-2023

Dit document beschrijft de gewenste view (uitsluitend lezen) van de AuditEvents voor Beheerders. De logging van mutaties op de beheerschermen wordt hier buiten beschouwing gelaten, evenals de toekomstige stelsellog.

Algemeen:

• Overzichtsscherm wordt standaard leeg getoond. Door zoekactie wordt deze gevuld.

• Resultaat op scherm maximeren tot 100? Met vervolgschermen.

• Totaal resultaat maximeren tot 1000? Anders melding om zoekfilters te verfijnen.

• Sortering standaard van nieuw naar oud.

• Het zoeken zou, net als elke GET actie, een AuditEvent moeten aanmaken.

• Mogelijkheid om van de view een csv bestand te maken.

• Loggingview tonen als onderdeel van een domein (valt dus onder een domein). Wie geautoriseerd is voor het domein kan ook de loggingview gebruiken.

• Boven de kolommen een filter om sortering aan te passen.

Zoeken op:

• Device (resource-origin), zodat op applicatieinstantie gefilterd kan worden.

• Datum/tijd, vanaf - t/m (lastUpdated). Verplicht veld van maken i.v.m. performance. Standaard datum van vandaag t/m vandaag vullen.

• RequestId

• TraceId

• CorrelationId

• Gebeurtenis (type), zodat op type gefilterd kan worden.

• Resultaat (outcome), zodat bijvoorbeeld alleen op fouten (<>0) gefilterd kan worden.

Er moet gezocht kunnen worden op een deel van een gegeven.

Tonen op overzichtsscherm:

• Device (resource-origin)

• Tijdstip (lastUpdated)

• RequestId

• TraceId

• CorrelationId

• Gebeurtenis (type)

• Resultaat (outcome)

Detailscherm toont hele resource AuditEvent in Json format.

Logging per beheerdersrol:

• Systeembeheerder ziet alle logging van alle domeinen, per domein.

• Applicatiebeheerder ziet alle logging van het domein waarin applicatieinstantie 'actief' of 'in onderhoud' is.

• Domeinbeheerder ziet alle logging van het domein.