Gruppierung von Anwendungs- und Sicherheitsdiensten
K |
(→Querverweise und Referenzen) |
||
| Zeile 41: | Zeile 41: | ||
| | Authorization Requestor || Für eine Zugriffsentscheidung zur Herausgabe eines Dokuments wird über den Authorization Requestor Akteur eine Autorisierungsanfrage an den Authorization Decision Provider Akteur des EFA-Registers gestellt. | | | Authorization Requestor || Für eine Zugriffsentscheidung zur Herausgabe eines Dokuments wird über den Authorization Requestor Akteur eine Autorisierungsanfrage an den Authorization Decision Provider Akteur des EFA-Registers gestellt. | ||
|} | |} | ||
| + | |||
| + | === Policy Pull === | ||
| + | |||
| + | Jeder EFA-Provider muss das im IHE Cookbook beschriebene Verfahren des Policy Pull unterstützen. Hierbei wird vom EFA-Dienst für jede Anfrage die gültige Policy (Berechtigungsregelwerk) ermittelt und ausgewertet. Der EFA Policy Provider zur Verwaltung und Bereitstellung von Berechtigungsregeln ist hierbei ein logischer Dienst, dessen konkrete Umsetzung nicht näher reglementiert ist. Insbesondere ist es dem Hersteller der EFA-Aktendienste überlassen, wie er eine Einwilligungserklärung in eine Policy übersetzt und wie er diese bei einem Aktenaufruf ermittelt und auswertet. | ||
| + | |||
| + | [[Datei:PIM_SEQ_Policy_Pull.png|480px]] | ||
| + | |||
| + | === Client Policy Push === | ||
| + | |||
| + | Optional kann ein EFA-Provider das in der EFAv1.2 bevorzugt genutzte Policy Push Verfahren unterstützen. Hierbei ruft der Client die für den aktuellen Nutzer gültige Policy für eine zu öffnende Fallakte vom EFA Policy Provider ab. Die Policy wird als Teil des [[cdaefa:EFA_Security_Informationsmodell#context|EFA-Nutzerkontextes]] im Context Manager verwaltet und bei jedem Aufruf eines EFA-Dienstes in Form einer [[cdaefa:EFA_Security_Informationsmodell#subjectAccessPolicy|subjectAccessPolicy]] mitgegeben. | ||
| + | |||
| + | [[Datei:PIM_SEQ_Policy_Push.png|480px]] | ||
| + | |||
=== Querverweise und Referenzen === | === Querverweise und Referenzen === | ||
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] | * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] | ||
Version vom 17. November 2013, 16:36 Uhr
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden Gruppierung von Anwendungs- und Sicherheitsdiensten (0.9). Die Teilmaterialien gehören der Kategorie cdaefa an. |
February 2013
Jörg Caumanns, Raik Kuhlisch
| Version: | 0.9 |
| Datum: | March 2013 |
| Status: | xxx |
| Verfahren: | {{{Verfahren}}} |
| Realm: |  Deutschland
|
Anmerkung: Die Kürzel unter den einzelnen Überschriften 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.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".
Inhaltsverzeichnis
Gruppierung von Anwendungs- und Sicherheitsdiensten
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Gpruw.01}
Die EFA Anwendungs- und Sicherheitsarchitektur ist über eine spezielle Gruppierung von Akteuren miteinander verzahnt. Die nachfolgende Grafik stellt die Beziehungen im Überblick dar.
Aus der Grafik sind die folgenden Gruppierungen ersichtlich:
| Anwendungsdienst bzw. Akteur | Sicherheitsdienst bzw. Akteur | Beschreibung |
|---|---|---|
| EFA-Teilnehmersystem | HP Identity Assertion User | Das EFA-Teilnehmersystem bzw. der Arzt authentisiert sich bei einem konfigurierten EFA Identity Provider, welcher eine HP Identity Assertion als Authentifizierungsnachweis ausstellt. |
| EFA-Register | HP Identity Assertion Consumer | Die HP Identity Assertion ist für die Nutzung des EFA-Registers notwendig. Die Inhalte des Nachweises werden für eine Zugriffskontrollprüfung durch den Authorization Requestor Akteur verwendet. |
| Authorization Requestor | Der Authorization Requestor Akteur stellt eine Autorisierungsanfrage an den Authorization Decision Provider. | |
| Authorization Decision Provider | Der Authorization Decision Provider Akteur wird mit dem EFA-Register gruppiert, da keine standardisierte Schnittstelle vorgesehen ist, über die effizient alle für die Zugriffsentscheidung notwendigen Dokumentenmetadaten transportiert werden können. | |
| EFA-Speichersystem | HP Identity Assertion Consumer | Die HP Identity Assertion ist für die Nutzung des EFA-Speichersystems notwendig. |
| Authorization Requestor | Für eine Zugriffsentscheidung zur Herausgabe eines Dokuments wird über den Authorization Requestor Akteur eine Autorisierungsanfrage an den Authorization Decision Provider Akteur des EFA-Registers gestellt. |
Policy Pull
Jeder EFA-Provider muss das im IHE Cookbook beschriebene Verfahren des Policy Pull unterstützen. Hierbei wird vom EFA-Dienst für jede Anfrage die gültige Policy (Berechtigungsregelwerk) ermittelt und ausgewertet. Der EFA Policy Provider zur Verwaltung und Bereitstellung von Berechtigungsregeln ist hierbei ein logischer Dienst, dessen konkrete Umsetzung nicht näher reglementiert ist. Insbesondere ist es dem Hersteller der EFA-Aktendienste überlassen, wie er eine Einwilligungserklärung in eine Policy übersetzt und wie er diese bei einem Aktenaufruf ermittelt und auswertet.
Client Policy Push
Optional kann ein EFA-Provider das in der EFAv1.2 bevorzugt genutzte Policy Push Verfahren unterstützen. Hierbei ruft der Client die für den aktuellen Nutzer gültige Policy für eine zu öffnende Fallakte vom EFA Policy Provider ab. Die Policy wird als Teil des EFA-Nutzerkontextes im Context Manager verwaltet und bei jedem Aufruf eines EFA-Dienstes in Form einer subjectAccessPolicy mitgegeben.
