EFA Sicherheitsdienste (logische Spezifikation)
(→EFA Sicherheits(token)dienste) |
K (→Spezifikation) |
||
| Zeile 44: | Zeile 44: | ||
=== Spezifikation === | === Spezifikation === | ||
| − | * Normative Spezifikation: [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider Service Functional Model]], [[cdaefa:EFA_Policy_Provider_SFM|EFA Policy Provider | + | * Normative Spezifikation: [[cdaefa:EFA Identity Provider SFM|EFA Identity Provider Service Functional Model]], [[cdaefa:EFA_Policy_Provider_SFM|EFA Policy Provider Service Functional Model]] |
| − | * Binding: [[cdaefa: | + | * Binding: [[cdaefa:EFA_Identity_Provider_WS_Trust_Binding|EFA Identity Provider WS Trust Binding]], [[cdaefa:EFA_Policy_Provider_WS Trust_Binding|EFA Policy Provider WS Trust Binding]] |
Version vom 8. April 2013, 08:38 Uhr
 |
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
|
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
- 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 enthält neben einem Proof-of-Possession Merkmal auch Angaben zu Rollen und Gruppenzugehörigkeiten des Nutzers. 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:
|
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. |
Spezifikation
- Normative Spezifikation: EFA Identity Provider Service Functional Model, EFA Policy Provider Service Functional Model
- Binding: EFA Identity Provider WS Trust Binding, EFA Policy Provider WS Trust Binding
- zurück zur EFA-2.0-Spezifikation
