EFA Sicherheitsdienste (logische Spezifikation)

Aus Hl7wiki
(Teildokument von CDA für die elektronische Fallakte)
Wechseln zu: Navigation, Suche
(Die Seite wurde neu angelegt: „This section concerns the service functional models of the eCR security services that realize the access control scenario of the electronic Case Record. The follo…“)
 
K (Markup-Fehler behoben)
 
(13 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
This section concerns the service functional models of the eCR security services that realize the access control scenario of the electronic Case Record. The following table gives an overview of the eCR security services and their functionality.
+
{{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]]".''
 +
----
  
{| border="1" cellpadding="4" cellspacing="2"
+
== Sicherheitstoken und Sicherheitstokendienste ==
!Service
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eierz.01}</tt>
!Tasks
+
 
!Persistent Data
+
Jeder EFA-Anwendungsdienst und jeder EFA-Sicherheitsdienst besitzt eine Sicherheitspolitik, in der u. a. definiert ist, wie der Sicherheitskontext aussehen muss, aus dem heraus der Dienst aufgerufen werden kann. Hierdurch „weiß“ ein EFA-Client, welches Sicherheitstoken er von welchem GDD-Sicherheitsdienst abrufen und in den Ablaufkontext laden muss, bevor der gewünschte Dienst aufgerufen werden kann. Dadurch dass auch Sicherheitsdienste Sicherheitspolitiken besitzen, lässt sich die komplette Ablaufsteuerung über den Sicherheitsdiensten deklarativ abbilden. Beispielsweise kann ein EFA-Anwendungsdienst für den Zugriff auf eine Ressource ein Sicherheitstoken verlangen, über das die entsprechende Berechtigung des Nutzers verifizierbar ist. Der dieses Token ausstellende Autorisierungsdienst wiederum kann eine Politik definieren, dass Berechtigungsnachweise nur ausgestellt werden, wenn der Nutzer über ein entsprechendes Token seine Authentizität nachweist, d.h. vor dem Autorisierungsdienst ein Authentifizierungsdienst aufgerufen wurde.
|-
+
 
!Identity Provider
+
Im Rahmen des ''IHE Cookbook'' und der EFA-2.0 Spezifikation werden verschiedene Sicherheitstokendienste (föderierte Authentifizierung, Pseudonymisierung, Zugang zu Anwendungen, Autorisierung auf Ressourcen) spezifiziert, die nach dem oben skizzierten Prinzip von allen Aktendiensten genutzt werden können. Welche Sicherheitsdienste ein Aktendienst in Anspruch nimmt, definiert er über seine Sicherheitspolitk, die im Fachmodul in Aufrufe an die Sicherheitstokendienste übersetzt wird.
|Authenticates user while it verifies the user’s credentials. This service encapsulates the supported authentication methods.  
+
 
|Retrieves supplemental user information as attributes from a directory service. The identities of users (individuals and/or organizations), the verification data of their credentials, and the attributes of the identities.
+
== EFA Sicherheits(token)dienste ==
|-
+
<tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eierz.02}</tt>
!eCR Admission Token Service
+
 
|Calculates the pseudonyms (admission codes) to identify a patient’s records.
+
[[Datei:Sicherheitsdienste_5_Domains.png|480px]]
|no persistent data
+
 
 +
;EFA Identity Provider
 +
:Der EFA Identity Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Teilnehmersystem aufgerufen und stellt einen Identitätsnachweis für authentifizierte Nutzer aus. Dieser Nachweis kann neben  Angaben zu Rollen und Gruppenzugehörigkeiten des Nutzers je nach Sicherheitspolitik auch ein ''Proof-of-Possession'' Merkmal enthalten, über der Provider die Authentizität des Nutzers unmittelbar verifizieren kann (im Gegensatz hierzu wird bei einer mittelbaren Authentizitätsprüfung die Nutzer-Authentizitätsprüfung eines als authentisch geprüften Clientsystems akzeptiert).
 +
 
 +
Der EFA Identity Provider unterstützt potenziell beliebige Verfahren der Authentifizierung (z.B. mittels Passwort, HBA oder SMC-B). Bei einer Authentifizierung mittels HBA werden die Nutzerattribute aus dem HBA-Zertifikat in den Identitätsnachweis übernommen. Zusätzlich wird anhand der genutzten SMC-B die Organisationszugehörigkeit eingetragen. Bei der Authentifizierung mittels SMC-B hat sich der Nutzer bereits innerhalb seiner Organisation sicher authentisiert. Auch alle Attribute wurden bereits durch die Organisation zugewiesen. Beim Aufruf des EFA Identity Providers bestätigt die Organisation die durchgeführte Authentifizierung und die Authentizität der Attribute in Form eines selbst ausgestellten, von der SMC-B signierten Identitätsnachweises (Guarantor Assertion). Dieser Nachweis wird vom EFA Identity Provider geprüft und in einen für EFA-Anwendungs- und EFA-Sicherheitsdienste nutzbaren Authentifizierungsnachweis überführt.
 +
