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

...

Inleiding

Dit document beschrijft de entiteiten en bevoegdheden op de beheerschermen. De beheerschermen bevat o.a. gegevens van domeinen, applicaties, applicatieinstanties, gebruikers (beheerders), applicatierollen, en logging. Verschillende gegevens zijn tevens bepalend voor 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.

...

.

Vooraf zijn vanuit discussie tussen testteam en architectuur verschillende eisen en wensen aangegeven. Tijdens het ontwikkelproces met Itzos zijn hierop enkele aanpassingen of keuzes gemaakt om een werkbaar geheel te krijgen. Voor logging van de beheerschermen waren de eisen zeer minimaal en is de logging naar beste inzicht vorm gegeven.

Beschrijving

Applicatierollen en autorisatieregels (zie ook KT-TOP-005).

Rollen en autorisatieregels kunnen vastgelegd worden. De naam van de rol is uniek en niet wijzigbaar. Binnen de rol moet per resource vastgelegd kunnen worden of een Create, Read, Update en Delete actie is toegestaan. Daarnaast moet bij Read, Update en Delete aangegeven worden of dit alleen voor de resource is toegestaan die de applicatieinstantie zelf heeft aangemaakt (OWN), of dat de applicatieinstantie de actie op al deze resources in hetzelfde domein mag uitvoeren (ALL).

Dit is een domein- en applicatie onafhankelijke taak. Vastlegging wordt uitgevoerd door Support (de systeembeheerder).

N.B. De 'GRANTED' optie is i.v.m. complexiteit niet gebouwd in de Itzos omgeving.

N.B. Er zijn nog geen procesafspraken gemaakt over hoe we in de praktijk om moeten gaan met rollen en autorisatieregels. Voor nu gaan we uit van een rol die beperkt is tot de resources (en de CRUD acties hierop) die gelijk is aan waarvoor applicatie geaccepteerd is/wordt.

N.B. Het is nog niet mogelijk om applicatierollen, die niet in gebruik zijn, te beëindigen/verwijderen. (bevinding)

Domein

Het domein bevat (minimaal) de volgende gegevens/attributen:

...

• Een unieke domein identifier

...

• . (Deze is aanwezig, maar niet zichtbaar op het scherm.)
• Een (leesbare) naam

...

• van 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)

...

• . (verplicht, en niet wijzigbaar).
  • Maximaal 32 karakters.
  • Toegestaan: alfanumeriek, spatie, uitroepteken, underscore, minteken en punt.
• Url van de autorisatieserver (verplicht, begint met 'https'). (Eventuele spaties en hoofletters zijn uit domeinnaam verwijderd. Dit geldt ook voor de urls hieronder.)
• Url van de endpoint van de autorisatieserver (verplicht, begint met 'https').
• Url van de FHIR server (verplicht, begint met 'https').
• Contactpersoon voor het domein :
  • Naam (verplicht)
  • Email (verplicht)
  • Telefoonnummer (optioneel).

Daarbij bevat het domein ook gegevens van de bijbehorende domeinbeheerders, applicatieinstanties, connectieaanvragen en logging.

N.B. Het domein kan ingevoerd worden door de systeembeheerder nadat Itzos ook het complexe proces aan de 'achterkant' van het domein heeft ingericht. Een nieuw domein moet dus altijd aangevraagd worden bij Itzos.

N.B. Het vullen van de drie technische velden (autorisatieserver, endpoint autorisatieserver en FHIR server) wordt bij aanmaken domein niet afgedwongen. Dit is procedureel opgelost.

Applicatie

De applicatie bevat (minimaal) de volgende gegevens/attributen:

...

• Een unieke

...

• applicatie identifier. (Deze is aanwezig, maar niet zichtbaar op het scherm.)
• Een (leesbare) naam van de

...

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.

e. Contact gegevens voor de rolbeschrijving

i. contactpersoon

ii. e-mail adres/telefoon

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.

...

• applicatie (verplicht, en niet wijzigbaar).
  • Maximaal 32 karakters.
  • Toegestaan: alfanumeriek, spatie, uitroepteken, underscore, minteken en punt.
• (Deze wordt automatisch gevuld bij aanmaken en is niet wijzigbaar.)
• Eén of meer rollen. Te selecteren uit de lijst van (actieve) rollen. Minimaal 1 rol verplicht. (Bevinding: Deze is na aanmaken van de applicatie niet meer te wijzigen.)
• Contactpersoon voor de applicatie :
  • Naam (verplicht)
  • Email (verplicht)
  • Telefoonnummer (optioneel).

Daarbij bevat de applicatie ook gegevens van de bijbehorende applicatiebeheerders en connectieaanvragen.

