EFA Sicherheitsdienste (logische Spezifikation)
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden EFA Sicherheitsdienste (logische Spezifikation) (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
|
Inhaltsverzeichnis
Sicherheitstoken und Sicherheitstokendienste
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
- Security Token Service
- Identity Provider
- Der Identity Provider ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Client aufgerufen und stellt eine für beliebige Gesundheitsdatendienste nutzbaren Identitätsnachweis für authentifizierte Nutzer aus. Dieser Nachweis enthält neben einem Proof-of-Possession Merkmal auch Angaben zu Rollen und Gruppenzugehörigkeiten des Nutzers. Der 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 authentifiziert. Auch alle Attribute wurden bereits durch die Organisation zugewiesen. Beim Aufruf des 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. Dieser Nachweis wird vom Identity Provider geprüft und in einen für Gesundheitsdatendienste nutzbaren Idnetitätsnachweis überführt (siehe auch eFA Sicherheitsarchitektur: Direct and Brokered Trust).
- Security Token Service
- Access Token Service
- Der Access Token Service ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Client oder einen 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). 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 Access Token Service durch einen EFA-Anwendungsdienst unterstützt.
- Security Token Service
- Policy Token Service
- Der Policy Token Service ist ein Sicherheitstoken-Dienst. Er wird vom EFA-Client oder einen EFA-Anwendungsdienst aufgerufen und liefert die zu einer Policy Referenz gehörige Policy Datei. Um auch ein „Policy Pull“ und „Policy Cache“ zu erlauben (siehe IHE White Paper on Access Control), wird auch ein Aufruf des Policy Token Service durch einen EFA-Anwendungsdienst unterstützt.
| Service | Tasks | Persistent Data |
|---|---|---|
| Identity Provider | 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. |
| eCR Access Token Service | Authorizes the user to access an electronic Case Record by assigning an access policy. | The admission lists of the eCRs. These lists can be imagined as tables containing record identifiers, admission codes, and corresponding access policy identifiers. |
| eCR Policy Token Service | Provides the access policies of electronic Case Records. | A table (etc.) that matches policy identifiers with access policies. |
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
- Normative Spezifikation: EFA Identity Provider Service Functional Model
- Binding: EFA Identity Provider WS Trust Binding
- zurück zur EFA-2.0-Spezifikation
