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
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.
| 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 Admission Token Service | Calculates the pseudonyms (admission codes) to identify a patient’s records. | no persistent data |
| 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