;EFA Policy Provider
 +
:Der EFA Policy Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Client oder einem EFA-Anwendungsdienst aufgerufen und liefert einen Verweis auf die für den aufrufenden Nutzer gültigen Berechtigungsregeln (Policy) zu einer Anwendungsinstanz (z. B. einer spezifischen eFA) oder die zum Verweis gehörende Policy. Diese Verweise sind transparent, d. h. sie können sowohl selber bereits eine Semantik tragen (z. B. gemäß IHE BPPC) oder eine Policy-Datei referenzieren. Um auch ein "Policy Pull" zu erlauben (siehe [http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf IHE White Paper on Access Control]), wird auch ein Aufruf des Policy Provider durch einen EFA-Anwendungsdienst unterstützt.
 +
 
 +
{| class="wikitable"
 +
!Dienst || Aufgaben || Datenhaltung
 
|-
 
|-
!eCR Access Token Service
+
| EFA Identity Provider
|Authorizes the user to access an electronic Case Record by assigning an access policy.
+
|| Authentifiziert einen EFA-Teilnehmer durch Verifikation seiner Credentials. Der Dienst bietet verschiedene Authentifizierungsmethoden an:
|The admission lists of the eCRs. These lists can be imagined as tables containing record identifiers, admission codes, and corresponding access policy identifiers.
+
* Direktes Vertrauen: Authentifiziert einen EFA-Teilnehmer per X.509 Zertifikat oder Benutzername/Passwort-Kombination
 +
* Vermitteltes Vertrauen: Authentifiziert einen EFA-Teilnehmer durch Verifikation einer übermittelten signierten Guarantor Assertion (lokaler Identitätsnachweis eines EFA-Teilnehmers aus einer Organisation).
 +
|| Weitere Attribute können über einen mit dem EFA Identity Provider gruppierten Verzeichnisdienst abgerufen werden. Der Dienst enthält einen Identity Store, wo die verwalteten Identitäten sowie die Credentials für die Authentifizierung gespeichert sind.  
 
|-
 
|-
!eCR Policy Token Service
+
| EFA Policy Provider
|Provides the access policies of electronic Case Records.
+
|| Gibt eine Policy zu einem bestimmten (Behandlungs-)Zweck heraus. Je nach Autorisierungsmodell ("Policy Push"/"Policy Pull") kann eine explizite Access Control Policy oder ein Verweis (mit impliziter Semantik) die Autorisierung eines Benutzers (oder seiner Rolle) zu einer Fallakte bzw. dem festgelegten Zweck beschreiben.
|A table (etc.) that matches policy identifiers with access policies.  
+
|| Policies, welche jeweils den konsentierten Kreis der Behandelnden zu einem Zweck definieren.
 
|}
 
|}
  
== Identity Provider ==
 
The Identity Provider authenticates the user while it verifies the user’s credentials. The required credentials depend on the authentication method. The service issues an Identity Assertion on successful authentication. This service MUST support at least the following authentication methods:
 
* Direct trust: authenticate a dedicated client verifying the X.509 certificate of a known user identity
 
* Brokered trust: authenticate a trusted client verifying the provided Guarantor Assertion and the X.509 certificate that is used to sign this assertion.
 
  
=== Spezifikation ===
+
 
 +
----
 +
 
 +
 
 +
{{NoteBox|'''Referenzen und Querverweise'''
 +
* [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 
* Normative Spezifikation: [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider Service Functional Model]]
 
* Normative Spezifikation: [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider Service Functional Model]]
* Binding: [[cdaefa:EFA Identity Provider WS Trust Binding|EFA Identity Provider WS Trust Binding]]
+
* Normative Spezifikation: [[cdaefa:EFA_Policy_Provider_SFM|EFA Policy Provider Service Functional Model]]
 +
<nowiki></nowiki>
 +
}}

Aktuelle Version vom 26. Januar 2015, 16:05 Uhr

Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

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.
Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "Kommentierung EFAv2.0".


Sicherheitstoken und Sicherheitstokendienste

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierz.01}

Jeder EFA-Anwendungsdienst und jeder EFA-Sicherheitsdienst besitzt eine Sicherheitspolitik, in der u. a. definiert ist, wie der Sicherheitskontext aussehen muss, aus dem heraus der Dienst aufgerufen werden kann. Hierdurch „weiß“ ein EFA-Client, welches Sicherheitstoken er von welchem GDD-Sicherheitsdienst abrufen und in den Ablaufkontext laden muss, bevor der gewünschte Dienst aufgerufen werden kann. Dadurch dass auch Sicherheitsdienste Sicherheitspolitiken besitzen, lässt sich die komplette Ablaufsteuerung über den Sicherheitsdiensten deklarativ abbilden. Beispielsweise kann ein EFA-Anwendungsdienst für den Zugriff auf eine Ressource ein Sicherheitstoken verlangen, über das die entsprechende Berechtigung des Nutzers verifizierbar ist. Der dieses Token ausstellende Autorisierungsdienst wiederum kann eine Politik definieren, dass Berechtigungsnachweise nur ausgestellt werden, wenn der Nutzer über ein entsprechendes Token seine Authentizität nachweist, d.h. vor dem Autorisierungsdienst ein Authentifizierungsdienst aufgerufen wurde.

