cdaefa:EFA Access Control System - Versionsgeschichte

Jcaumanns: Markup-Fehler behoben

2015-01-26T16:12:00Z

Markup-Fehler behoben

Jcaumanns: Querverweise

2015-01-14T13:44:15Z

Querverweise

Jcaumanns: /* Bindung von Policies an Schnittstellen */

2013-09-05T20:01:49Z

‎Bindung von Policies an Schnittstellen

Jcaumanns am 23. April 2013 um 21:00 Uhr

2013-04-23T21:00:50Z

Rkuhlisch: /* Bausteine des ACS */

2013-03-25T13:45:54Z

‎Bausteine des ACS

Rkuhlisch am 21. März 2013 um 09:19 Uhr

2013-03-21T09:19:45Z

Foemig am 20. März 2013 um 08:10 Uhr

2013-03-20T08:10:10Z

Jcaumanns am 17. März 2013 um 20:07 Uhr

2013-03-17T20:07:56Z

Jcaumanns am 13. März 2013 um 00:03 Uhr

2013-03-13T00:03:49Z

Jcaumanns: Die Seite wurde neu angelegt: „{{Infobox Dokument |Title = EFA Access Control System |Short = EFA Access Control System |Namespace = cdaefa |Type = Implementierungsleitfaden |Versi…“

2013-03-12T23:04:21Z

Die Seite wurde neu angelegt: „{{Infobox Dokument |Title = EFA Access Control System |Short = EFA Access Control System |Namespace = cdaefa |Type = Implementierungsleitfaden |Versi…“

Neue Seite

{{Infobox Dokument
|Title = EFA Access Control System
|Short = EFA Access Control System
|Namespace = cdaefa
|Type = Implementierungsleitfaden
|Version = 0.9
|Submitted = February 2013
|Author = Jörg Caumanns, Raik Kuhlisch
|Date = March 2013
|Copyright = 2012-2013
|Status = Draft
|Period = xxx
|OID = n.n.
|Realm = Deutschland
}}

[[Datei:EFA_access_control.png|800px]]

----

* zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

@@ Zeile 45: / Zeile 45: @@
 <references/>
 * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]
 }}

@@ Zeile 38: / Zeile 38: @@
-=== Referenzen ===
 <references/>
 * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

@@ Zeile 8: / Zeile 8: @@
 <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {EcssS.01}</tt>
-Die Sicherheitsarchitektur der elektronischen Fallakte definiert für jeden Anwendungsdienst mittels WS-Policy und WS-SecurityPolicy welche Sicherheitsnachweise (Security Assertions, z. B. kodiert als Security Token) notwendig sind, um die Operationen aufrufen zu können. SAML Assertions [SAML2.0] kodieren die notwendigen Authentisierungs- und Autorisierungsinformationen, welche von speziellen Security Token Services ausgestellt werden. Hierbei kann ein Security Token Service zur Ausstellung eines geforderten Sicherheitsnachweises (Security Assertion) die Vorlage eines Security Token verlangen, dass in die Zuständigkeit eines anderen Security Token Service fällt. Auf diese Weise können Abhängigkeiten in Sicherheitsdiensten (z. B. Autorisierung erfordert Authentifizierung) auf sequentielle Ketten von Sicherheitsnachweisen abgebildet werden.
+Die Sicherheitsarchitektur der elektronischen Fallakte definiert für jeden Anwendungsdienst mittels WS-Policy und WS-SecurityPolicy welche Sicherheitsnachweise (Security Assertions, z. B. kodiert als Security Token) notwendig sind, um die Operationen aufrufen zu können. SAML Assertions [SAML2.0] kodieren die notwendigen Authentisierungs- und Autorisierungsinformationen, welche von speziellen Security Token Services ausgestellt werden. Hierbei kann ein Security Token Service zur Ausstellung eines geforderten Sicherheitsnachweises (Security Assertion) die Vorlage eines Security Token verlangen, dass in die Zuständigkeit eines anderen Security Token Service fällt. Auf diese Weise können Abhängigkeiten in Sicherheitsdiensten (z. B. Autorisierung erfordert Authentifizierung) auf sequentielle Ketten von Sicherheitsnachweisen abgebildet werden. Die nachfolgende Abbildung stellt dies in der maximalen Komplexitätsstufe dar, in der neben dem Authentisierungsnachweis auch ein Admission Code und ein Autorisierungsnachweis Bestandteil der Nachweis-Kette sind.
 [[Datei:EFA_Assertion_Chain.png|640px]]
@@ Zeile 14: / Zeile 14: @@
 In der Deklaration der zur Umsetzung der Schutzziele beizubringenden Sicherheitsobjekte können „klassische“ X.509 Token und Security Context Token mit SAML Token kombiniert werden. Die eFA-Sicherheitsarchitektur erlaubt es auch, mehrere SAML Token an einen Web Service zu versenden, d. h. iterativ ganze Ketten von aufeinander verweisenden Sicherheitsnachweisen aufzubauen. Hiermit können die Nachweise der Nutzung einzelner Sicherheitsdienste (Authentisierung, Pseudonymisierung, Autorisierung, etc.) als vom unterliegenden Security Framework zu bearbeitende Bestandteile des Aufrufs eines  Anwendungsdienstes kodiert werden.
-Die Einbettung mehrerer SAML Assertions in das SOAP Security Header stellt auf der Implementierungsseite vielerlei Ansprüche: Zum einen muss die Semantik der Assertions selbst (strukturierte Elemente in Attributen) und zum anderen die korrekte Kombination einer Assertion-Kette überprüft werden können. Einem Aufrufenden muss zudem ein Besitznachweis für diese SAML Assertions abverlangt werden.
+Durch diese Flexibilität kann eine EFA-Implementierung alle im IHE White Paper "Access Control" benannten Verfahren zum Austausch von Autorisierungsnachweisen (policy push, policy pull, policy cache) nutzen. Grundsätzlich gelten hierbei jedoch die folgenden Vorgaben:
 Um unterschiedliche Sicherheitsanforderungen für die verschiedenen Vertrauensbeziehungen zwischen Dienstnutzern und -anbietern deklarieren zu können, wird für jede Vertrauensbeziehung in der Schnittstellenspezifikation ein eigener Port definiert. So können z. B. sehr einfach unterschiedliche Policies für Zugriffe aus verschiedenen Sicherheitszonen heraus definiert werden (z. B. Zugriffe innerhalb eines Circle-of-Trust und in einen Circle-of-Trust hinein).

@@ Zeile 1: / Zeile 1: @@
 {{DocumentPart}}
 = Bindung von Policies an Schnittstellen =
 Die Sicherheitsarchitektur der elektronischen Fallakte definiert für jeden Anwendungsdienst mittels WS-Policy und WS-SecurityPolicy welche Sicherheitsnachweise (Security Assertions, z. B. kodiert als Security Token) notwendig sind, um die Operationen aufrufen zu können. SAML Assertions [SAML2.0] kodieren die notwendigen Authentisierungs- und Autorisierungsinformationen, welche von speziellen Security Token Services ausgestellt werden. Hierbei kann ein Security Token Service zur Ausstellung eines geforderten Sicherheitsnachweises (Security Assertion) die Vorlage eines Security Token verlangen, dass in die Zuständigkeit eines anderen Security Token Service fällt. Auf diese Weise können Abhängigkeiten in Sicherheitsdiensten (z. B. Autorisierung erfordert Authentifizierung) auf sequentielle Ketten von Sicherheitsnachweisen abgebildet werden.
@@ Zeile 12: / Zeile 18: @@
 Um unterschiedliche Sicherheitsanforderungen für die verschiedenen Vertrauensbeziehungen zwischen Dienstnutzern und -anbietern deklarieren zu können, wird für jede Vertrauensbeziehung in der Schnittstellenspezifikation ein eigener Port definiert. So können z. B. sehr einfach unterschiedliche Policies für Zugriffe aus verschiedenen Sicherheitszonen heraus definiert werden (z. B. Zugriffe innerhalb eines Circle-of-Trust und in einen Circle-of-Trust hinein).
-== Bausteine des Access Control System ==
+=== Bausteine des Access Control System ===
 Die nachfolgende Grafik stellt das Prinzip der Zugriffskontrolle abstrakt mit den [[cdaefa:EFA_Verwendete_Standards#eXtensible_Access_Control_Markup_Language_.28XACML.29|XACML]]-Akteuren dar. Ein Zugriff auf den eigentlichen Dienst einer Document Registry wird serverseitig von einem PEP unterbrochen. Ein PEP implementiert einen Authorization Requestor, welcher eine Autorisierungsanfrage an einen PDP (Authorization Decision Provider) stellt. Der in der Abbildung gezeigte optionale Context Handler kann diese Anfrage in ein standardisiertes Protokoll (bspw. SAML)<ref>A. Anderson und H. Lockhart (2005), SAML 2.0 profile of XACML v2.0.</ref> überführen oder der Authorization Requestor kann direkt mit einem Authorization Decision Provider kommunizieren. Über einen PAP (Policy Repository) können die eigentlichen Autorisierungsrichtlinien kodiert als XACML Policies abgerufen werden. Der Transport einer Autorisierungsanfrage bzw. Policy-Abfrage kann über einen HTTP SOAP Request erfolgen.<ref>C. L. Joie (2007), SOAP Profile for XACML-SAML.</ref> Sind weitere Attribute für die Evaluierung einer Autorisierungsentscheidung notwendig (eine Policy bestimmt die notwendigen Attribute), so können diese über einen PIP bezogen werden.
@@ Zeile 26: / Zeile 33: @@
-= Referenzen =
+=== Referenzen ===
 <references/>
 * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

@@ Zeile 12: / Zeile 12: @@
 Um unterschiedliche Sicherheitsanforderungen für die verschiedenen Vertrauensbeziehungen zwischen Dienstnutzern und -anbietern deklarieren zu können, wird für jede Vertrauensbeziehung in der Schnittstellenspezifikation ein eigener Port definiert. So können z. B. sehr einfach unterschiedliche Policies für Zugriffe aus verschiedenen Sicherheitszonen heraus definiert werden (z. B. Zugriffe innerhalb eines Circle-of-Trust und in einen Circle-of-Trust hinein).
-== Bausteine des ACS ==
+== Bausteine des Access Control System ==
-Die nachfolgende Grafik stellt das Zusammenspiel von Anwendungs- und Sicherheitsdiensten im Detail dar.
+Die nachfolgende Grafik stellt das Prinzip der Zugriffskontrolle abstrakt mit den [[cdaefa:EFA_Verwendete_Standards#eXtensible_Access_Control_Markup_Language_.28XACML.29|XACML]]-Akteuren dar. Ein Zugriff auf den eigentlichen Dienst einer Document Registry wird serverseitig von einem PEP unterbrochen. Ein PEP implementiert einen Authorization Requestor, welcher eine Autorisierungsanfrage an einen PDP (Authorization Decision Provider) stellt. Der in der Abbildung gezeigte optionale Context Handler kann diese Anfrage in ein standardisiertes Protokoll (bspw. SAML)<ref>A. Anderson und H. Lockhart (2005), SAML 2.0 profile of XACML v2.0.</ref> überführen oder der Authorization Requestor kann direkt mit einem Authorization Decision Provider kommunizieren. Über einen PAP (Policy Repository) können die eigentlichen Autorisierungsrichtlinien kodiert als XACML Policies abgerufen werden. Der Transport einer Autorisierungsanfrage bzw. Policy-Abfrage kann über einen HTTP SOAP Request erfolgen.<ref>C. L. Joie (2007), SOAP Profile for XACML-SAML.</ref> Sind weitere Attribute für die Evaluierung einer Autorisierungsentscheidung notwendig (eine Policy bestimmt die notwendigen Attribute), so können diese über einen PIP bezogen werden.
 ----
 * zurück zur [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]]

← Nächstältere Version		Version vom 21. März 2013, 09:19 Uhr
Zeile 11:		Zeile 11:

	Um unterschiedliche Sicherheitsanforderungen für die verschiedenen Vertrauensbeziehungen zwischen Dienstnutzern und -anbietern deklarieren zu können, wird für jede Vertrauensbeziehung in der Schnittstellenspezifikation ein eigener Port definiert. So können z. B. sehr einfach unterschiedliche Policies für Zugriffe aus verschiedenen Sicherheitszonen heraus definiert werden (z. B. Zugriffe innerhalb eines Circle-of-Trust und in einen Circle-of-Trust hinein).		Um unterschiedliche Sicherheitsanforderungen für die verschiedenen Vertrauensbeziehungen zwischen Dienstnutzern und -anbietern deklarieren zu können, wird für jede Vertrauensbeziehung in der Schnittstellenspezifikation ein eigener Port definiert. So können z. B. sehr einfach unterschiedliche Policies für Zugriffe aus verschiedenen Sicherheitszonen heraus definiert werden (z. B. Zugriffe innerhalb eines Circle-of-Trust und in einen Circle-of-Trust hinein).
−
−	Die folgende Abbildung verdeutlicht die Komplexität verschiedener Schnittstellen mit den Policies, in denen deklariert ist, welche Sicherheitsnachweise bei Aufruf eines Dienstes aus verschiedenen Sicherheitskontexten heraus jeweils beizubringen sind (z. B. wird bei einem Aufruf von „außen“ ein expliziter Authentisierungsnachweis verlangt, während beim Aufruf durch Dienste innerhalb eines definierten Circle-of-Trust aufgrund von vorab aufgebauten WS-SecureConversation Kanälen solche Nachweise nicht erforderlich sind).
−
−	~~[[Datei:EFA_Ports.png\|640px]]~~

	== Bausteine des ACS ==		== Bausteine des ACS ==

← Nächstältere Version		Version vom 17. März 2013, 20:07 Uhr
Zeile 15:		Zeile 15:
	}}		}}

		+	= Bindung von Policies an Schnittstellen =
		+	Die Sicherheitsarchitektur der elektronischen Fallakte definiert für jeden Anwendungs-dienst mittels WS-Policy und WS-SecurityPolicy welche Sicherheitsnachweise (Security Assertions, z. B. kodiert als Security Token) notwendig sind, um die Operationen aufrufen zu können. SAML Assertions [SAML2.0] kodieren die notwendigen Authentisierungs- und Autori¬sie¬rungs¬informationen, welche von speziellen Security Token Services ausgestellt werden. Hierbei kann ein Security Token Service zur Ausstellung eines geforderten Sicherheitsnachweises (Security Assertion) die Vorlage eines Security Token verlangen, dass in die Zuständigkeit eines anderen Security Token Service fällt. Auf diese Weise können Abhängigkeiten in Sicherheitsdiensten (z. B. Autorisierung erfordert Authentifizierung) auf sequentielle Ketten von Sicherheitsnachweisen abgebildet werden.
		+
		+	[[Datei:EFA_Assertion_Chain.png\|640px]]
		+
		+	In der Deklaration der zur Umsetzung der Schutzziele beizubringenden Sicherheitsobjekte können „klassische“ X.509 Token und Security Context Token mit SAML Token kombiniert werden. Die eFA-Sicherheitsarchitektur erlaubt es auch, mehrere SAML Token an einen Web Service zu versenden, d. h. iterativ ganze Ketten von aufeinander verweisenden Sicherheitsnachweisen aufzubauen. Hiermit können die Nachweise der Nutzung einzelner Sicherheitsdienste (Authentisierung, Pseudonymisierung, Autorisierung, etc.) als vom unterliegenden Security Framework zu bearbeitende Bestandteile des Aufrufs eines Anwendungsdienstes kodiert werden.
		+
		+	Die Einbettung mehrerer SAML Assertions in das SOAP Security Header stellt auf der Implementierungsseite vielerlei Ansprüche: Zum einen muss die Semantik der Assertions selbst (strukturierte Elemente in Attributen) und zum anderen die korrekte Kombination einer Assertion-Kette überprüft werden können. Einem Aufrufenden muss zudem ein Besitznachweis für diese SAML Assertions abverlangt werden.
		+
		+	Um unterschiedliche Sicherheitsanforderungen für die verschiedenen Vertrauensbeziehungen zwischen Dienstnutzern und -anbietern deklarieren zu können, wird für jede Vertrauensbeziehung in der Schnittstellenspezifikation ein eigener Port definiert. So können z. B. sehr einfach unterschiedliche Policies für Zugriffe aus verschiedenen Sicherheitszonen heraus definiert werden (z. B. Zugriffe innerhalb eines Circle-of-Trust und in einen Circle-of-Trust hinein).
		+
		+	Die folgende Abbildung verdeutlicht die Komplexität verschiedener Schnittstellen mit den Policies, in denen deklariert ist, welche Sicherheitsnachweise bei Aufruf eines Dienstes aus verschiedenen Sicherheitskontexten heraus jeweils beizubringen sind (z. B. wird bei einem Aufruf von „außen“ ein expliziter Authentisierungsnachweis verlangt, während beim Aufruf durch Dienste innerhalb eines definierten Circle-of-Trust aufgrund von vorab aufgebauten WS-SecureConversation Kanälen solche Nachweise nicht erforderlich sind).
		+
		+	[[Datei:EFA_Ports.png\|640px]]
		+
		+	= Bausteine des ACS =

	Die nachfolgende Grafik stellt das Zusammenspiel von Anwendungs- und Sicherheitsdiensten im Detail dar.		Die nachfolgende Grafik stellt das Zusammenspiel von Anwendungs- und Sicherheitsdiensten im Detail dar.

← Nächstältere Version		Version vom 13. März 2013, 00:03 Uhr
Zeile 16:		Zeile 16:


		+	Die nachfolgende Grafik stellt das Zusammenspiel von Anwendungs- und Sicherheitsdiensten im Detail dar.
	[[Datei:EFA_access_control.png\|800px]]		[[Datei:EFA_access_control.png\|800px]]