EFA Access Control System
K |
|||
| 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. | ||
Version vom 17. März 2013, 20:07 Uhr
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden EFA Access Control System (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
|
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.
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).
Bausteine des ACS
Die nachfolgende Grafik stellt das Zusammenspiel von Anwendungs- und Sicherheitsdiensten im Detail dar.
- zurück zur EFA-2.0-Spezifikation
