EFA Verwendete Standards
K (Seitentemplate an Konvention angepasst.) |
K (Markup-Fehler behoben) |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 106: | Zeile 106: | ||
− | |||
− | |||
+ | |||
+ | ---- | ||
+ | |||
+ | |||
+ | {{NoteBox|'''Referenzen und Querverweise''' | ||
+ | <references /> | ||
* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] | * zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] | ||
+ | <nowiki></nowiki> | ||
+ | }} |
Aktuelle Version vom 26. Januar 2015, 16:06 Uhr
Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte.
|
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
Verwendete Standards: Sicherheit
Security Assertion Markup Language (SAML)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eeenn.01.01}
Die Security Assertion Markup Language (SAML) spezifiziert einen Rahmen, in dem vertrauenswürdige Aussagen zu Identitäten dargestellt und ausgetauscht werden können. Die primären Anwendungsszenarien, in denen SAML eingesetzt wird, sind Single Sign-On sowie Identity Federation (Verknüpfung und Austausch von Identitätsinformationen über Organisationsgrenzen hinweg).
Den zentralen Bestandteil des Standards bilden die abstrakten Nachweise (Assertions) und Protokolle.[1] Während die Assertions vertrauenswürdige Aussagen zur Authentifizierung und Autorisierung einer Identität sowie einer Identität zugeordnete Attribute kapseln, erlauben es die Protokolle, solche Assertions anzufragen und zu transportieren.
SAML Core | |
---|---|
Organisation | OASIS |
Version | 2.0 (März 2005) |
Zweck | Abstrakte, XML-basierte Darstellung von vertrauenswürdigen Aussagen in Form von SAML Assertions |
Abstrakte Protokolle für den Transport der SAML Assertions |
Die SAML-Protokolle und deren Nachrichten werden in [1] zunächst abstrakt spezifiziert. Wie die Protokolle an ein konkretes Nachrichten- oder Transportprotokoll, beispielsweise SOAP oder HTTP, gebunden werden, wird in [2] spezifiziert. Abhängig vom mit SAML umzusetzenden Anwendungsszenario können Assertions und Protokolle zusätzlich in Form einer Profilierung konkretisiert werden. Für typische Anwendungsszenarien gibt der SAML-Standard bereits Profilierungen in [3] vor. Diese umfassen u.a. Single Sign-On-Szenarien für Web Browser und für erweiterte Clients sowie Identity-Federation-Szenarien in verschiedenen Varianten.
Die EFA 2.0 Spezifikation verwendet SAML Assertions als Sicherheitstoken, welche von speziellen Sicherheitstokendiensten ausgestellt werden. Die Assertions erlauben die Kodierung von Identitäts- und Authentifizierungsnachweisen.
Weitere Informationen zu diesem Standard sind im IHE Cookbook zu finden.
eXtensible Access Control Markup Language (XACML)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eeenn.01.02}
XACML[4] erlaubt die XML-basierte Beschreibung von Regeln für den Zugriff auf Ressourcen und spezifiziert Protokolle, mit denen Autorisierungsentscheidungen angefordert und ausgegeben werden können. Der Standard verfolgt einen generischen Ansatz, sodass mit XACML verschiedenartige Ansätze für Berechtigungssysteme (z.B. rollenbasierte Berechtigungen) realisiert werden können.
XACML | |
---|---|
Organisation | OASIS |
Version | 2.0 (Februar 2005) |
Zweck | Autorisierung |
Beschreibung von Zugriffsregeln | |
Protokoll zur Anforderung und Herausgabe von Autorisierungsentscheidungen |
Der Standard besteht in seinem Kern aus den Systembausteinen Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP) sowie Policy Administration Point (PAP). Diese Systembausteine werden durch weitere periphere Informationssysteme (z.B. Verzeichnisdienste) unterstützt. Weitere von OASIS herausgegebene Profile adressieren das Zusammenspiel mit anderen Standards (z.B. SAML) oder die Implementierung spezifischer Berechtigungsmodelle über die Konstrukte von XACML.
XACML spezifiziert – wie SAML auch – zunächst lediglich die Schemata für Protokollnachrichten. Der Transport dieser Nachrichten wird vom Standard nicht adressiert und ist Gegenstand einer Profilierung. In der EFA 2.0 Spezifikation wird XACML für die Kodierung von Autorisierungsnachweisen verwendet.
Weitere Informationen zu diesem Standard sind im IHE Cookbook zu finden.
Web Service Security (WS-Security)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eeenn.01.03}
WS-Security [5] erlaubt es, SOAP-Nachrichten auf der Nachrichtenebene zu signieren und zu verschlüsseln. Es bietet außerdem einen Rahmen, in dem verschiedene Sicherheitstoken übertragen werden können. Der Standard wird daher von weiteren Token-Profilen begleitet, die etwa die Nutzung von X.509-basierten Zertifikaten, SAML-Token oder Kerberos-Tickets als Sicherheitstoken spezifizieren.
WS-Security | ||
---|---|---|
Organisation | OASIS | |
Version | 1.1 (Februar 2006) | |
Zweck | Nachrichtensicherheit auf Nachrichtenebene, Bereitstellung von Mechanismen für höhere
Sicherheitsprotokolle | |
Erweiterungen | Tokenprofile: | Username Token Profile 1.1 |
X.509 Token Profile 1.1 | ||
SAML Token Profile 1.1 | ||
Kerberos Token Profile 1.1 |
Im Rahmen der EFA-Sicherheitsarchitektur wird WS-Security genutzt, um Sicherheitstoken zwischen EFA-Teilnehmersystem und EFA-Anwendung- und Sicherheitsdiensten auszutauschen.
Web Services Trust Language (WS-Trust)
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eeenn.01.04}
WS-Trust [6] erweitert WS-Security um ein nachrichtenbasiertes Protokoll, das das Anfragen und Ausstellen von Sicherheitstoken sowie die Delegation von Vertrauensbeziehungen erlaubt. WS-Trust führt dazu ein aus drei Rollen bestehendes Modell ein, in dem ein Webservice-Nutzer bei einem Sicherheitstokendienst ein Sicherheitstoken anfragt, welches dieser anschließend bei einem Webservice-Anbieter einlösen kann. Die vom Webservice-Nutzer so vorgelegten Behauptungen zur Nutzeridentität sind durch die Vertrauensbeziehung zwischen Webservice-Anbieter und Sicherheitstokendienst mithilfe von kryptographischen Methoden verifizierbar.
WS-Trust ist funktional dem SAML 2.0 Protokoll sehr ähnlich, wobei SAML eher in browserbasierten Lösungen zum Einsatz kommt, während WS-Trust vorwiegend in Fat-Client-Umgebungen genutzt wird, bei denen auch über eine rein textbasierte HTTP-Kommunikation hinausgehende Protokolle wie z.B. SOAP zur Kommunikation zwischen Systemkomponenten genutzt werden. Hersteller von Identitäts- und Berechtigungsmanagement-Lösungen unterstützen üblicherweise beide Protokolle.
WS-Trust | |
---|---|
Organisation | OASIS |
Version | 1.3 (März 2007) |
Zweck | Anfragen und Ausstellen von Sicherheitstoken (z. B. SAML Assertions), Konzept des direkt vermittelten Vertrauens |
Der EFA Identity Provider ist ein WS-Trust 1.3 Sicherheitstokendienst. Er erlaubt einen Abruf von EFA Identity Assertions über das WS-Trust-Protokoll. Weitere Informationen im IHE Cookbook.
Referenzen und Querverweise
|