cdaefa:EFA Security Informationsmodell - Versionsgeschichte

Jcaumanns: /* subjectIdentity */

2016-02-14T10:12:17Z

‎subjectIdentity

Jcaumanns: Markup-Fehler behoben

2015-01-26T15:59:47Z

Markup-Fehler behoben

Jcaumanns: Querverweise

2015-01-13T17:34:25Z

Querverweise

Jcaumanns: Seitentemplate an Konvention angepasst.

2014-09-09T13:45:56Z

Seitentemplate an Konvention angepasst.

Jcaumanns: /* accessToken */ Beschreibung hinzugefügt.

2014-04-08T09:38:11Z

‎accessToken: Beschreibung hinzugefügt.

Jcaumanns: /* subjectAccessPolicy */

2013-11-17T16:09:11Z

‎subjectAccessPolicy

Jcaumanns: /* context */

2013-11-11T15:39:38Z

‎context

Jcaumanns: /* context */

2013-11-11T15:38:57Z

‎context

Jcaumanns: /* subjectIdentity */

2013-06-14T10:50:15Z

‎subjectIdentity

Jcaumanns: /* subjectIdentity */

2013-04-28T07:05:52Z

‎subjectIdentity

@@ Zeile 36: / Zeile 36: @@
 Sofern weitere Sicherheitsnachweise über ein ''context''-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das ''subjectIdentity''-Objekt gebunden sein, da nur so eine integre und authentische [[cdaefa:Kontext,_Akte,_Ressource#Kontext|Nachweis-Kette]] aufgebaut werden kann.
-==== subjectIdentity ====
+==== ecrParticipant ====
-Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen. Es wird mit jeder Anfrage an einen EFA-Dienst übermittelt und soll es dem aufgerufenen Dienst ermöglichen, den Aufrufer zu authentisieren und dessen Berechtigungen anhand der verfügbar gemachten Informationen auszuwerten und durchzusetzen.
+Dieses Sicherheitsobjekt fasst Informationen zu einem EFA-Teilnehmer zusammen und dient dessen eindeutiger Identifizierung im Kontext eine konkreten Fallakte. Ein EFA-Teilnehmer ist dabei immer eine Organisation oder eine einer Organisation zugeordnete Person.
-In einem ''subjectIdentity'' Nachweis müssen mindestens die folgenden Informationen enthalten sein:
+In der Klasse ''ecrParticipant''werden die folgenden Informationen zu einem EFA-Teilnehmer zusammengefass:
 ;ID des EFA-Teilnehmers
-: Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In der subjectIdentity muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert (bzw. idealerweise sogar identisch ist).
+:Bei der Abbildung einer Patienteneinwilligung auf Berechtigungsregeln werden EFA-Teilnehmer durch eine eindeutige ID repräsentiert. In einem ''ecrParticipant''-Nachweis muss ein eindeutiger Identifier des EFA-Teilnehmers enthalten sein, der zu der aus der Einwilligung abgeleiteten ID des Teilnehmers korrespondiert.
 ;Name des EFA-Teilnehmers
-: Anhand der im Audit Trail zu Datenschutzzwecken protokollierten Aktenzugriffe muss der Patient Information darüber erhalten können, wer wann und wieso auf welche Daten des Patienten zugegriffen hat. In der subjectIdentity muss der Klartextname des EFA-Teilnehmers (als Person) enthalten sein, da diese Information für das Schreiben eines auch für den Patienten nachvollziehbaren Zugriffsprotokoll benötigt wird.
+:Zur besseren Nachvollziehbarkeit der Überführung einer Papier-Einwilligung auf eine elektronische Einwilligungsdokumentation, muss dort der Name des berechtigten Teilnehmers wie in der Einwilligung angegeben enthalten sein.
 ;Art der Authentifizierung und authentifizierende Stelle
-: Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe [[cdaefa:Prinzipien_für_Datenschutz_und_Datensicherheit#Policy_Enforcement_dicht_an_den_Ressourcen|EFA Sicherheitsprinzipien]]). Hierzu gehört, dass der Provider die Vertrauenswürdigkeit einer ggf. an anderer Stelle vorgenommenen Authentifizierung bewerten können muss. Aus diesem Grund muss die subjectIdentity sichtbar machen, wie sich der EFA-Teilnehmer  authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
+: Jeder EFA-Provider ist für den Schutz der bei ihm verwalteten Daten verantwortlich (siehe [[cdaefa:Prinzipien_für_Datenschutz_und_Datensicherheit#Policy_Enforcement_dicht_an_den_Ressourcen|EFA Sicherheitsprinzipien]]). Hierzu gehört, dass der Provider die Vertrauenswürdigkeit einer ggf. an anderer Stelle vorgenommenen Authentifizierung bewerten können muss. Aus diesem Grund muss ein ''ecrAuthenticatedUser''-Objekt sichtbar machen, wie sich der EFA-Nutzer authentifiziert hat und welche Stelle die Richtigkeit und Sicherheit dieser Authentifizierung abgesichert hat.
-;Prüfdaten zur Feststellung der Authentizität des EFA-Teilnehmers
+;Prüfdaten zur Feststellung der Authentizität des EFA-Nutzers
-: Ein EFA-Provider muss verifizieren können, dass die einen Dienst aufrufende Person der EFA-Teilnehmer ist, für den er/sie sich ausgibt. Entsprechende Prüfdaten müssen fest an die subjectIdentity gebunden sein.
+: Ein EFA-Provider muss verifizieren können, dass die einen Dienst aufrufende Person der EFA-Teilnehmer ist, für den er/sie sich ausgibt. Entsprechende Prüfdaten müssen fest an ein ''ecrAuthenticatedUser''-Objekt gebunden sein.
-;Prüfdaten zur Feststellung der Authentizität und Integrität der ''subjectIdentity''
+;Prüfdaten zur Feststellung der Authentizität und Integrität des ''ecrAuthenticatedUser''-Objekts
-: Eine Verifizierbarkeit der Daten eines subjectIdentity ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jede subjectIdentity von der ausstellenden Stelle signiert werden.
+: Eine Verifizierbarkeit der Daten eines ''ecrAuthenticatedUser''-Objekt ist nur gegeben, wenn die subjectIdentity selbst integer und authentisch ist. Daher muss jedes ''ecrAuthenticatedUser''-Objekt von der ausstellenden Stelle signiert werden.
 {{AlertBox|
-Hier besteht noch eine Inkonsistenz zum ''IHE Cookbook''. Das Cookbook verlangt, dass eine Identity Assertion einen Verweis auf den Patienten enthält, um so bestehende Schwachstellen von IHE XDS auffangen zu können. Die EFA 2.0 Spezifikation schließt einen solchen Verweis zwar nicht aus, sieht diesen aber auch nicht als verpflichtenden Bestandteil einer ''subjectIdentity'' (logisches Pendant zur Identity Assertion). Die Gründe hierfür sind:
+Hier besteht noch eine Inkonsistenz zum ''IHE Cookbook''. Das Cookbook verlangt, dass eine Identity Assertion einen Verweis auf den Patienten enthält, um so bestehende Schwachstellen von IHE XDS auffangen zu können. Die EFA 2.0 Spezifikation schließt einen solchen Verweis zwar nicht aus, sieht diesen aber auch nicht als verpflichtenden Bestandteil einer ecrAuthenticatedUser vor (logisches Pendant zur Identity Assertion). Die Gründe hierfür sind:
-* auf der logischen Ebene repräsentiert die ''subjectIdentity'' die ''Subject Domain'' des IHE 5-Domänen-Modells, die Beziehung zum Patienten ist jedoch Bestandteil der ''Context Domain'' und sollte daher - analog z.B. zu epSOS - in einer diese Domain abbildenden separaten Assertion erfasst werden.
+* auf der logischen Ebene repräsentiert der ''ecrAuthenticatedUser'' die ''Subject Domain'' des IHE 5-Domänen-Modells, die Beziehung zum Patienten ist jedoch Bestandteil der ''Context Domain'' und sollte daher - analog z.B. zu epSOS - in einer diese Domain abbildenden separaten Assertion erfasst werden.
-* EFA zielt auf eine bestmögliche Unterstützung eines Single Sign-On ab. Ein Arzt soll in der Lage sein, innerhalb eines definierten Zeitraums mit einer einmal ausgestellten ''subjectIdentity'' auf Daten und Anwendungen zu verschiedenen Patienten zugreifen zu können.
+* EFA zielt auf eine bestmögliche Unterstützung eines Single Sign-On ab. Ein Arzt soll in der Lage sein, innerhalb eines definierten Zeitraums mit einer einmal ausgestellten ''ecrAuthenticatedUser Assertion'' auf Daten und Anwendungen zu verschiedenen Patienten zugreifen zu können.
 * Sowohl EFA 2.0 als auch das IHE Cookbook binden Berechtigungen nicht an Patienten, sondern an Ordner bzw. mit Ordnern verknüpfte Attribute (EFA: Patient + Zweck-Codes). Da diese Daten im Registry verwaltet werden, muss in jedem Fall auch beim Aufruf der RetrieveDocument Transaktion ein Registry-Zugriff erfolgen, d.h. es gibt keinen Effizienzgewinn (dieser wäre auch bei Bindung der Rechte an den Patienten nicht zu erzielen, da auch hier gegen das Registry geprüft werden müsste, ob das Dokument überhaupt dem fraglichen Patienten zugeordnet ist).
 <nowiki></nowiki>
 }}
 ==== subjectAccessPolicy ====

@@ Zeile 104: / Zeile 104: @@
 {{NoteBox|'''Referenzen und Querverweise'''
 * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 }}

@@ Zeile 4: / Zeile 4: @@
 ----
-== EFA Sicherheitskontext ==
+== EFA Sicherheitsinformationsmodell ==
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.01}</tt>
@@ Zeile 11: / Zeile 13: @@
 Grundsätzlich macht diese Spezifikation nur wenige Vorgaben, welche Sicherheitsobjekte im Sicherheitskontext abgelegt sind und wie diese Objekte in den Sicherheitskontext gelangen. Hierdurch entkoppelt der über ein [[#context|context-Objekt]] gekapselte Sicherheitskontext die EFA-Anwendungsarchitektur von der darunter liegenden Sicherheitsarchitektur. EFA-Dienste erhalten mit jedem Operationsaufruf eine Kopie des lokalen context-Objekts und können anhand der darin enthaltenen Informationen die eigenen Sicherheitsdienste zur Authentisierung und Autorisierung ausführen.
-== PIM Data Structures ==
+=== PIM Data Structures ===
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.02}</tt>
 Die nachfolgend beschriebenen Objektklassen werden im Rahmen des ''EFA Service Functional Model'' verwendet und bilden das Informationsmodel des ''Platform Independent Model'' der EFA Sicherheitsarchitektur.
-=== context ===
+==== context ====
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.02.01}</tt>
@@ Zeile 34: / Zeile 36: @@
 Sofern weitere Sicherheitsnachweise über ein ''context''-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das ''subjectIdentity''-Objekt gebunden sein, da nur so eine integre und authentische [[cdaefa:Kontext,_Akte,_Ressource#Kontext|Nachweis-Kette]] aufgebaut werden kann.
-=== subjectIdentity ===
+==== subjectIdentity ====
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.02.02}</tt>
@@ Zeile 67: / Zeile 69: @@
 Ein subjectIdentity Nachweis kann weitere Nutzerattribute enthalten. Diese müssen jedoch - im Gegensatz zu den oben aufgeführten Informationen - von dem angefragten Dienst nicht verarbeitet werden.
-=== subjectAccessPolicy ===
+==== subjectAccessPolicy ====
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.02.03}</tt>
@@ Zeile 88: / Zeile 90: @@
 Grundsätzlich können beide Arten von Berechtigungen auch in einem Regelwerk kombiniert werden.
-=== accessToken ===
+==== accessToken ====
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.02.04}</tt>
@@ Zeile 95: / Zeile 97: @@
 Die Struktur des Tokens ist in der EFA-1.2-Spezifikation ''eCR Offline Token - Service Architecture'' definiert.
 * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

@@ Zeile 1: / Zeile 1: @@
-{{Infobox Dokument
+{{DocumentPart
 }}
 ''Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel dienen der Unterstützung des Kommentierungsverfahrens. Bitte geben Sie bei einem Kommentar oder einem Verbesserungsvorschlag zu dieser Spezifikation immer das Kürzel des Abschnitts an, auf den sich Ihr Kommentar bezieht. Alle Kommentare werden in der Lasche "Diskussion" zu der kommentierten Seite gesammelt und gegenkommentiert.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".''
 ----

@@ Zeile 104: / Zeile 104: @@
 === accessToken ===
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.02.04}</tt>
 == Querverweise und Referenzen ==
 * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

@@ Zeile 42: / Zeile 42: @@
 * eine [[#subjectAccessPolicy|subjectAccessPolicy]] beschreibt die Zugriffsberechtigungen des über die ''subjectIdentity'' identifizierten EFA-Teilnehmers.
-In jedem Sicherheitskontext muss genau ein ''subjectIdentity''-Objekt vorhanden sein. Dieses wird durch den [[cdaefa:EFA_Context_Manager_SFM|EFA Context Manager]] im Rahmen der Identifizierung und Authentifizierung des EWFA-Teilnehmers von einem [[cdaefa:EFA_Identity_Provider_SFM|Identity Provider]] ausgestellt. Die Umsetzung des Identity Providers kann flexibel ausgestaltet werden, wodurch nicht nur ein Single Sign-On aus einem Primärsystem heraus sondern auch eine Nutzung der Sicherheitsobjekte und -mechanismen der Telematikinfrastruktur unterstützt werden (siehe [[cdaefa:EFA_Context_Manager_SFM#Optionen_zur_Authentisierung_von_EFA-Teilnehmern_.28nicht-normativ.29|Optionen zur Authentifizierung von EFA-Teilnhemern]]).
+In jedem Sicherheitskontext muss genau ein ''subjectIdentity''-Objekt vorhanden sein. Dieses wird durch den [[cdaefa:EFA_Context_Manager_SFM|EFA Context Manager]] im Rahmen der Identifizierung und Authentifizierung des EFA-Teilnehmers von einem [[cdaefa:EFA_Identity_Provider_SFM|Identity Provider]] ausgestellt. Die Umsetzung des Identity Providers kann flexibel ausgestaltet werden, wodurch nicht nur ein Single Sign-On aus einem Primärsystem heraus sondern auch eine Nutzung der Sicherheitsobjekte und -mechanismen der Telematikinfrastruktur unterstützt werden (siehe [[cdaefa:EFA_Context_Manager_SFM#Optionen_zur_Authentisierung_von_EFA-Teilnehmern_.28nicht-normativ.29|Optionen zur Authentifizierung von EFA-Teilnhemern]]).
 Eine ''subjectAccessPolicy'' ist nur bei Verwendung eines ''Policy-Push'' Verfahrens Bestandteil des Sicherheitskontextes. Ansonsten erfolgt der Abruf von Berechtigungsregeln on demand über den EFA-Dienst, der die angefragte Ressource verwaltete.

@@ Zeile 40: / Zeile 40: @@
 Die nebenstehende Abbildung stellt den Aufbau der context-Klasse dar:
 * eine [[#subjectIdentity|subjectIdentity]] kapselt die Identität des EFA-Teilnehmers und sichert bei Dienstaufrufen die Authentizität des EFA-Teilnehmers ab.
-* eine [[#subjectAccessPolicy|subjectAccessPolicy]] beschreibt die Zugruffsberechtigungen des über die ''subjectIdentity'' identifizierten EFA-Teilnehmers.
+* eine [[#subjectAccessPolicy|subjectAccessPolicy]] beschreibt die Zugriffsberechtigungen des über die ''subjectIdentity'' identifizierten EFA-Teilnehmers.
 In jedem Sicherheitskontext muss genau ein ''subjectIdentity''-Objekt vorhanden sein. Dieses wird durch den [[cdaefa:EFA_Context_Manager_SFM|EFA Context Manager]] im Rahmen der Identifizierung und Authentifizierung des EWFA-Teilnehmers von einem [[cdaefa:EFA_Identity_Provider_SFM|Identity Provider]] ausgestellt. Die Umsetzung des Identity Providers kann flexibel ausgestaltet werden, wodurch nicht nur ein Single Sign-On aus einem Primärsystem heraus sondern auch eine Nutzung der Sicherheitsobjekte und -mechanismen der Telematikinfrastruktur unterstützt werden (siehe [[cdaefa:EFA_Context_Manager_SFM#Optionen_zur_Authentisierung_von_EFA-Teilnehmern_.28nicht-normativ.29|Optionen zur Authentifizierung von EFA-Teilnhemern]]).