Funktionsarten #

Echtzeit #

Wenn ein ZK Backend im online Modus arbeitet, werden geschriebene Daten direkt übertragen und verarbeitet. Eventuelle Fehler werden vom System negativ quittiert und die im James verankerte Logik kann entsprechend reagieren.

Abfrage Status Schnittstelle #

Abfrage Systemstatus #

Stapelverarbeitung #

Bei der Stapelverarbeitung, i. d. R. bei Verarbeitung von CSV Dateien (auch XML, etc.) wird ein Datenstapel in ein Kommunikationsverzeichnis abgelegt. James hat weder Kenntnis über den Zeitpunkt der Verarbeitung, noch den Erfolg oder Misserfolg des Vorgangs. Die mittlere Latenzzeit bis zur tatsächlichen Übertragung und Anwendung von Änderungen kann sich negativ auf das Sicherheitskonzept auswirken und sollte stets bedacht werden!

Abfrage Status Hardware #

Manche ZK System bieten die Möglichkeit den Status von Hardwarekomponenten direkt über die API abzufragen. Aus diesem Systemzustand kann man z.B. bei kritischen Systemteilen Workflows verketten im Falle eines Ausfalls.

Zeitprofile #

Für die Ausweisstelle sind eventuell Zeitprofile von Interesse. Die Abfrage der Zeitprofile kann zur genaueren Bestimmung von individuellen Zugriffsrechten herangezogen werden. Die Abfrage erflog im Standardinterface nur lesend. Abfrage Kameras Manche ZK Systeme können eine Kamera/Kameraquelle zu einer Tür asoziieren. Diese kann vom eventuellen Interesse für Global Desk oder die WebApp sein. Abfrage Stichprobe / Zufallskontrolle metaSEC James bietet die Funktion der Stichprobe als Erweiterung/Aufwertung des ZK Systems. Manche ZK Systeme bieten die Funktionalität jedoch aus dem Standard an. in dem Fall würde die ZK Systemseitige Funktion verwendet werden.

Türen #

Die Abfrage von einzelnen Türen und den Zuständen dieser ist eine wichtige Anforderung an die Schnittstelle. Diese ist entsprechend notwendig zur Erteilung von abweichenden Einzelberechtigungen.

Liste Türen #

Die Listung der Türen ist optional, jedoch notwendig zur Erteilung von Sonderberechtigungen für einen Karteninhaber. Soweit vom ZK Backend unterstützt kann eine Sonderberechtigung sowohl als positiv als auch als negativ Liste verwaltet werden.

Abfrage Türstatus #

Analog der Relaissteuerung ist die Abfrage des Zustandes einer Tür für eventuelle Steuerungen oder Visualisierungen notwendig. Der Status einer Tür kann i.d.r. folgende Zustände haben: – Offen – Dauer auf – Geschlossen – Verriegelt – Zeitüberschreitung / Alarm
Die jeweiligen Zustände sind abhängig von ZK Backend.

Manuell Türsteuerung #

Analog der Relaissteuerung kann die manuelle Interaktion mit einer Tür von Wichtigkeit sein. Das Steuern einer Tür wird über eine entsprechende Statusänderung herbeigeführt.

Events #

Events sind Aktionen welche von ZK Backend emittiert oder empfangen werden können. Je nach Fluss Richtung kann die Gegenseite dieses Event mit weiteren Aktionen verknüpfen. Ein einfaches Beispiel ist hier, dass eine Aktion ausgeführt wird, wenn jemand ein Token an eine unberechtigte Tür präsentiert.

Abfrage Eventlog #

Abfrage einer Liste (gesamt oder gefiltert) des Eventlogs. Die Liste kann sich von Backend zu Backend unterscheiden.
Im einfachsten Fall erhält die Ausgabe folgende Felder: Datum, Uhrzeit, Eventtype, Beschreibung, Eventsource

Subscritpion auf einen singulären Event #

Soweit das Backend im online Modul läuft, kann eine s.g. Subscription auf gewissen Eventtypen erflogen. Dieses hat den Vorteil, dass das Programm nicht alle Events vom System empfangen und verarbeiten muss. Die Unterstützung für Eventssubscriptions ist Backend abhängig.

Relais Steuerung #

Manche ZK-Systeme unterstützen neben Türsteuerungen ebenfalls reine Relais / IO Baugruppen. Diese unterscheiden sich in einfache Relais oder digitale Input/Output Kontakte.

Die Kontakte können wahlweise im Global Desk zur manuellen Interaktion oder in Workflows verwendet werden. Liste verfügbarer Relais Listet die verfügbaren Kontakte auf. Der Aufbau der Liste ist, Kontaktart (Relais, Digital IN, Digital Out) Statusabfrage Abfrage eines einzelnen Kontakts oder einer Liste / Array. Dieses ist besonders bei Visualisierungen von Bedeutung.

