AC Treatment-Assertion¶
Wie in ELGA generell üblich, wird auch für den AC eine Treatment-Assertion für die AGW zu AGW Kommunikation verwendet. Dem Prinzip aus ELGA folgend, wird auch die AC Kontext-Treatment-Assertion von der initiierenden ZGF beim ETS angefordert. Das ETS führt dann – je nach angegebenen Optionen/Parametern – für den AC spezifische Prüfungen wie Validieren eines Kontaktes, Prüfung gegen einen Patientenindex oder Durchsetzen von generellen oder individuellen AC Policies durch.
Im Konfigurationsabschnitt für den AC sind Details, die Auswirkungen auf die Prüfungen beim Ausstellen von AC Treatment-Assertions haben, zu finden.
Autorisierung mittels AC Treatment-Assertion¶
Die Autorisierung erfolgt am ETS beim Ausstellen einer AC Treatment-Assertion auf Basis einer AC Kontext-Assertion. Abhängig von der Art des AC wird hier vom ETS eine generelle rollenbasierte XACML Policy durchgesetzt, welche die rollenbasierte Berechtigungsmatrix an Berechtigungen abbildet. Die Daten für die XACML Anfrage werden vom ETS der empfangenen AC Kontext-Assertion (Permissions) und der WS Trust Anfrage der initiierenden ZGF (Aktion) entnommen. Vom BeS wird bereits beim Ausstellen der AC Treatment-Assertion die jeweilige Rolle auf Permissions umgewandelt. Diese Permissions werden nachfolgend für die Berechtigungsprüfung zum Durchsetzen der Policies herangezogen.
Weiters werden abhängig vom jeweiligen AC vom ETS Teilnehmerberechtigungen, die mittels BPPC Dokument eingebracht wurden, durchgesetzt, bevor eine AC Kontext-Treatment-Assertion ausgestellt wird.
Es wird hierbei eine spezifische rollenbasierte AC Policy durchgesetzt, die losgelöst von der generellen ELGA Policy ist.
Die Attribute der AC Treatment-Assertion sind bis auf die nachfolgenden Angaben mit denen im "ELGA BeS Pflichtenheft" Kapitel Treatment-Assertion ident:
| Purpose of Use | |
|---|---|
| FriendlyName: | BeS Purpose of Use |
| Name: | urn:oasis:names xspa:1.0:subject:purposeofuse |
| Values: | E-HEALTH-CONTEXT^\<AC-APP-ID> |
| Type: | String |
| Source: | Input AC Kontext-Assertion Purpose of Use |
| Anmerkung: | Beinhaltet nicht wie in eBefund "TREATMENT" sondern kennzeichnet die eHealth Applikation |
| AC Purpose | |
|---|---|
| FriendlyName: | AC Purpose |
| Name: | urn:oasis:namesxacml:2.0:action:purpose |
| Values: | PUBLICHEALTH |
| Type: | String |
| Source: | Input AC Kontext-Assertion AC Purpose |
| Anmerkung: | Beinhaltet den originalen Purpose of Use der initialen Identity Assertion |
| AC Endpoint | |
|---|---|
| FriendlyName: | AC Endpoint |
| Name: | urn:elga:bes:2019:ac-wse |
| Values: | https://app1Backend/repo, https://app1Backend/reg |
| Type: | String |
| Source: | Zentrale AC Container Konfiguration |
| Anmerkung: | Beinhaltet die Endpunkte der AC Fachlogik |
| ELGA Personal Role | |
|---|---|
| FriendlyName: | ELGA Personal Role |
| Name: | urn:elga:bes:personal-role |
| Values: | Rolle der identifizierten Person laut: ELGA_GTelVoGDARollen - Austrian e-Health Terminology Browser - mit dem parent Attribut „10 Teil1: Rollen für Personen“ |
| Type: | String |
| Source: | ELGA Personal Role aus der AC-Kontext-Assertion auf deren Basis die AC-Treatment-Assertion ausgestellt wurde |
Beispiel AC Treatment-Assertion.xml
Wandeln von Rolle auf Permissions¶
Zum Wandeln von Rollen auf Permissions, wird das AC Import XML für den jeweiligen AC bereitgestellt. Die Permissions werden in der AC Kontext-Assertion und in die Treatment-Assertion übernommen.
Weitere Informationen zum Wandeln von Rollen kann in Kapitel Konfiguration eines AC gefunden werden.
AC XACML Policy¶
Es wird für den jeweiligen AC eine rollen- bzw. permissionbasierte XACML Policy bereitgestellt.
Nachfolgend als Beispiel die vom BeS verwendete XACML Policy, die durchgesetzt wird, wenn eine AC Treatment-Assertion ausgestellt wird. Die derzeit verwendeten Obligations haben keinen funktionalen Hintergrund, sondern dienen ausschließlich der einfacheren Fehlersuche.