Quelltext der Seite James access control interaction

=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 erflogt im Optimalfall in Echtzeit über eine direkte Datenkommunikation ( tcp Verbindung, RESTFULL API, SOAP, etc ). Eine direkte Kommunikation erlaubt Rückschlüsse auf den Erflog oder Misserfolg eines Systemaufrufs innerhalb der Schnittstelle.

metaSEC James kann mehrere ZK Backends zur gleichen Zeit verwalten und mit Daten bespielen.
Ein 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ückgeen. Eventuell besteht hier die Notwenidigkeit 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
			
			
			
			

 
=Identitätsmanagement=
==Anlage Identität / Karten Inhaber==
Die Anlage einer neunen 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 System als Rückgabewert die interne ID der 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. 

=Liste Zutritts Bereich=
Die Listung aller im ZK System angelegten Zonen/Bereiche ist eine notwendige Information zur Anlage eines Karteninhabers mit dem dazugehörigen Zugangsprfil.
Die Liste entspricht einer Ansammlung von Türen, welche ZK systemseits erstellt und verwaltet wird.
Auf die Zutritsbereiche wird nur lesend zugegriffen.
 
=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
Soweit 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“.
 
=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 Backendabhängig.
 
=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 Sonderbereichtigungen 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

==Manuele 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.

 
=Funktionsarten=

==Echtzeit==
Wenn ein ZK Backend on 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!
 
=Sonstige Funktionen=
==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.

=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.
 
=Unterstützte Produkte=