cdaefa Diskussion:EFA Security Informationsmodell
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…“)
Inhaltsverzeichnis
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