MOA-ID-AUTH


Zusatzinformationen

Inhalt

  1. Datenmanagement
    1. Sessiondaten
      1. Allgemein
    2. Logging von Statistikdaten
  2. Benötigte Netzwerkverbindungen (incoming / outgoing)
  3. Revisions-Logging

1 Datenmanagement

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.

1.1 Sessiondaten

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.

1.1.1 Allgemein

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.

Signaturzertifikat

Das Signaturzertifikat, welches zur Signierung des Authentifizierungsblocks verwendet wurde.

AuthTimeStamp Zeitpunkt an dem sich die Benutzerin oder der Benutzer an MOA-ID-Auth authentifiziert hat.

1.2 Logging von Statistikdaten

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:

  • bku: Fehler während der Kommunikation mit der Bürgerkartenumgebung.
  • moa-sp: Fehler bei der Kommunikation mit MOA-SP oder der Signaturprüfung.
  • mandate: Fehler beim Zugriff auf das Online-Vollmachten Service.
  • moa-id: Fehler während des Authentifizierungsvorgangs.
  • unknown: für allgemeine Fehler die keinem der oben genannten Typen entsprechen.

ExceptionCode

Fehlercode des aufgetretenen Fehlers falls vorhanden.

ExceptionMessage

Fehlermeldung in textueller Form (max. 255 Zeichen lang)

 

2 Benötigte Netzwerkverbindungen (incoming / outgoing)

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

E-ID System vollmachten.stammzahlenregister.gv.at
Test: https://eid.egiz.gv.at/idp/shibboleth
443 ausgehend SAML2 Metadaten des E-ID System

 

3 Revisions Logging

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)

3300

 

SAML1 StartAuthentication Request

4000

 

Identifizierungs- und Authentifizierungsprozess wurde gestartet

4001

 

Identifizierungs- und Authentifizierungsprozess wurde beendet

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

6300 EntityID Zentrales E-ID System ausgewählt
6301 RequestID Zentrales E-ID System kontaktiert
6302 ResponseID Gültige Response vom E-ID System erhalten
6303   Ungültige Response oder Fehlercode vom E-ID System erhalten
6304   Gültige Attribute vom E-ID System erhalten

 

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