Applicatieinstantie

Een applicatieinstantie is geen zelfstandige eenheid, maar de entiteit van de applicatie binnen een domein. Deze ontstaat als de applicatiebeheerder en zgn. connectieaanvraag doet vanuit de applicatie (status 'Actief' of 'In onderhoud') aan een domein, en de domeinbeheerder van dat domein deze connectieaanvraag (met status 'open') accepteert.

Een geaccepteerde connectieaanvraag wordt een applicatieinstantie en krijgt daarmee ook een ClientID en een resource Device. (In Itzos omgeving heeft het Device dezelfde id als de ClientID van de applicatieinstantie.). De connectieaanvraag is verdwenen uit de lijst van connectieaanvragen.

Indien de domeinbeheerder de connectieaanvraag weigert, dan wordt er geen applicatieinstantie aangemaakt en wordt dus de toegang tot het domein geweigerd. De connectieaanvraag blijft in de lijst van connectieaanvragen staan met de status 'geweigerd', en kan ook niet meer geaccepteerd worden.

Indien de applicatie reeds een connectieaanvraag heeft gedaan, dus bij status 'open', 'geaccepteerd' of 'geweigerd', is het niet meer mogelijk voor de applicatie een nieuwe connectieaanvraag te doen. De volgende melding verschijnt:  'Applicatieinstantie bestaat al.' Indien de aanvraag is afgewezen, verschijnt melding: “Er is eerder een connectieaanvraag ingediend. Het is niet mogelijk dit nogmaals te doen.”.

Een connectieaanvraag kan niet geaccepteerd worden als de applicatie de status 'Afgesloten' heeft. De volgende melding verschijnt bij het accepteren: "De Connectieaanvraag kan niet geaccepteerd worden, de applicatie heeft de status 'Afgesloten'."

Note: De systeembeheerder kan beide acties ook uitvoeren, maar mag dat procedureel níet.

Connectieaanvraag bevat (minimaal) de volgende gegevens/attributen:

• 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. Veld bevat controle of deze bereikbaar is. Getoonde melding: 'De JWKS URL is niet bereikbaar; controleer of de URL correct is.' Er zal geen controle plaatsvinden als het veld leeg gelaten wordt. Reden voor het leeg laten van het veld kan zijn als IT-deelnemer het ClientId van de applicatieinstantie nodig heeft om een JWKS uri aan te maken. De JWKS uri moet daarna alsnog toegevoegd worden aan de applicatieinstantie om deze te kunnen gebruiken. 
• De redirect_uri(s). Max. 3 uri's mogelijk. Is optioneel veld, maar moet wel ingevuld worden om een SHOF launch uit te kunnen voeren.
• De applicatienaam (wordt automatisch overgenomen en is niet wijzigbaar).
• Eén rol die gekoppeld is aan de applicatie. Het is niet mogelijk om een andere rol te selecteren, dan die bij de applicatie is vastgelegd.
• Domein waarnaar de connectieaanvraag gestuurd wordt. Het domein wordt geselecteerd uit een lijst van domeinen met status 'Actief' en 'In onderhoud'.

Indien de connectieaanvraag is ingediend, zijn alleen de velden JWKS uri en status aan te passen door geautoriseerden. De andere velden zijn niet muteerbaar.

Een ingediende connectieaanvraag krijgt automatisch een (leesbare) naam voor de aan te maken applicatieinstantie (zie onder 'applicatieinstantie').

Mailnotificatie connectieaanvraag:

• Het indienen van een connectieaanvraag resulteert in een mailnotificatie naar alle domeinbeheerders die vastgelegd zijn bij het domein uit de connectieaanvraag.
  • Onderwerp: Nieuwe connectieaanvraag voor domein <domeinnaam> op <omgeving>
  • Tekst: Er is een connectieaanvraag ingediend voor applicatie <applicatienaam> in uw domein <domeinnaam>.
• Het accepteren van een connectieaanvraag resulteert in een mailnotificatie naar de indiener van de connectieaanvraag.
  • Onderwerp: Connectieaanvraag geaccepteerd.
  • Tekst: Uw aanvraag om applicatie <applicatienaam> toe te voegen aan domein <domeinnaam> is geaccepteerd.
  • Voor de applicatie-domein combinatie zijn de volgende gegevens geregistreerd:

Applicatieinstantie: <naam applicatieinstantie>

Client-Id: <client-id>.

Omgeving: <omgeving>

• Het weigeren van een connectieaanvraag resulteert in een mailnotificatie naar alle applicatiebeheerders die vastgelegd zijn bij de applicatie.
  • Onderwerp: Connectieaanvraag geweigerd
  • Tekst: Uw aanvraag om applicatie <applicatienaam> toe te voegen aan domein <domeinnaam> op <omgeving> is afgewezen.

