e-Impfpass Kontext-Assertion¶
Die Verfahren, eine e-Impfpass Kontext-Assertion anzufordern, zu erneuern bzw. zu invalidieren, sind mit denen der ELGA Login-Assertion identisch. Einzig die Inhalte der einzelnen WS Trust Transaktionen bzw. der SAML-Assertions unterscheiden sich in den SAML-Attributen Purpose of Use, Permissions und Audience-Restriction. In der Audience-Restriction sind jene Endpunkte gelistet, an welche die e-Impfpass Kontext-Assertion potenziell übermittelt werden könnte.
Eine e-Impfpass Kontext-Assertion repräsentiert eine Identitätsföderation und wird wie eine HCP-Assertion über die lokale AGW mittels WS Trust RST vom ETS angefordert. Als Vorbedingung wird eine gültige HCP-Assertion oder eine gültige und valide Identity-Assertion (PVP oder vertrauenswürdiger IdP) benötigt. Der Bürger bzw. der Vertreter kann mittels User I- bzw. Mandate I- auch eine e-Impfpass Kontext-Assertion beantragen. Die e-Impfpass Kontext-Assertion auf Basis einer HCP-Assertion (bzw. auf Basis von GDA Assertions allgemein) kann nur einmalig erneuert werden, beim Versuch die e-Impfpass Kontext-Assertion ein zweites Mal zu erneuern, wird die Fehlermeldung "wst:UnableToRenew" SoapFault retourniert. Eine e-Impfpass Kontext-Assertion, die auf Basis einer User I-, Mandate I oder OBST/eHS Mandate I-Assertion ausgestellt wurde, kann auch wie eine User I, Mandate I oder OBST/eHS Mandate zweimal erneuert werden. Unter Verwendung einer abgelaufenen oder invalidierten e-Impfpass Kontext-Assertion, werden bei allen anderen folgenden Transaktionen, die Fehlermeldung "wsse:InvalidSecurityToken" SoapFault zurückgegeben. Beim Versuch, eine Transaktion mit einer HCP-Assertion im Kontext e-Impfpass durchzuführen, wird der BeS Fehler "spirit:xds.004.3.00020" mit der Meldung "XDS request failed" zurückgeliefert.
Läuft eine Benutzersession ab oder wurde invalidiert, muss auch die e-Impfpass Kontext-Assertion beim ETS invalidiert werden. Die Länge der Gültigkeitsdauer der e-Impfpass Kontext-Assertion ist mit der zugrundeliegenden ELGA-Assertion identisch und beginnt mit der Ausstellung der e-Impfpass Kontext-Assertion. Wird als Grundlage keine ELGA-Assertion (HCP, User I, Mandate I, OBST/eHS) sondern eine IDA verwendet, orientiert sich die Gültigkeitsdauer an der der HCP-Assertion (4 Stunden).
Der WS Trust RST Request wird um die e-Health Anwendung ID (103) im OID Codesystem 1.2.40.0.34.5.159 erweitert und in das Attribut "Purpose of Use" der e-Impfpass Kontext-Assertion mit "E-HEALTH-CONTEXT^" präfixiert.
Beispiel: E-HEALTH-CONTEXT^103
Die e-Impfpass Kontext-Assertion muss für alle nachfolgenden Transaktionen im konkreten e-Impfpass Kontext im SOAP Security Header mitgeführt werden.
Die in Abbildung Kontext-Assertion Workflow vorkommenden Schritte werden in den nachfolgenden Unterkapiteln beschrieben.
Anmerkung allgemein zum Thema Abfragen:
Im Rahmen der Identifizierung geschehen zu bestimmten Zeitpunkten auch Abfragen Richtung Z-PI & GDA-I.
Weitere Details dazu siehe
- ELGA Gesamtarchitektur Beschreibung Abschnitt 2.6 – Einheitliche Berechtigung und Protokollierung
- BeS Pflichtenheft Abschnitt 2.1.1 ETS – ELGA Tokenservice mit einer allgemeinen Übersicht über das Zusammenspiel des ETS mit anderen Komponenten (GDA-I, ZPI…)
- BeS Pflichtenheft Abschnitt 3.4 Login Assertions mit Graphiken die die Abfragen an die relevanten Endpunkte darstellen.
- BeS Pflichtenheft Abschnitt 3.5 Abbildung 23 - Treatment-Assertions (Delegierte Assertions).
e-Impfpass RST Issuer Anfrage¶
Um sich im Kontext des e-Impfpass anzumelden, muss mit einer ELGA HCP,
User I, Mandate I, OBST/eHS-Mandate I, einer lokalen IDA eines
vertrauenswürdigen ELGA Bereichs IdPs oder einer PVP2-Assertion
(behördlicher Zugang), mittels WS Trust RST, um eine e-Impfpass
Kontext-Assertion angefragt werden.
Datenelemente e-Impfpass RST:
| Element | Beschreibung |
|---|---|
| wst:RequestType | http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue |
| wst:TokenType | "urn:elga:bes:2019:Context:assertion" Wird verwendet, um die unterschiedlichen Token Typen unterscheiden zu können. |
| urn:tiani-spirit:bes:2013:claims:requested-role | Wenn keine HCP-Assertion als Input verwendet wird, muss die verwendete Aggregat-Rolle des Anfragenden in der Issue Anfrage mit übergeben werden. |
| urn:tiani-spirit:bes:2013:claims:requested-ac | Die angeforderte e-Impfpass Anwendung ID (103) (Siehe Codesystem oid:1.2.40.0.34.5.159) der Kontext-Assertion muss in der Issue Anfrage mit übergeben werden. Der Claim beinhaltet den exakten Wert ‚103’. |
| urn:tiani-spirit:bes:2013:claims: calling-facade | OPTIONAL: Beim Anfordern einer e-Impfpass Kontext-Assertion kann ein ActAs Attribute angegeben werden - WS Trust Issue (wst14:ActAs). Wird ein ActAs Attribute empfangen, wird an Stelle des sonst verwendeten SubjectNameID Wertes, der Wert aus dem RST Claim calling-facade als SubjectNameID eingesetzt. Diese Option steht allen Clients zur Verfügung und es muss im Zuge der Anbindung an ELGA geprüft werden, ob die jeweils richtige Option vom Client verwendet wird und ob der übergebene Wert in calling-facade sinnvoll befüllt ist. |
Tabelle: Datenelemente e-Impfpass Kontext-Assertion RST Issuer Anfrage
Die Verwendung eines "urn:tiani-spirit:bes:2013:claims:requested-ac", der nicht dem Wert 103 entspricht und für den keine andere ELGA bzw. e-Health Anwendung existiert, liefert einen "wst:RequestFailed" SoapFault zurück. In Fällen in denen der "requested-ac" einer anderen existierende e-Health Anwendung entspricht, kann auch eine "wsse:InvalidSecurityToken" SoapFault Fehlermeldungen zurückgeliefert werden.
Wird bei nicht HCP-Assertions als "urn:tiani-spirit:bes:2013:claims:requested-role" eine Rolle angegeben, die dem GDA-OID am GDA-Index nicht zugeordnet ist, wird ein "wsse:FailedAuthentication" SoapFault zurückgeliefert.
Weitere WS Trust und WSSE Fehlerbehandlungen verhalten sich äquivalent zu den bereits in BeS existierenden - siehe BeS Pflichtenheft Abschnitt 5.7. - Fehlermeldungen.
Beispiel e-Impfpass Kontext-Assertion-Request.xml mit HCP-Assertion
Beispiel e-Impfpass Kontext-Assertion-Request.xml mit Aggregat-Rolle
e-Impfpass RST Issuer Anfrage mit HCP¶
Wird als Input-Assertion eine HCP-Assertion verwendet, wird keine erneute Prüfung gegen den GDA-Index durchgeführt und die Rolle wird der HCP-Assertion entnommen und nicht der WS Trust Anfrage. Es sind nur die e-Impfpassrollen für GDA 700, 702, 703, 704, 724 und 729 zulässig. Das WS Trust Element ‚urn:tiani-spirit:bes:2013:claims:requested-role’ muss in der Anfrage nicht enthalten sein.
e-Impfpass RST Issuer Anfrage mit Bereichs IDA¶
Wird als Input-Assertion eine vertrauenswürdige IDA eines ELGA Bereichs IdPs verwendet, wird die Rolle der WS Trust Anfrage entnommen und gegen den GDA-Index geprüft. Für die IDA gelten die Vorgaben, die bereits in ELGA für die Anforderung einer HCP-Assertion definiert sind. In diesem Kontext sind die GDA Rollen 700, 702, 703, 704, 721, 722, 724 und 729 sowie für den behördlichen Zugang die Rollen 716, 717 und 718, zulässig.
e-Impfpass RST Issuer Anfrage mit PVP2¶
Wird als Input-Assertion eine vertrauenswürdige PVP2-Assertion verwendet, wird die Rolle auch der WS Trust Anfrage entnommen und es wird auch hier gegen den GDA-Index geprüft. Als gültige Rollen werden die Rollen 700, 702, 703, 704, 721 und 722 sowie die Rollen für den behördlichen Zugang (716, 717, 718 und 723) akzeptiert.
Bei der GDA-Index Prüfung der e-Impfpass Rollen muss das Attribut ‚elgaRoles‘ entsprechend GDA-Index Servicehandbuch V1.2 herangezogen werden. Das Attribut ‚otherRoles‘ kann optional auch geprüft werden. Die neuen e-Health-Rollen sind in ‚elgaRoles‘ angeführt.
Im Rahmen der Identifikation und Validierung der PVP Assertion werden folgende Datenelemente geprüft:
| Element | Attribut | Prüfung |
|---|---|---|
| rn:oid:1.2.40.0.10.2.1.1.71 | gvOuId des Verbundteilnehmers (PARTICIPANT-ID) |
Muss vorhanden sein und wird als Identifikation der PVP verwendet. Der Validator prüft auf AT:.* - Im Negativfall wird die interne Fehlermeldung "spirit:susi.001.3.00077: The validated value does not match the configured regEx" verwendet. Bei allen Rollen die NICHT 700|702|703|704|721|722 sind wird dieses Attribute gegen den GDA Index geprüft. Die Werte des GDA Index werden in der AC Kontext Assertion verwendet. |
| urn:oid:0.9.2342.19200300.100.1.1 | Benutzerkennung (USERID) | Es erfolgt keine Prüfung. Wird BeS intern als UserID verwendet. |
| urn:oid:1.2.40.0.10.2.1.1.149 | BPK | Bei den Rollen 700|702|703|704|721|722 wird die BPK GH gegen den GDA Index geprüft und die Werte des GDA Index in der AC Kontext Assertion verwendet. |
Tabelle: Prüfung der PVP Assertion
e-Impfpass RST Issuer Anfrage mit e-card Identity-Assertion¶
Wird als Input Assertion eine e-card IDA verwendet, wird die Rolle auch der WS Trust Anfrage entnommen und es wird auch hier gegen den GDA-Index geprüft. Für die e-card IDA gelten die exakt gleichen Vorgaben wie auch bereits heute für e-card Identity-Assertions im Kontext ELGA. Mittels e-card IDA sind die GDA Rollen 700, 702, 703, 704, 721, 724 und 729, sowie für den behördlichen Zugang die Rollen 716 und 717, im WS Trust RST zulässig.
e-Impfpass RSTR Issuer Antwort¶
Die e-Impfpass Kontext-Assertion wird mittels WS Trust RSTR an den Anfragenden zurückgeliefert. Die erhaltene e-Impfpass Kontext-Assertion muss bei allen nachfolgenden Transaktionen an das ELGA Berechtigungssystem im konkreten e-Impfpass Kontext im SOAP Security Header mitgeliefert werden.
Datenelemente e-Impfpass RSTR:
| Element | Beschreibung |
|---|---|
| RequestSecurityTokenResponseCollection | RequestSecurityTokenResponseCollection (RSTRC) wird in der abschließenden Antwort an eine RST Anfrage verwendet werden, um ein Security Token zu retournieren |
| RequestSecurityTokenResponse | Body der Antwort |
| TokenType | urn:elga:bes:2019:Context:assertion |
| RequestedSecurityToken | Beinhaltet die ELGA SAML2 e-Impfpass Kontext-Assertion |
Tabelle: Datenelemente e-Impfpass Kontext-Assertion RSTR
Beispiel e-Impfpass Kontext-Assertion-Response.xml
Beispiel e-Impfpass Kontext-Assertion-Response.xml mit Aggregat-Rolle