Dieser Abschnitt spezifiziert jene Datensätze die während eines Anmeldevorgangs durch das Modul MOA-ID-Auth temporär oder permanent gespeichert werden. Hierbei handelt es sich sowohl um temporäre Sessiondaten als auch um dauerhaft gespeicherte Statistikdaten.
Dieser Abschnitt behandelt jene Informationen die das Modul MOA-ID-Auth während eines Authentifizierungsvorgangs oder während einer aktiven Single Sign-On Session im Speicher hält. Diese Datensätze werden nach Beendigung des Anmeldevorgangs, bei einfacher Anmeldung, oder nach Beendigung der Single Sign-On Session gelöscht. Die nachfolgenden Unterkapitel geben eine Aufstellung jener Daten die von MOA-ID im jeweiligen Falle gespeichert werden.
Folgende Daten müssen mindestens von MOA-ID gecached werden um einen korrekten Anmeldevorgang zu ermöglichen.
Element |
Beschreibung |
Authentication Request |
Dieser wird von der Online-Applikation als Start des Anmeldevorgangs übertragen. |
Session ID |
Wird von MOA-ID generiert und dient zur Identifikation von Datensätzen. |
Personenbindung |
Die Personenbindung der Benutzerin oder des Benutzers. |
AuthBlock |
Der Authentifizierungsblock, welcher im Rahmen des Anmeldevorgangs vom der Benutzerin oder dem Benutzer signiert wird. |
Signaturzertifikat |
Das Signaturzertifikat, welches zur Signierung des Authentifizierungsblocks verwendet wurde. |
Vollmacht |
Die Online-Vollmacht, welche bei einer Anmeldung in Vertretung ausgewählt wurde. |
STORK |
Alle Attribute, welche bei einer Anmeldung mittels STORK übertragen werden. |
| AuthTimeStamp | Zeitpunkt an dem sich die Benutzerin oder der Benutzer an MOA-ID-Auth authentifiziert hat. |
Im Falle einer Anmeldung mit Single Sign-In werden zusätzlich zu den oben genannten Elementen noch weitere Datensätze gecached.
Element |
Beschreibung |
SSO Session Token |
Das SSO Session Token dient zur Identifizierung einer aktuell bestehenden Single Sign-On Session. |
| UpdateTimeStamp | Zeitpunkt des letzten Zugriffs der Benutzerin oder des Benutzers mittels SSO. |
Liste: ungültige SSO Token |
Eine Liste aller in dieser Single Sign-On Session bereits vergebenen und verwendeten SSO Session Token. |
Liste: Online-Applikationen |
Eine Liste aller Onlineapplikationen an denen im Rahmen dieser SSO Session eine Anmeldung stattgefunden hat. |
Zusätzlich zu den Daten aus den temporären Sessiondaten werden vom Modul MOA-ID-Auth auch Logging- und Statistikdaten generiert, welche nicht automatisiert gelöscht werden. Diese Daten dienen der Statuskontrolle und zur Protokollierung von Anmeldevorgängen an MOA-ID-Auth. Von MOA-ID-Auth werden folgende Statistikdaten je Anmeldevorgang gespeichert, wobei je nach Art der Anmeldung nicht alle Datenelemente gefüllt werden. Die nachstehende Tabelle beschreibt den maximalen Umfang der Loggingdaten, wobei keine Informationen zur anmeldenden Person gespeichert werden.
Element |
Beschreibung |
timestamp |
Datum und Uhrzeit des Eintrags. |
OAID |
Eindeutige Datenbank ID der Online-Applikation. |
OAURLPrefix |
Publik URL Prefix der Online-Applikation |
OAFriendlyName |
Bezeichnung der Online-Applikation |
isBusinessService |
„True“ wenn die Online-Applikation aus dem privatwirtschaftlichen Bereich stammt. |
OATarget |
Bereichskennzeichen der Online-Applikation (Target oder privatwirtschaftlicher Bereich) |
BKUType |
Art der Bürgerkartenumgebung die für den Anmeldevorgang verwendet wurde. (online, local, handy) |
BKUURL |
URL der verwendeten Bürgerkartenumgebung |
isSSOLogin |
„True“ wenn die die Anmeldung als Teil einer SSO Anmeldung erfolgt ist. |
isMandateLogin |
„True“ wenn die Anmeldung in Vertretung erfolgt ist. |
MandateType |
Art der verwendeten Vollmacht (Einzelprofile des Vollmachtenservice oder OID des Organwalters / berufsmäßigen Parteienvertreters) |
MandatorType |
„jur“ / „nat“ je nach Art der vertretenen juristischen oder natürlichen Person |
isPV |
„True“ wenn die Anmeldung in Vertretung durch einen Organwalter oder berufsmäßigen Parteienvertreter erfolgt ist. |
PVOID |
OID des Organwalter oder berufsmäßigen Parteienvertreter |
ProtocolType |
Type des für die Anmeldung verwendeten Authentifizierungsprotokolls. (PVP21, OpenID, SAML1) |
ProtocolSubType |
Nähere Spezifizierung des Protokolltyps. (Im Falle von PVP 2.1: POST oder Redirect) |
ExceptionType |
Typ des Fehlers der während des Anmeldevorgangs aufgetreten ist. Aktuell werden folgende Typen unterschieden:
|
ExceptionCode |
Fehlercode des aufgetretenen Fehlers falls vorhanden. |
ExceptionMessage |
Fehlermeldung in textueller Form (max. 255 Zeichen lang) |
Für die Betrieb des Modules MOA-ID-Auth werden Netzwerkverbindungen zu externen Service benötigt. Die nachfolgende Tabelle gibt eine Aufstellung der benötigten Verbindungen und eine kurze Beschreibung über deren Funktion.
| Service | URL | Port | Richtung | Beschreibung |
MOA-ID-Auth |
* | 80, 443 | eingehend | Front-Channel und Back-Channel Verbinding zum IDP |
MOA-ID-Auth |
* | 80, 443 | ausgehend | Abholen von Template oder PVP 2.1 Metadaten |
| LDAP | * | 389, 636 | ausgehend | Zertifikatsprüfung |
OSCP / CRL |
* | 80, 443 | ausgehend | Zertifikatsprüfung |
| OVS | vollmachten.stammzahlenregister.gv.at Test: vollmachten.egiz.gv.at |
443 | ausgehend | Online-Vollmachten Service (MIS) via SOAP Service |
| SZR-Gateway | gateway.stammzahlenregister.gv.at Test: szrgw.egiz.gv.at |
443 | ausgehend | Stammzahlenregister Gateway via SOAP Service |
Ab der Version 3.x von MOA-ID-Auth steht zusätzlich zum normalen Logging und zur Generierung von Statisikdaten ein spezielles Reversions Logging zur Verfügung. Dieses Revisions Logging erstellt ein spezielles Log welches Informationen zum Identifikations- und Authentifikationsprozess mit Zeitstempel und Eventcode beinhaltet. Die Events, welche durch dieses Log aufgezeichnet werden lassen sich je MOA-ID-Auth Instanz und je Online-Applikation konfigurieren. Das Revisions Logging kann über die folgende Zeilen in der log4j Konfiguration der MOA-ID Instanz konfiguriert werden:
log4j.logger.at.gv.egiz.eventlog.plain.all=info,reversion
log4j.appender.reversion=org.apache.log4j.RollingFileAppender
log4j.appender.reversion.File=$logDirectory/moa-id-reversion.log
log4j.appender.reversion.MaxFileSize=10000KB
log4j.appender.reversion.MaxBackupIndex=9999
log4j.appender.reversion.layout=org.apache.log4j.PatternLayout
log4j.appender.reversion.layout.ConversionPattern=%5p | %d{dd HH:mm:ss,SSS} | %t | %m%n
Die nachstehenden Tabellen beschreibt alle Events welche aktuell in MOA-ID zur Verfügung stehen, wobei die erste Tabelle alle Basisevents beinhaltet die von MOA-ID auf jeden Fall geloggt werden. Die in der zweiten Tabelle angegebenen Events sind immer einer Session und einer Transaktion aus Tabelle 1 zugeordnet und können durch die MOA-ID Konfiguration ausgewählt werden.
EventCode |
Wert |
Beschreibung |
1000 |
SessionID |
Eine neue Session wurde mit der angegebenen ID gestartet |
1001 |
SessionID |
Die Session mit der angegebenen ID wurde beendet |
1002 |
IP Adresse |
IP Addresse des Hosts der die Session geöffnet hat |
1003 |
SessionID |
Die Session mit der angebenden ID wurde wegen eines Fehler beendet |
1100 |
TransaktionsID |
Eine neue Transaction wurde mit der angegebenen ID gestartet. Eine Transaktion ist immer eine Session zugeordnet |
1101 |
TransaktionsID |
Die Transkation mit der angegebenen ID wurde beendet |
1102 |
IP Adresse |
IP Addresse des Hosts der die Transaction geöffnet hat |
1103 |
TransaktionsID |
Die Transkation mit der angebenden ID wurde wegen eines Fehler beendet |
EventCode |
Wert |
Beschreibung |
3000 |
Protokolltype |
Type des verwendeten Authentifizierungsprotokolls (OpenID Connect, PVP2, STORK, SAML1) |
3100 |
|
PVP 2.x Metadaten Request |
3101 |
|
PVP 2.x Authentifizierungsrequest |
3102 |
|
PVP 2.x Authentifizierungsresponse |
3103 |
|
PVP 2.x Single LogOut Request |
3104 |
|
PVP 2.x Attribute Query (im Fall IDP Interfederation mit zwischen MOA-IDs) |
3200 |
|
OpenID Connect Auth Requsst |
3201 |
|
OpenID Connect Tokken Request |
3300 |
|
SAML1 StartAuthentication Request |
| 3400 | eIDAS Metadata Request | |
| 3401 | Request ID | Eingehender eIDAS Authentication Request |
| 3402 | Response ID | eIDAS Authentication Response erstellt |
4000 |
|
Identifizierungs- und Authentifizierungsprozess wurde gestartet |
4001 |
|
Identifizierungs- und Authentifizierungsprozess wurde beendet |
4004 |
|
Anmeldeprozess mit Online Vollmachten |
4005 |
|
Anmeldeprozess mit STORK |
4006 |
|
Anmeldeprozess mit Single Sign-On |
4007 |
|
Ungültige Single Sign-On Session |
4008 |
|
Benutzeranfrage für Single Sign-On Verwendung gestellt |
4009 |
|
Benutzerantwort für Single Sign-On Verwendung empfangen |
4010 |
|
Anmeldeprozess über IDP Föderation |
4011 |
|
Gültige Response von föderiertem IDP erhalten |
| 4012 | EntityID des IDP | Verwendeter IDP für föderierte Anmeldung |
4013 |
Service Identifikator |
Eindeutiger Identifikator der/des Online-Applikation/Service an der/dem die Anmeldung erfolgt |
4110 |
|
BKU Auswahl gestartet |
4111 |
Bkutype (z.b. online, handy, local) |
Ausgewählter BKU Type |
4112 |
URL |
Verwendete BKU URL |
4113 |
IP Adresse |
IP Adresse mit der die BKU Daten an MOA-ID liefert |
4220 |
|
Personenbindung ausgelesen und gültig validiert |
4221 |
|
Signaturzertifikat ausgelesen und validiert |
4222 |
|
AuthBlock signiert und gültig validiert |
4223 |
|
Wechsel in den Modus für ausländische Signaturkarten |
4224 |
|
SZR-Gateway wird kontaktiert |
4225 |
|
Personenbindung von SZR-Gateway erhalten |
4300 |
ReferenceID des Vollmachtensystems |
Online-Vollmachten Service wird kontaktiert |
4301 |
|
Redirekt zum Online-Vollmachten Service |
4302 |
|
Vollmacht vom Online-Vollmachten Service erhalten |
| 4400 | IDP initiated Single LogOut Request erhalten | |
| 4401 | Single LogOut Process gestartet | |
| 4402 | Single LogOut Process erfolgreich beendet | |
| 4403 | Unvollständiger Single LogOut Prozess | |
5000 |
bPK |
bPK bei Vollmacht mit berufsmäßigem Parteienvertreter oder Organwalter |
5001 |
OID |
OID bei Vollmacht mit berufsmäßigem Parteienvertreter oder Organwalter |
5002 |
JSON String |
Pseudoanonymisierte Personendaten der sich anmeldeten natürlichen Person. |
5100 |
Vollmachtstype |
Type der ausgewählten Vollmacht |
5101 |
jur / nat |
Vollmacht - Type der vertretenen Person (Juristische / natürliche Person) |
5102 |
JSON String |
Pseudoanonymisierte Personendaten der vertretenen natürlichen Person. |
5103 |
baseID |
Stammzahl der vertretenen juristischen Person |
| 6000 | ReferenceID zum Auth. Prozess | externes Vollmachten Service kontaktiert |
| 6001 | ReferenceID des Vollmachhtenservice | gültige Vollmacht vom externen Vollmachten Service verarbeitet |
| 6002 | Fehler vom externen Vollmachten Service verarbeitet | |
| 6003 | IP Adresse | IP Adresse mit der das externe Vollmachten Service die Vollmacht ausgeliefert hat |
| 6004 | EntityID | EntityID des externen Vollmachten Services an welches die Anfrage gesendet wird |
| 6100 | EntityID | eIDAS Node ausgewählt |
| 6101 | RequestID | eIDAS Node kontaktiert |
| 6102 | ResponseID | Gültige Response von eIDAS Node erhalten |
| 6103 | Ungültige Response oder Fehlercode von eIDAS Node erhalten | |
| 6104 | Personenbindung für Authentifizierung über eIDAS Node erstellt | |
| 6200 | Anmeldung via nationalen zentralen eIDAS Knoten gestartet | |
| 6201 | RequestID | Weiterleitung an zentralen eIDAS Knoten mit RequestID |
| 6202 | ResponseID | Antwort von zentralem eIDAS Knoten mit ResponseID erhalten |
| 6203 | Antwort von zentralem eIDAS Knoten enthält einen Fehler | |
| 6204 | Antwort von zentralem eIDAS Knoten vollständig und gültig |
Einzelne Events werden um einen Transaktionsparameter ergänzt, welcher in der Spalte Wert beschrieben ist.
Die pseudoanonymisierten Personendaten für natürliche Personen werden anhand des nachfolgenden Schemas generiert. Als pseudoanonymisiertes Personendatum dient der SHA256 Hash über die in eine JSON Struktur eingetragenen Personendaten. Hierfür wird das folgende JSON Schema verwendet, welches als Input für die SHA256 Berechnung dient.
{"person":{"givenname":"Vorname der Person","familyname":"Nachname der Person","dateofbirth":"Geburtsdatum der Person"},"salt":"Zufallszahl"}
Anschließend wird das pseudoanonymisiert Personendatum als JSON Wert bei den entsprechenden Events eingetragen. Der eingetragener JSON Wert entspricht dem folgenden Schema
{"hash":"BASE64 codierte Personendatum","salt:"Zufallzahl welche zur Generierung des Personendatums verwendet wurde"}
