KOP-838 KT2 Documentatie: Bijwerken topics
- Kees Graveland
Links naar bijbehorende tickets
Jira ticket | |
Github ticket |
|
Wijzigingen
Zet bij de locatie de link naar de confluence pagina van de te wijzigen topics. Is het een tabel benoem dan bij de locatie ook de rij van de tabel .
Kopieer voor de oude en de nieuwe tekst de zin(nen) die aangepast moeten worden inclusief de regel ervoor en de regel erna.
In de kolom “Oude tekst”, maak de verwijderde of gewijzigde stukken rood en streep ze door
In de kolom “Nieuwe tekst” voer de wijzigingen door in de tekst en geef de nieuwe stukken een groene kleur.
Locatie | Oude tekst | Nieuwe tekst |
|---|---|---|
TOP-KT-023 - Identity Provisioning | IdP per user type In het architectuurbesluit AB.017 - Authenticatie van de gebruiker tijdens de launch is tevens opgenomen dat de configuratie van de IdentityProvider op de combinatie domein, applicatie-instantie en user type plaatsvindt, vooralsnog zijn dat Patient en Practitioner. Het moet dus mogelijk zijn om per user type een andere IdP in een domein toe te wijzen. Dit is noodzakelijk omdat het vaak voorkomt dat medewerkers in een domein een andere IdP gebruiken dan de cliënten. Op zich zou dit opgelost kunnen worden door een vorm van federatie ter hoogte van de IdP, echter, de autorisatie service heeft inzicht in de FHIR resources betrokken in de launch, en kan zo met meer informatie de beslissing nemen bij welke IdP de gebruiker zich moet aanmelden. | In het architectuurbesluit AB.017 - Authenticatie van de gebruiker tijdens de launch is tevens opgenomen dat de configuratie van de IdentityProvider op de combinatie domein, applicatie-instantie en user type plaatsvindt, dit betreft de vooralsnog zijn dat Patient en Practitioner en RelatedPerson. Het moet dus mogelijk zijn om per user type een andere IdP in een domein toe te wijzen. Dit is noodzakelijk omdat het vaak voorkomt dat medewerkers in een domein een andere IdP gebruiken dan de cliënten en zijn/haar Naasten. Afhankelijk van de Rol van de Naaste zijn kan het zijn dat ook gebruik gemaakt moeten kunnen worden van verschillende IdP’s voor de verschilllende rollen van de Naaste. Op zich zou dit opgelost kunnen worden door een vorm van federatie ter hoogte van de IdP, echter, de autorisatie service heeft inzicht in de FHIR resources betrokken in de launch, en kan zo met meer informatie de beslissing nemen bij welke IdP de gebruiker zich moet aanmelden. Het onderscheid op de verschillende IdP’s voor de verschillende rollen van de Naaste moet nog nader worden uitgewerkt in het Koppeltaal Profiel van de RelatedPerson | |
| TOP-KT-023 - Identity Provisioning | Configuratie in het domein De configuratie van de Identity Provider (IdP) vindt plaats in het domeinbeheer, de authorization service maakt gebruik van deze configuratie om tijdens de SAMRT on FHIR app launch procedure de user agent op de juiste manier te authenticeren. De configuratie van de IdP gebeurt op de combinatie domein - applicatieinstantie - gebruikerstype. Op de combinatie van de volgende drie kenmerken wordt de configuratie van de Identity Provisioning vastgesteld:
Afhankelijk van de implementatie kan er gewerkt worden met defaults, zo is het logisch per domein - gebruikerstype een default in te kunnen stellen, en deze dan per applicatie optioneel te kunnen configureren. Dit om de complexiteit van de configuratie terug te brengen. Op dit niveau wordt vastgesteld:
Het is de verantwoordelijkheid van het domeinbeheer deze configuratie mogelijk te maken, de authrosiatieservice maakt van deze configuratie gebruik om de SMART on FHIR app launch uit te voeren. | De configuratie van de Identity Provider (IdP) vindt plaats in het domeinbeheer, de authorization service maakt gebruik van deze configuratie om tijdens de SAMRT on FHIR app launch procedure de user agent op de juiste manier te authenticeren. De configuratie van de IdP gebeurt op de combinatie domein - applicatieinstantie - gebruikerstype. Op de combinatie van de volgende drie kenmerken wordt de configuratie van de Identity Provisioning vastgesteld:
Afhankelijk van de implementatie kan er gewerkt worden met defaults, zo is het logisch per domein - gebruikerstype een default in te kunnen stellen, en deze dan per applicatie optioneel te kunnen configureren. Dit om de complexiteit van de configuratie terug te brengen. Op dit niveau wordt vastgesteld:
Het is de verantwoordelijkheid van het domeinbeheer deze configuratie mogelijk te maken, de authrosiatieservice maakt van deze configuratie gebruik om de SMART on FHIR app launch uit te voeren. |