cdaefa Diskussion:EFA Security Informationsmodell

Aus Hl7wiki
Version vom 17. September 2013, 16:16 Uhr von Jcaumanns (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== Eecim.02.01 == ;Author :mr ;Existing :Zugruffsberechtigungen ;Proposed :Zugriffsberechtigungen == Eecim.02.01 == ;Author :mr ;Exis…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Eecim.02.01

Author
mr
Existing
Zugruffsberechtigungen
Proposed
Zugriffsberechtigungen

Eecim.02.01

Author
mr
Existing
EWFA
Proposed
EFA

Eecim.02.02

Comment
Zur Assertion der angefragten Patienten ID: Ich kann die Argumente zu epSOS und SSO nachvollziehen. Diese wären durch eine von der Identity Assertion getrennte Assertion der relevanten Patienten ID addressierbar. Zum Thema Effizienzgewinn: Wenn ich bei einer reinkommenden Query durch die Patienten ID alle relevanten Policies abfrage, kann ich einen signifikanten Teil der Anfragen ohne Aufbauen des Request Context beantworten. Der Request Context würde ja im EFA Fall (wo die gesamte Akte auf einmal abgefragt wird) eine signifikante Größe haben. Alle Anfragen bei denen der LE kein Teilnehmer ist, benötigen keine Abfrage der kompletten Metadaten, sondern können alleine anhand der Policies, der Action (z.B. RegistryStoredQuery) und der Subject Informationen negativ beantwortet werden. Bevor Dokumente herausgegeben werden, wird natürlich trotzdem die dort referenzierte Patienten ID mit den Policies verglichen, die aufgrund der Patienten ID in der Assertion herangezogen werden. Wenn die Patienten ID in den Policies (die aus der Assertion stammt) anders ist als die Patienten ID in den Dokumenten Metadaten, matcht die XACML Rule nicht und der Zugriff wird nicht gestattet. Solange es wie bei der EFA keine expliziten Deny Regeln (z.B. pat.-spezifisches Blacklisting von bestimmten Ärzten) gibt, besteht hier auch kein Sicherheitsrisiko. TL;DR: Die Pat ID in der Assertion ist als "Hint" aufzufassen, der eine effizientere Verarbeitung gerade bei nicht authorisierten Benutzern führt. (ti, 29.05.2013)
Author
ti
Comment Editor
Cookbook: Identity Assertion mit Verweis auf Patienten ID soll als optional deklariert werden. Profil (hier: EFA) kann dann den Aufbau der Identity Assertion "überschreiben" oder klare Empfehlungen geben.

Eecim.02.02

Comment
"Sofern in der EFA-Einwilligung eines Patienten Organisationen bzw. Organisationseinheiten als EFA-Teilnehmer benannt sind, muss der subjectIdentity-Nachweis weiter Informationen enthalten" Ich würde eine explizite Pflicht zur Organisations-ID vorziehen. Die hier zitierte Regel hiesse das der Identity Provider wissen muss wie die EFA Einwilligung strukturiert ist, d.h. ob darin nur Individuen oder auch Organisationen berechtigt werden (Sofern ... muss ...). Es muss ja auch nicht unbedingt eine OID sein. (ti, 29.05.2013)
Author
ti

Eecim.02.02

Comment
Die Inkonsistenz zum Cookbook muss ausgeräumt werden, da ansonsten der Profilieruingsmechanismus nicht greift.

Die einfachste Variante dürfte daher sein, diesen Mechanismus im Cookbook als optional aber empfohlen zu beschreiben.

Author
fo
Comment Editor
Im Cookbook als optional definieren