Im Rahmen des IHE Cookbook und der EFA-2.0 Spezifikation werden verschiedene Sicherheitstokendienste (föderierte Authentifizierung, Pseudonymisierung, Zugang zu Anwendungen, Autorisierung auf Ressourcen) spezifiziert, die nach dem oben skizzierten Prinzip von allen Aktendiensten genutzt werden können. Welche Sicherheitsdienste ein Aktendienst in Anspruch nimmt, definiert er über seine Sicherheitspolitk, die im Fachmodul in Aufrufe an die Sicherheitstokendienste übersetzt wird.

EFA Sicherheits(token)dienste

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eierz.02}

Sicherheitsdienste 5 Domains.png

EFA Identity Provider
Der EFA Identity Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Teilnehmersystem aufgerufen und stellt einen Identitätsnachweis für authentifizierte Nutzer aus. Dieser Nachweis kann neben Angaben zu Rollen und Gruppenzugehörigkeiten des Nutzers je nach Sicherheitspolitik auch ein Proof-of-Possession Merkmal enthalten, über der Provider die Authentizität des Nutzers unmittelbar verifizieren kann (im Gegensatz hierzu wird bei einer mittelbaren Authentizitätsprüfung die Nutzer-Authentizitätsprüfung eines als authentisch geprüften Clientsystems akzeptiert).

Der EFA Identity Provider unterstützt potenziell beliebige Verfahren der Authentifizierung (z.B. mittels Passwort, HBA oder SMC-B). Bei einer Authentifizierung mittels HBA werden die Nutzerattribute aus dem HBA-Zertifikat in den Identitätsnachweis übernommen. Zusätzlich wird anhand der genutzten SMC-B die Organisationszugehörigkeit eingetragen. Bei der Authentifizierung mittels SMC-B hat sich der Nutzer bereits innerhalb seiner Organisation sicher authentisiert. Auch alle Attribute wurden bereits durch die Organisation zugewiesen. Beim Aufruf des EFA Identity Providers bestätigt die Organisation die durchgeführte Authentifizierung und die Authentizität der Attribute in Form eines selbst ausgestellten, von der SMC-B signierten Identitätsnachweises (Guarantor Assertion). Dieser Nachweis wird vom EFA Identity Provider geprüft und in einen für EFA-Anwendungs- und EFA-Sicherheitsdienste nutzbaren Authentifizierungsnachweis überführt.

EFA Policy Provider
Der EFA Policy Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Client oder einem EFA-Anwendungsdienst aufgerufen und liefert einen Verweis auf die für den aufrufenden Nutzer gültigen Berechtigungsregeln (Policy) zu einer Anwendungsinstanz (z. B. einer spezifischen eFA) oder die zum Verweis gehörende Policy. Diese Verweise sind transparent, d. h. sie können sowohl selber bereits eine Semantik tragen (z. B. gemäß IHE BPPC) oder eine Policy-Datei referenzieren. Um auch ein "Policy Pull" zu erlauben (siehe IHE White Paper on Access Control), wird auch ein Aufruf des Policy Provider durch einen EFA-Anwendungsdienst unterstützt.
Dienst Aufgaben Datenhaltung
EFA Identity Provider Authentifiziert einen EFA-Teilnehmer durch Verifikation seiner Credentials. Der Dienst bietet verschiedene Authentifizierungsmethoden an:
  • Direktes Vertrauen: Authentifiziert einen EFA-Teilnehmer per X.509 Zertifikat oder Benutzername/Passwort-Kombination
  • Vermitteltes Vertrauen: Authentifiziert einen EFA-Teilnehmer durch Verifikation einer übermittelten signierten Guarantor Assertion (lokaler Identitätsnachweis eines EFA-Teilnehmers aus einer Organisation).
Weitere Attribute können über einen mit dem EFA Identity Provider gruppierten Verzeichnisdienst abgerufen werden. Der Dienst enthält einen Identity Store, wo die verwalteten Identitäten sowie die Credentials für die Authentifizierung gespeichert sind.
EFA Policy Provider Gibt eine Policy zu einem bestimmten (Behandlungs-)Zweck heraus. Je nach Autorisierungsmodell ("Policy Push"/"Policy Pull") kann eine explizite Access Control Policy oder ein Verweis (mit impliziter Semantik) die Autorisierung eines Benutzers (oder seiner Rolle) zu einer Fallakte bzw. dem festgelegten Zweck beschreiben. Policies, welche jeweils den konsentierten Kreis der Behandelnden zu einem Zweck definieren.