AC Kontext-Assertion¶
Eine AC Kontext-Assertion muss vom Client Akteur gelöst werden, um sich in einem AC anzumelden.
Die Verfahren, eine AC Kontext-Assertion anzufordern bzw. zu invalidieren, sind mit denen der ELGA HCP-Assertion identisch. Einzig die Inhalte der einzelnen WS Trust Transaktionen bzw. der SAML Assertions unterscheiden sich geringfügig.
Eine AC Kontext-Assertion wird wie eine HCP-Assertion über die lokale AGW mittels WS Trust RST vom ETS angefordert.
Der WS Trust RST Request wird um eine AC-ID (OID 1.2.40.0.34.5.159) erweitert.
Läuft eine Benutzersession ab oder wurde invalidiert, muss auch die AC Kontext-Assertion beim ETS invalidiert werden.
Die Gültigkeitsdauer der AC Kontext-Assertion ist mit der der HCP-Assertion identisch und beginnt mit der Ausstellung der AC Kontext-Assertion. Wird als Grundlage keine HCP-Assertion sondern eine IDA verwendet, orientiert sich die Gültigkeitsdauer an der HCP-Assertion (4 Stunden und kann einmal erneuert werden). Eine AC Kontext-Assertion auf Basis einer USER I oder MANDATE I Assertion ist 20 Minuten gültig und kann zweimal erneuert werden. Die AC Kontext-Assertion auf Basis einer EU-IDA ist ebenfalls 20 Minuten gültig und kann zweimal erneuert werden.
Die AC Kontext-Assertion ist anstelle der ELGA Login-Assertions zu verwenden, und muss für alle nachfolgenden Transaktionen im SOAP Security Header mitgeführt werden. (Hinweis: Im Kontext AC wird nur eine SAML-Assertion im SOAP Security Header akzeptiert und daher kann mit einer Abfrage nur ein AC adressiert werden.)
Ein AC 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 Login-Assertion (HCP, User, Mandate, PVP, EU-IDA (NCPeH) oder vertrauenswürdiger IdP) benötigt. Der Bürger bzw. der Vertreter kann mittels User I- bzw. Mandate I - auch AC Kontext-Assertion beantragen. Die AC Kontext-Assertion auf Basis einer HCP-Assertion (bzw. auf Basis von GDA Assertions allgemein) kann nur einmalig erneuert werden. Beim Versuch den AC Kontext-Assertion ein zweites Mal zu erneuern, wird die Fehlermeldung "wst:UnableToRenew" SoapFault retourniert. Eine AC 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 AC Kontext-Assertion wird bei allen anderen folgenden Transaktionen die Fehlermeldung "wsse:InvalidSecurityToken" SoapFault zurückgegeben. Beim Versuch, eine Transaktion mit einer HCP-Assertion im Kontext AC durchzuführen, wird der BeS Fehler "spirit:xds.004.3.00020" mit der Meldung "XDS request failed" zurückgeliefert.
Beim Anfordern einer AC-Kontext Assertion kann je nach nationalen Anforderungen die Organisation ID als OID (z.B.: urn:oid:1.2.3.4) oder als HL7v3 Instanz Identifier (z.B.: urn:hl7ii:1.2.3.4:XYZ) angegeben werden. Es wird eine entsprechende Überprüfung beim Validieren der Assertion durchgeführt (regEx="urn:oid:.*|urn:hl7ii:.*").
Der WS Trust RST Request wird um eine e-Health Anwendung-ID im OID Codesystem 1.2.40.0.34.5.159 erweitert und in das Attribut "Purpose of Use" der AC Kontext-Assertion mit "E-HEALTH-CONTEXT^" präfixiert.
Beispiel: E-HEALTH-CONTEXT^103
Die in folgender Abbildung dargestellten Schritte werden in den nachfolgenden Unterkapiteln beschrieben.
Allgemeine Anmerkung 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)
Datenelemente einer Kontext-Assertion:
| Assertion Element | Opt | Usage Convention | ||
|---|---|---|---|---|
| @Version | R | MUST be "2.0" | ||
| @ID | R | SAML assertion identifier NCName encoded (see section 1.3.4 of [SAMLCORE]) | ||
| @IssueInstant | R |
Time instant of issuance in UTC Format: yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fff'Z' |
||
| Issuer | R | Address URI that identifies the endpoint of the issuing service. For the assertion, it is set as the URI representing the ETS | ||
| Subject | R | |||
| NameID | R |
Identifier of the GDA, set as the value returned by the GDA index. Im Falle einer HCP, IDA, EU-IDA, User oder Mandate als Input wird die NameID übernommen. Im Falle einer eCard und PVP als Input: GDAIndex/GdaDescriptor/InstanceIdentifier/id^ GDAIndex/GdaDescriptor/InstanceIdentifier/oidIssuingAuthority@ GDAIndex/GdaDescriptor/InstanceIdentifier/description |
||
| @Format | R | "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" | ||
| SubjectConfirmation | R | |||
| @Method | R | "urn:oasis:names:tc:SAML:2.0:cm:bearer " | ||
| SubjectConfirmationData | X | Not present | ||
| Conditions | R | |||
| @NotBefore | R | Time instant from which the assertion is useable. It is set as the issue instant | ||
| @NotOnOrAfter | R | Time instant at which the assertion expires. Value is @NotBefore+IDA based validity range | ||
| @ProxyRestriction/Count | R | Specifies how often a Login Assertion is renewable. Depending on the input Assertion | ||
| @AudienceRestriction | R | This element contains the list of Audiences, e.g., the contexts (services) for whom the STS issued the assertion (i.e. https://elga-online.at/KBS if ALLOW_KBS="true", https://elga-online.at/ETS and https://elga-online.at/ZPI). Added https://elga-online.at/DSUB as Audience, if ALLOW_DSUB is true, https://elga-online.at/AC_PAP, if CONSENT_SCOPE is NOT ‘no’. | ||
| AuthnStatement | R | |||
| @AuthnInstant | R |
Time instant of authentication in UTC Format: yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fff'Z' |
||
| AuthnContext | R | |||
| AuthnContextClassRef | R | Since the user has been already authenticated in a previous session (which may be unknown to the ETS, given the BeS trust relationship assumptions), the value is set as urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession | ||
| AttributeStatement | R | Identity attributes and permissions | ||
| ds:Signature | R | Enveloped XML signature of the issuer of the Assertion (see: Assertion Signaturlayout in ELGA) | ||
Tabelle: Datenelemente AC Kontext-Assertion
Attribute der Kontext-Assertion:
| HCP subject name | |
|---|---|
| FriendlyName: | XSPA Subject |
| Name: | urn:oasis:names:tc:xacml:1.0:subject:subject-id |
| Values: | Human readable name of the HCP |
|
Type: Source: |
String IDA,HCP,User,Mandate: |
| Structural Role of the HCP | |
| FriendlyName: | ELGA Rolle |
| Name: | urn:oasis:names:tc:xacml:2.0:subject:role |
| Values: | Contains the ELGA role of the GDA, coming from the GDA Index (see ELGA Terminology "ELGA_Rollen 2013-01-10") |
|
Type: Source: |
Hl7v3 coded value IDA,PVP: RST/requested-role checked against GDAIndex/GdaDescriptor/ElgaRoles HCP,User,Mandate: urn:oasis:names:tc:xacml:2.0:subject:role |
| Permissions | |
| FriendlyName: | Permissions |
| Name: | urn:elga:bes:permission |
| Values: | Contains a mapping from the ELGA role of the GDA to permissions (BeS internal ID values) |
| Type: | URN |
| Source: | Permissions are mapped from the ELGA Role - RST/requested-role checked against "GDAIndex/GdaDescriptor/ElgaRoles" |
| Healthcare Professional Organisation ID | |
| FriendlyName: | XSPA Organization Id |
| Name: | urn:oasis:names:tc:xspa:1.0:subject:organization-id |
| Values: | URN encoded OID of the GDA (GDA Index) |
| Type: | URI |
| Source: |
HCP,USER,Mandate: urn:oasis:names:tc:xspa:1.0:subject:organization-id IDA, PVP: GDAIndex/GdaDescriptor/InstanceIndentifier/ID: GDAIndex/GdaDescriptor/InstanceIndentifier/OidIssuingAuthority |
| Local Healthcare Professional Organisation ID | |
| FriendlyName: | Local Organisation ID |
| Name: | urn:elga:bes:2013:local-organisation-id |
| Values: | Local OID of the GDA (OrgID from the local Identity Assertion) |
| Type: | URI |
| Purpose of Use | |
| FriendlyName: | BeS Purpose Of Use |
| Name: | urn:oasis:names:tc:xspa:1.0:subject:purposeofuse |
| Values: | E-HEALTH-CONTEXT^103 |
| Type | URI |
| Source | TokenIssuer configuration |
| Purpose | |
| FriendlyName: | AC Purpose |
| Name: | urn:oasis:names:tc:xacml:2.0:action:purpose |
| Values: | copy of the original PoU of the input assertion |
| Type | URI |
| Source | Input Assertion or TokenIssuer configuration |
| XSPA Patient ID (only with User and Mandate) | |
| FriendlyName: | XSPA Patient ID |
| Name: | urn:oasis:names:tc:xacml:1.0:resource:resource-id |
| Values: | Patient id |
| Type | URI |
| Source | User or Mandate urn:oasis:names:tc:xacml:1.0:resource:resource-id |
| ELGA User Description (only with EU-IDA) | |
| FriendlyName: | ELGA User Description |
| Name: | urn:elga:bes:2023:user-description |
| Values: | User Description |
| Type | URI |
| Source |
Dieser Wert ist nur bei einer EU-IDA vorhanden: urn:oasis:names:tc:xspa:1.0:subject:organization-id ^ urn:oasis:names:tc:xspa:1.0:environment:locality ^ urn:ehdsi:names:subject:healthcare-facility-type |
| XSPA Organization (nur wenn acImport.xml/USE_KONTEXT_ASS_ORG_NAME true) | |
| FriendlyName: | XSPA Organization |
| Name: | urn:oasis:names:tc:xspa:1.0:subject:organization |
| Values: | Organisations-Name aus dem GDA-Index |
| Type: | URI |
| ELGA Personal Role (nur wenn acImport.xml/USE_PERSONAL_ROLE true) | |
| FriendlyName: | ELGA Personal Role |
| Name: | urn:elga:bes:personal-role |
| Values: | Rolle der identifizierten Person laut: ELGA_GTelVoGDARollen - Austrian e-Health Terminology Browser mit dem parent Attribut „10 Teil1: Rollen für Personen“ |
| Type | String |
| Source |
Der Wert der jeweiligen HCP-/ Identity-Assertion: urn:elga:bes:personal-role |
Tabelle: Attribute der AC Kontext-Assertion
Beispiel AC Kontext-Assertion.xml
AC Kontext-Assertion RST Issuer Anfrage¶
Um sich im Kontext eines AC anzumelden, muss mit einer ELGA HCP, User I, Mandate I, OBST/eHS-Mandate I, EU-IDA, einer lokalen IDA eines vertrauenswürdigen ELGA Bereichs IdPs oder einer PVP2-Assertion (behördlicher Zugang), mittels WS Trust RST, um eine AC Kontext-Assertion angefragt werden.
Datenelemente:
| 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-, User- oder Mandate-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 AC Anwendung ID (z.B. 103 für e-Impfpass) (Siehe Codesystem oid:1.2.40.0.34.5.159) der Kontext-Assertion muss in der Issue Anfrage mit übergeben werden. |
| urn:tiani-spirit:bes:2013:claims: calling-facade | OPTIONAL: Beim Anfordern einer AC 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 AC Kontext-Assertion RST Issuer Anfrage
Die Verwendung eines "urn:tiani-spirit:bes:2013:claims:requested-ac", der nicht dem Wert einer e-Health Anwendung entspricht, liefert einen "wst:RequestFailed" SoapFault zurück. In Fällen in denen der "requested-ac" einer anderen existierende e-Health Anwendung entspricht, wird eine "wsse:InvalidSecurityToken" SoapFault Fehlermeldung zurückgeliefert.
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. Im Falle einer EU-IDA wird keine Prüfung gegen den GDA-I durchgeführt.
Wird als Input-Assertion eine User I oder Mandate I verwendet, wird die Rolle der Assertion entnommen. Es wird keine erneute Abfrage an den Z-PI durchgeführt.
Weitere WS Trust und WSSE Fehlerbehandlungen verhalten sich äquivalent zu den bereits in BeS existierenden – siehe BeS Pflichtenheft Abschnitt 5.7. – Fehlermeldungen.
Beispiel AC Kontext-Assertion-Request – IDA 716.xml
Beispiel AC Kontext-Assertion-Request – HCP 702.xml
Beispiel AC Kontext-Assertion-Request – USER.xml
Beispiel AC Kontext-Assertion-Request – MANDATE.xml
AC Kontext-Assertion 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.
AC Kontext-Assertion 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.
Bei der GDA-Index Prüfung der AC 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 |
|---|---|---|
| urn: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
AC Kontext-Assertion 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.
AC Kontext-Assertion RST Issuer Anfrage mit EU Identity-Assertion¶
Wird als Input-Assertion eine EU-IDA verwendet, wird die Rolle der WS Trust Anfrage entnommen. Es wird jedoch keine Prüfung der Rolle bzw. des GDA gegen den GDA Index durchgeführt.
Das Vertrauensverhältnis zwischen BeS und dem NCPeH-AT wird alleinig durch MTLS und der signierten EU-IDA hergestellt. Die EU-IDA enthält nicht die originale Signatur sondern wird von der NCPeH-AT National Connector Implementiert erneut "für BeS" signiert. Details zur EU-Assertion in der Version 6.3 siehe: https://webgate.ec.europa.eu/fpfis/wikis/display/EHDSI/SAML+Profile
AC Kontext-Assertion RSTR Issuer Antwort¶
Die AC Kontext-Assertion wird mittels WS Trust RSTR an den Anfragenden zurückgeliefert. Die erhaltene AC Kontext-Assertion muss bei allen nachfolgenden Transaktionen an das ELGA Berechtigungssystem im konkreten AC Kontext im SOAP Security Header mitgeliefert werden.
Datenelemente 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 den ELGA SAML2 AC Kontext-Assertion |
Tabelle: Datenelemente AC Kontext-Assertion RSTR
Beispiel AC Kontext-Assertion-Response IDA 716.xml
Beispiel AC Kontext-Assertion-Response HCP 702.xml
AC Kontext-Assertion erneuern¶
Siehe ELGA BeS Pflichtenheft Kapitel Erneuern von Login-Assertions
AC Kontext-Assertion invalidieren¶
Siehe ELGA BeS Pflichtenheft Kapitel Invalidieren von Login-Assertions