Steuerung von IO Zuständen so weit unterstützt, Statusänderung bei Relaiskontakten, rsp digital Out.
Bei digitalen Input Kontakten kann der Zustand nicht geändert werden. Hier kann nur ein Event generiert werden, bei externer Statusänderung – siehe Kapitel „Events“.

Liste Zutritts Bereich #

Die Listung aller im ZK System angelegten Zonen/Bereiche ist eine notwendige Information zur Anlage eines Karteninhabers mit dem dazugehörigen Zugangsprofil. Die Liste entspricht einer Ansammlung von Türen, welche ZK systemseits erstellt und verwaltet wird. Auf die Zutrittsbereiche wird nur lesend zugegriffen.

Identitätsmanagement #

Anlage Identität / Karten Inhaber #

Die Anlage einer neuen Identität im ZK Backend benötigt mindestens die o.g. Pflichtfelder. Systemabhängig können weitere Felder benötigt werden. Sollte dieses der Fall sein, so werden diese Notwendigkeiten spezifisch im Treiber abgefangen und vervollständigt. Soweit mit der Schnittstelle online kommuniziert wird (siehe Kapitel Funktionsarten), können eventuell Fehler direkt abgefangen werden. Bei Stapelverarbeitung z. B. über CSV Dateien kann nicht unbedingt immer zuverlässig der Erfolg einer Verarbeitung festgestellt werden. Bei erfolgreicher Anlage liefern die meisten Systeme als Rückgabewert die interne ID des Kartenobjektes. Diese ID wird intern in der James Datenbank gespeichert.

Modifikation Identität / Karten Inhaber #

Abhängig von der Funktionsweise der Schnittstelle (online/Stapel) wird eine Änderung der Eigenschaften in Echtzeit oder verzögert verarbeitet. Der Ablauf selbst ist analog einer Anlage. Bei Stapelverarbeitung gibt es eine Systembedingte Latenz bis die Änderung ( z. B. Zugangsprofil) im ZK Backend verarbeitet wird und entsprechend tatsächlich greift! Dieses ist in Sicherheitskonzept zu bedenken.

Löschung Identität / Karten Inhaber #

Abhängig von der Funktionsweise der Schnittstelle (online/Stapel) wird eine Löschung einer Identität in Echtzeit oder verzögert verarbeitet. Abhängig vom ZK System verblieben noch weitere Daten (z. B. Bewegungsarten, Logbücher, etc.) weiterhin im System. Eventuell ergeben sich hierdurch DSGVO relevante Themen. Bei Stapelverarbeitung gibt es eine Systembedingte Latenz bis die Änderung ( z. B. Zugangsprofil) im ZK Backend verarbeitet wird und entsprechend tatsächlich greift! Dieses ist in Sicherheitskonzept zu bedenken.

Spezifikation metaSEC James ZK Schnittstelle #

Dieses Dokument beschreibt die generellen Notwendigkeiten an ein angeschlossenes elektronisches Zugangskontroll-Backend (nachfolgend ZK System genannt) aus Sicht der James Ausweisstelle als auch der Besuchermanagementprozesse.

Nicht alle ZK Systeme unterstützen alle Funktionsaufrufe. Fehlende Funktionalitäten im ZK Produkt können nicht seitens der Ausweisstellenlogik kompensiert werden.

Eine Schnittstelle rsp. die Kommunikation über diese erfolgt im Optimalfall in Echtzeit über eine direkte Datenkommunikation ( tcp Verbindung, RESTFULL API, SOAP, etc ). Eine direkte Kommunikation erlaubt Rückschlüsse auf den Erfolg oder Misserfolg eines Systemaufrufs innerhalb der Schnittstelle.

metaSEC James kann mehrere ZK Backends zur gleichen Zeit verwalten und mit Daten bespielen. Eine Liste der aktuell unterstützen Zugangskontrollprodukte und der jeweiligen Versionen können beim Support erfragt werden.

Identität / Karteninhaber Datenfelder #

Folgende Felder können von der James Schnittstelle verarbeitet werden:
Feld Typ Pflichtfeld Beschreibung Name Char Ja Name des Karteninhabers Vorname Char Nein Vorname des Karteninhabers Gültigkeit Date Nein Gültigkeit der Karte / Startdatum Kartennummer Char, Array Ja Kartenummer der Karte / Tokens

WICHTIG: die gleiche Karte kann an unterschiedlichen Lesern unterscheidliche Seriennummern zurückgeben. Eventuell besteht hier die Notwendigkeit von Karten Mappings.

Berechtigter Bereich Array Ja Für den Karteninhaber berechtigte Bereiche innerhalb des ZK Systems Berechtigte Tür Array Nein Berechtigung auf eine einzelne Tür(en) Ablauf Profil date Nein Gültigkeit der Karte / Ablaufdatum Foto Blob Nein Foto des Karteninhabers Pin Int Nein PIN Code für die Karte / Mehrfaktor Profile