Informationsmodell der EFA Sicherheitsobjekte
(Die Seite wurde neu angelegt: „{{Infobox Dokument |Title = Informationsmodell der EFA Sicherheitsobjekte |Short = Informationsmodell der EFA Sicherheitsobjekte |Namespace = cdaefa |Type…“) |
|||
| Zeile 15: | Zeile 15: | ||
}} | }} | ||
| + | ''Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel 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.<br>Hinweise zum Kommentierungsverfahren einschließlich aller Formulare und Kontaktadressen finden Sie auf der Seite "[[cdaefa:Kommentierung EFAv2.0|Kommentierung EFAv2.0]]".'' | ||
| + | ---- | ||
| + | |||
| + | == EFA Sicherheitskontext == | ||
| + | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.01}</tt> | ||
| + | |||
| + | [[Datei:EFA_GDD_Klein.png|160px|right]]Alle Aufrufe einer EFA-Funktionalität erfolgen innerhalb eines definierten [[cdaefa:Kontext,_Akte,_Ressource#Kontext|Sicherheitskontextes]], der über den [[cdaefa:EFA_Context_Manager_SFM|EFA Context Manager]] aufgebaut und verwaltet wird. | ||
| + | |||
| + | Grundsätzlich macht diese Spezifikation nur wenige Vorgaben, welche Sicherheitsobjekte im Sicherheitskontext abgelegt sind und wie diese Objekte in den Sicherheitskontext gelangen. Hierdurch entkoppelt der über ein [[#context|context-Objekt]] gekapselte Sicherheitskontext die EFA-Anwendungsarchitektur von der darunter liegenden Sicherheitsarchitektur. EFA-Dienste erhalten mit jedem Operationsaufruf eine Kopie des lokalen context-Objekts und können anhand der darin enthaltenen Informationen die eigenen Sicherheitsdienste zur Authentisierung und Autorisierung ausführen. | ||
== PIM Data Structures == | == PIM Data Structures == | ||
| − | Die nachfolgend beschriebenen Objektklassen werden im Rahmen des EFA Service Functional Model verwendet und bilden | + | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.02}</tt> |
| + | |||
| + | Die nachfolgend beschriebenen Objektklassen werden im Rahmen des ''EFA Service Functional Model'' verwendet und bilden das Informationsmodel des ''Platform Independent Model'' der EFA Sicherheitsarchitektur. | ||
=== context === | === context === | ||
| + | <tt>Bitte markieren Sie [[cdaefa:Kommentierung_EFAv2.0|Kommentare]] zu diesem Abschnitt mit dem Code {Eecim.02.01}</tt> | ||
| + | |||
| + | Die Klasse ''context'' entkoppelt Anwendungs- und Sicherheitsarchitektur der EFA. Jeder Aufruf einer EFA-Operation enthält eine Kopie des im lokalen [[cdaefa:EFA_Context_Manager_SFM|EFA Context Manager]] des EFA-Clients verwalteten context-Objekts. | ||
| + | |||
| + | [[Datei:IM_PIM_Context.png|420px|right]] | ||
| + | Während in der EFA-1.2-Spezifikation noch vier Sicherheitsnachweise über die Klasse ''context'' gekapselt wurden, sind in der EFA-2.0-Spezifikation zunächst nur zwei Nachweise normativ spezifiziert. Weitere Sicherheitsnachweise können für Ergänzungen dieser Spezifikation bzw. auch für einzelne Umsetzungen der EFA 2.0 definiert werden. Wesentlich ist lediglich, dass hierbei das logische Konstrukt des ''context'' zur Verwaltung und zum Austausch dieser Nachweise genutzt wird. Hierdurch sind die Interoperabilität auf der logischen Ebene sowie die grundsätzliche Migrationsfähigkeit in die Telematikinfrastruktur sichergestellt. | ||
| − | [[ | + | Die nebenstehende Abbildung stellt den Aufbau der context-Klasse dar: |
| + | * eine [[#subjectIdentity|subjectIdentity]] kapselt die Identität des EFA-Teilnehmers und sichert bei Dienstaufrufen die Authentizität des EFA-Teilnehmers ab. | ||
| + | * eine [[#subjectAccessPolicy|subjectAccessPolicy]] beschreibt die Zugruffsberechtigungen des über die ''subjectIdentity'' identifizierten EFA-Teilnehmers. | ||
| − | ---- | + | In jedem Sicherheitskontext muss genau ein ''subjectIdentity''-Objekt vorhanden sein. Dieses wird durch den [[cdaefa:EFA_Context_Manager_SFM|EFA Context Manager]] im Rahmen der Identifizierung und Authentifizierung des EWFA-Teilnehmers von einem [[cdaefa:EFA_Identity_Provider_SFM|Identity Provider]] ausgestellt. Die Umsetzung des Identity Providers kann flexibel ausgestaltet werden, wodurch nicht nur ein Single Sign-On aus einem Primärsystem heraus sondern auch eine Nutzung der Sicherheitsobjekte und -mechanismen der Telematikinfrastruktur unterstützt werden (siehe [[cdaefa:EFA_Context_Manager_SFM#Optionen_zur_Authentisierung_von_EFA-Teilnehmern_.28nicht-normativ.29|Optionen zur Authentifizierung von EFA-Teilnhemern]]). |
| + | |||
| + | Eine ''subjectAccessPolicy'' ist nur bei Verwendung eines ''Policy-Push'' Verfahrens Bestandteil des Sicherheitskontextes. Ansonsten erfolgt der Abruf von Berechtigungsregeln on demand über den EFA-Dienst, der die angefragte Ressource verwaltete. | ||
| + | |||
| + | Sofern weitere Sicherheitsnachweise über ein ''context''-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das ''subjectIdentity''-Objekt gebunden sein, da nur so eine integre und authentische [[cdaefa:Kontext,_Akte,_Ressource#Kontext|Nachweis-Kette]] aufgebaut werden kann. | ||
| + | |||
| + | === subjectIdentity === | ||
| + | |||
| + | |||
| + | === subjectAccessPolicy === | ||
| + | |||
| + | |||
| + | == Querverweise und Referenzen == | ||
| − | * | + | * [[cdaefa:EFA_Spezifikation_v2.0|EFA-2.0-Spezifikation]] |
Version vom 27. April 2013, 16:49 Uhr
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden Informationsmodell der EFA Sicherheitsobjekte (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
|
Anmerkung: Die unter den einzelnen Überschriften in geschweiften Klammern angegebenen Kürzel 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
EFA Sicherheitskontext
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.01}
Alle Aufrufe einer EFA-Funktionalität erfolgen innerhalb eines definierten Sicherheitskontextes, der über den EFA Context Manager aufgebaut und verwaltet wird.
Grundsätzlich macht diese Spezifikation nur wenige Vorgaben, welche Sicherheitsobjekte im Sicherheitskontext abgelegt sind und wie diese Objekte in den Sicherheitskontext gelangen. Hierdurch entkoppelt der über ein context-Objekt gekapselte Sicherheitskontext die EFA-Anwendungsarchitektur von der darunter liegenden Sicherheitsarchitektur. EFA-Dienste erhalten mit jedem Operationsaufruf eine Kopie des lokalen context-Objekts und können anhand der darin enthaltenen Informationen die eigenen Sicherheitsdienste zur Authentisierung und Autorisierung ausführen.
PIM Data Structures
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02}
Die nachfolgend beschriebenen Objektklassen werden im Rahmen des EFA Service Functional Model verwendet und bilden das Informationsmodel des Platform Independent Model der EFA Sicherheitsarchitektur.
context
Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eecim.02.01}
Die Klasse context entkoppelt Anwendungs- und Sicherheitsarchitektur der EFA. Jeder Aufruf einer EFA-Operation enthält eine Kopie des im lokalen EFA Context Manager des EFA-Clients verwalteten context-Objekts.
Während in der EFA-1.2-Spezifikation noch vier Sicherheitsnachweise über die Klasse context gekapselt wurden, sind in der EFA-2.0-Spezifikation zunächst nur zwei Nachweise normativ spezifiziert. Weitere Sicherheitsnachweise können für Ergänzungen dieser Spezifikation bzw. auch für einzelne Umsetzungen der EFA 2.0 definiert werden. Wesentlich ist lediglich, dass hierbei das logische Konstrukt des context zur Verwaltung und zum Austausch dieser Nachweise genutzt wird. Hierdurch sind die Interoperabilität auf der logischen Ebene sowie die grundsätzliche Migrationsfähigkeit in die Telematikinfrastruktur sichergestellt.
Die nebenstehende Abbildung stellt den Aufbau der context-Klasse dar:
- eine subjectIdentity kapselt die Identität des EFA-Teilnehmers und sichert bei Dienstaufrufen die Authentizität des EFA-Teilnehmers ab.
- eine subjectAccessPolicy beschreibt die Zugruffsberechtigungen des über die subjectIdentity identifizierten EFA-Teilnehmers.
In jedem Sicherheitskontext muss genau ein subjectIdentity-Objekt vorhanden sein. Dieses wird durch den EFA Context Manager im Rahmen der Identifizierung und Authentifizierung des EWFA-Teilnehmers von einem Identity Provider ausgestellt. Die Umsetzung des Identity Providers kann flexibel ausgestaltet werden, wodurch nicht nur ein Single Sign-On aus einem Primärsystem heraus sondern auch eine Nutzung der Sicherheitsobjekte und -mechanismen der Telematikinfrastruktur unterstützt werden (siehe Optionen zur Authentifizierung von EFA-Teilnhemern).
Eine subjectAccessPolicy ist nur bei Verwendung eines Policy-Push Verfahrens Bestandteil des Sicherheitskontextes. Ansonsten erfolgt der Abruf von Berechtigungsregeln on demand über den EFA-Dienst, der die angefragte Ressource verwaltete.
Sofern weitere Sicherheitsnachweise über ein context-Objekt verwaltet und ausgetauscht werden sollen, müssen diese direkt oder indirekt an das subjectIdentity-Objekt gebunden sein, da nur so eine integre und authentische Nachweis-Kette aufgebaut werden kann.