Voor deze functionaliteit is de omgeving uitgebreid met een mailserver.

De applicatieinstantie bevat (minimaal) de volgende gegevens/attributen:

a. Een uniek (uitgegeven) client identifier

b. Een (leesbare) naam

...

• Een unieke client identifier (Client ID) (format: UUID).
• Een (leesbare) naam (format: <applicatienaam>@<domeinnaam>, max 128 karakters, wordt automatisch gegenereerd en is niet wijzigbaar).
• Een (logische) naam

...

• .

...

• (Deze is aanwezig, maar niet zichtbaar op het scherm.)
• De JWKS uri. Is een unieke

...

e. Een domein Identifier.

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

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.

Image Removed

Enkele definities:

• Applicatie. Software of (geautomatiseerd) proces.
• Persoon. Een persoon (van vlees en bloed) die rechten en plichten heeft.
• 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 informatieresource identifier dat refereert naar een applicatie JSON Web Key Set bestand dat (roulerende) publieke sleutels van de applicatie bevat.
• De redirect_uri(s). Max. 3 uri's mogelijk. Is optioneel veld, maar moet wel ingevuld worden om een SHOF launch uit te kunnen voeren.
• De domeinnaam.
• De applicatienaam.
• De rol.

Het overzicht van applicatieinstanties bevat ook een datum van aanmaken, maar dit is geen onderdeel van het detailscherm.

Logging - view AuditEvents

In het domein is het mogelijk om de resource AuditEvent in te zien. Iedere beheerder die toegang heeft tot het domein, kan de AuditEvents inzien. Ook als het domein de status 'afgesloten' heeft.

Algemeen:

• Het overzichtsscherm wordt standaard met een lege respons getoond en pas gevuld na het invoeren van een zoekactie.
• Er wordt maximaal 100 resultaten getoond op het scherm, met vervolgschermen tot maximaal 1000 resultaten. Levert de zoekopdracht meer dan 1000 resultaten op dan verschijnt een melding om de zoekfilters te verfijnen.
• Sortering is standaard op datum van nieuw naar oud.
• Het zoeken moet, net als elke GET actie, een AuditEvent aanmaken.
• Het moet mogelijk zijn om van de resultaten van de zoekopdracht een csv bestand te maken. (Dit bevat dus alleen de informatie van het overzicht, niet van de details. Bevat dus max. 1000 records.)

Het overzichtsscherm logging bevat de volgende gegevens boven de kolommen:

• DeviceId (resource-origin)
• Datum (lastUpdated)
• RequestId
• TraceId
• CorrelationId
• Actie (type)
• Resultaat (outcome)

Het detailscherm toont de hele resource AuditEvent in Json format.

Zoeken van de logging is mogelijk op:

• DeviceId (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.
• Actie (type), zodat op type gefilterd kan worden.
• Resultaat (outcome), zodat bijvoorbeeld alleen op fouten (<>0) gefilterd kan worden.

Logging - Beheerschermen

De applicatie Beheerschermen bevat een loggingscherm van de acties die op de beheerschermen worden uitgevoerd. Dit betreft het inloggen en uitloggen van beheerders, en alle create, update en delete acties die op de gegevens in de beheerschermen worden uitgevoerd.

Algemeen:

• Het overzichtsscherm wordt standaard met een lege respons getoond en pas gevuld na het invoeren van een zoekactie.
• Sortering is standaard op datum van nieuw naar oud.

Het overzichtsscherm logging bevat de volgende gegevens boven de kolommen:

• Datum/tijd.
• Resultaat.
• Gebruiker.
• Actie.

Het detailscherm toont de hele logging in Json format. De inhoud is afhankelijk van het soort logging.

Zoeken van de logging is mogelijk op:

• Datum/tijd, vanaf - t/m. Verplicht veld i.v.m. performance. Standaard datum van vandaag t/m vandaag vullen.
• Er kan geselecteerd worden uit een lijst, waarin gekozen kan worden voor logging van acties die goed gegaan zijn, of acties die fout gegaan zijn.
• Vrij veld waar de user van de beheerder ingevuld kan worden. De volledige user moet ingevoerd worden.
• Er kan geselecteerd worden uit een lijst met verschillende activiteiten.

N.B. De logging van foute inlog door beheerders is niet opgenomen in de logging van de Beheerschermen. Dit wordt gelogd in de tooling van KT Support.

BEB - Eisen (en aanbevelingen) Beheren van entiteiten en bevoegdheden

{}