cdaefa:EFA Context Manager SFM

Dieses Material ist Teil des Leitfadens CDA für die elektronische Fallakte. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

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".

---

EFA Context Manager

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eoexr.01}

Die EFA nutzt einen vom Client aufgebauten und mit dem EFA-Provider geteilten Sicherheitskontext. Wesentlicher Bestandteil dieses Sicherheitskontextes sind authentische Nachweise zur Identität des EFA-Teilnehmern, die auf Seiten des EFA-Providers zur Berechtigungsprüfung benötigt werden.

Der erste Schritt jeder EFA-Nutzung ist der Aufbau eines initialen Sicherheitskontextes, da dieser bei jedem Aufruf eines EFA-Dienstes mitgegeben werden muss. Der initiale Sicherheitskontext kann durch Nutzung verschiedener Sicherheitsdienste ausgeweitet werden. Die entsprechenden Anforderungen werden vom EFA-Provider formuliert, der für jeden EFA-Dienst angeben kann, welche Sicherheitsnachweise der zum Aufruf des Dienstes erforderliche Sicherheitskontext enthalten muss.

Auf Seiten des EFA-Clients kapselt der (logische) Dienst des EFA ContextManagers den Aufbau und die Verwaltung des Sicherheitskontextes. Alle clientseitigen Aufrufe von EFA-Sicherheitsdiensten werden durch den EFA ContextManager ausgeführt, der die von diesen Diensten für den EFA-Teilnehmer ausgestellten Sicherheitsnachweise in den bestehenden Sicherheitskontext integriert.

Authentisierung eines EFA-Teilnehmers

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eoexr.02}

Die EFA macht keine Vorgaben, wie eine Authentifizierung eines EFA-Teilnehmers erfolgen muss. Verpflichtend ist in Bezug auf das Authentifizierungsverfahren und die eingesetzten Objekte und Mechanismen lediglich die Einhaltung der geltenden regionalen und nationalen Vorgaben zur Stärke der Authentifizierung sowie deren technischer und organisatorischer Absicherung.

Wesentlich für die über den ContextManager gesteuerte Authentisierung ist lediglich, dass in deren Ergebnis eine authentischer Identitätsnachweis des EFA-Teilnehmers vorliegt. Dieser Nachweis muss einem vorgegebenen Format genügen und bestimmte Identitätsinformationen kodieren, so dass jeder EFA-Dienst dieses Nachweis verarbeiten und semantisch gleichartig interpretieren kann.

Optionen zur Authentisierung von EFA-Teilnehmern (nicht-normativ)

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eoexr.02.01}

Die Identifizierung und Authentifizierung von EFA-Teilnehmern gegenüber den EFA-Diensten erfolgt in zwei Stufen; an einem initialen Authentisierungspunkt erfolgt die Prüfung des Authentizitätsnachweises und die Erstellung eines Identitätsnachweises, in dem die Identität des EFA-Teilnehmers über Attribute (z. B. Rollen und Organisationszugehörigkeiten) beschrieben ist. Jeder EFA-Dienst umfasst einen föderierten Authentisierungspunkt, an dem die Authentizität von Identitätsnachweisen verifiziert werden kann. Dieses zweistufige Verfahren erlaubt die Dezentralisierung der initialen Authentifizierung und die Einbringung von beim Leistungerbringer verwalteten Nutzerattributen (z. B. Funktionsrollen). Darüber hinaus bleiben so die technischen Besonderheiten verschiedener und potenziell parallel genutzter Authentifizierungsmechanismen (HBA, Mitarbeiterausweise einer Klinik, Username/Passwort, etc.) vor den EFA-Diensten verborgen.

Die nachfolgende Grafik stellt verschiedene Optionen zur Umsetzung eines initialen Authentisierungspunkts dar. Wesentlich hierbei ist, dass der Aufruf des initialen Authentisierungspunkts logisch über den ContextManager gekapselt wird, d.h. client-seitige Funktionalitäten der EFA-Nutzung und die beim EFA-Provider angesiedelten EFA-Dienste von konkreten Umsetzungen der initialen Authentisierung unabhängig sind. Einen Sonderfall stellt die Nutzung einer Guarantor Assertion dar, die dezentral ausgestellt wird und anschließend an einem Identity Provider in einen für den EFA-Dienste verarbeitbaren Identitätsnachweis überführt wird. Hierbei prüft der Identity Provider die Authentizität der Guarantor Assertion (föderierter Authentisierungspunkt) und stellt mit den Angaben aus der Guarantor Assertion und ggf. weiteren Informationen eines Verzeichnisdienstes einen neuen, für den EFA-Dienst validierbaren Nachweis aus (initialer Authentisierungspunkt aus Sicht des EFA-Dienstes).

Operation: OpenContext

Bitte markieren Sie Kommentare zu diesem Abschnitt mit dem Code {Eoexr.02.02}

Method	openContext(credential Object) : ContextIdentifer fault AuthenticationFailedException
Description	This method establishes a security context for a user that wants to get access to an eCR peer. The security context holds the Identity Assertion [SAML2.0core] necessary for invoking service operations from business services. A credential MUST be passed.
Input Parameters	credential	Object which MAY be a username/password combination, a subject identifier, a health card handle, or a SAML assertion that guarantees for an authentication.
Return Value	context	The identifier used to refer to the security context when issuing EFA activities within that context
Preconditions	Credentials (i.e., username/password) are present. No previously established security context with the same credentials is present.
Sequence (Main success scenario)	If a username/password combination is passed, the connector/ECRRequestor constructs a UsernameToken [WSSUsername] and invokes the RequestSecurityToken [WSTrust] operation of the eCR Identity Provider [eCR SecArch 1.2] for issuing an Identity Assertion. If a subject identifier is passed and a local Guarantor Token Service is configured, a local au-thentication assertion is issued and forwarded to the eCR Identity Provider. If the credential is already an Authentication Assertion, it will be forwarded as a security token to the eCR Identity Provider. If the authentication was successful, the Identity Assertion is stored in the session context within the eCR-Connector for later use. Otherwise an exception is thrown.
Exception	AuthenticationFailedException	Authentication failed due to wrong credentials.

---