MOA-ID-AUTH


Zusatzinformationen

Inhalt

  1. Datenmanagement
    1. Sessiondaten
      1. Allgemein
      2. Single Sign-On
    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.

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.

1.1.2 Single Sign-On

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.

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

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

 

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)

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

4002

 

Anmeldeprozess mit Online Vollmachten

4003

 

Anmeldeprozess mit STORK

4004

 

Anmeldeprozess mit Single Sign-On

4005

 

Ungültige Single Sign-On Session

4006

 

Benutzeranfrage für Single Sign-On Verwendung gestellt

4007

 

Benutzerantwort für Single Sign-On Verwendung empfangen

4008

 

Anmeldeprozess über IDP Föderation

4009

 

Gültige Response von föderiertem IDP erhalten

4010 EntityID des IDP Verwendeter IDP für föderierte Anmeldung

4011

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