So funktionieren Zugriffsentscheidungen

Diese Seite erläutert das Modell hinter jeder Entsperrung: wer eine Tür passieren darf, in welcher Reihenfolge die Prüfungen ablaufen und wie Access Policies, Berechtigungen und Sicherheitsprüfungen zusammenwirken. Lesen Sie diese Seite zuerst – alle anderen Seiten bauen auf diesen Konzepten auf.

Die additiven Zulassungswege

Ein Benutzer kann über jeden beliebigen Richtlinien- oder Berechtigungsweg Zugang zu einer Tür erhalten. Es genügt, einen Weg zu bestehen; ein Weg schränkt niemals den Zugriff ein, den ein anderer gewährt.

Eine Richtlinie trifft nur zu, wenn Who UND Where UND When zutreffen. Richtlinien sind miteinander ODER-verknüpft. Innerhalb von Who sind Bedingungen zu Personentyp/Status und Tags Alternativen; innerhalb von When sind Zeitfenster vom Typ Weekly und One-time Alternativen. Where kann alle Türen der Einrichtung, Access Scopes, einzelne Türen und Ausschlüsse umfassen.

Beispiel: Eine Richtlinie „Active members“ kann den Bereich Front entrances mit Anytime abdecken, während eine separate Richtlinie „Staff“ alle Türen der Einrichtung außer dem Technikraum abdeckt. Eine Reinigungskraft, auf die keine von beiden zutrifft, kann trotzdem eine dauerhafte Berechtigung für den Bereich Service entries erhalten.

Dauerhafte Berechtigungen und Zeitfenster von Administratoren bzw. Integrationen bleiben separat und additiv. Änderungen an Richtlinien und der automatische Import übernehmen oder entfernen sie nicht.

Performance Hub-Mitarbeitende, die in Users synchronisiert werden, erhalten Türzugang über die bearbeitbare Richtlinie Performance Hub staff, wie bei jeder anderen Richtlinie. Siehe Synchronisierung und Integrationen.

Der vollständige Entscheidungsablauf

Wenn ein Benutzer in der mobilen App auf Unlock tippt, prüft der Server Folgendes in dieser Reihenfolge. Die erste fehlgeschlagene Prüfung lehnt die Entsperrung ab und erfasst den Grund in den Zugriffsprotokollen.

1. Ist der Zugriff des Benutzers aktiviert? Der Schalter Access enabled in der Zeile des Benutzers unter Users ist ein Not-Aus-Schalter für Administratoren. Gelöschte, deaktivierte oder durch die Synchronisierung blockierte Benutzer können unabhängig von Richtlinien oder Berechtigungen nicht entsperren. (Zum Beispiel: access_disabled.)
2. Ist die Tür blockiert oder im Wartungsmodus? Ein explizites blockAllAccess lehnt jeden Weg für Mitglieder ab. Der Wartungsmodus Force closed hält die Tür verriegelt und für Mitglieder außer Betrieb; Force open hält die Tür entsperrt. Administratoren können eine Tür aus der Ferne entsperren; jede Administrator-Entsperrung wird in den Zugriffsprotokollen erfasst.
3. Ist ein additiver Zulassungsweg erfolgreich?
   • Richtlinienweg: Jede aktivierte benannte Richtlinie, bei der Who, Where und When zutreffen, gewährt Zugriff.
   • Weg über dauerhafte Berechtigungen: Eine Berechtigung für die Einrichtung, die Tür oder einen Access Scope, der die Tür enthält, gewährt Zugriff, wenn ihre optionalen Zeiten zutreffen.
   • Weg über Benutzer-Zeitfenster: Ein von Administratoren verwaltetes Access Time Window ist aktiv und zielt auf diese Tür, diese Einrichtung oder einen Access Scope, der die Tür enthält.
   • Weg über Integrations-Zeitfenster: Ein aktuelles Zeitfenster aus der Quelle ist aktiv, und seine konfigurierte scope_key-Zuordnung zielt auf diese Tür. Veraltete oder nicht zugeordnete Zeitfenster aus der Quelle schlagen sicher fehl.
   • Ist keiner erfolgreich → abgelehnt (no_matching_policy_or_grant)
4. Geofence-Prüfung (falls aktiviert). Anhand des vom Telefon gemeldeten Standorts:
   • Konnte das Telefon keinen Standort liefern → abgelehnt (location_unavailable)
   • Ist die GPS-Messung ungenauer als die Einstellung Require GPS accuracy better than → abgelehnt (gps_too_imprecise)
   • Überschreitet die Entfernung des Benutzers vom Mittelpunkt des Geofence Radius + GPS-Genauigkeit + Genauigkeitspuffer → abgelehnt (outside_geofence)
   • Maßgeblich ist der Server – ein gefälschter Standort auf dem Telefon wird serverseitig trotzdem abgelehnt.
5. Ist die Türsteuerung online? Hat sich die Steuerung nicht gemeldet (Lebenszeichen innerhalb der letzten 5 Minuten), kann die Entsperrung nicht zugestellt werden (device_offline). Wird der Befehl gesendet, die Steuerung bestätigt ihn aber nicht, wird das Ereignis als Timed out erfasst.
6. Entsperren. Das Relais gibt für die Hold time der Tür frei (1–30 Sekunden, Standard 10) und verriegelt dann automatisch wieder. Das Ereignis wird als Confirmed unlocked erfasst, sobald die Steuerung es bestätigt.

Zeitfenster vom Typ One-time sowie begrenzte Zeitfenster vom Typ Weekly verwenden ganzzahlige Unix-Sekunden als Grenzen und halboffene Intervalle [from, to): Der Beginn zählt dazu, das Ende nicht. Wöchentliche Blöcke verwenden ihre angegebene IANA-Zeitzone sowie die lokalen Regeln für Ortszeit und Sommerzeit. Siehe Zeitpläne für Access Policies.

Neue Clients erhalten bei einer Tür, die nur in einem künftigen Zeitfenster nutzbar ist, die Detailangabe outside_access_time_window sowie strukturierte Angaben zur nächsten Verfügbarkeit. Während der Übergangsphase zur Kompatibilität erhalten ältere Clients weiterhin outside_access_hours als Hauptgrund, sodass die Tür sicher deaktiviert und sichtbar bleibt.

Bestehende Konfiguration

Die bestehende Zugriffskonfiguration wird automatisch in Access Policies importiert. Der Import übernimmt, wer Zugriff hatte, welche Türen oder Access Scopes diese Personen nutzen konnten und welche Zeiten galten, als Werte für Who, Where und When in den Richtlinien. Administratoren verwalten die resultierenden Richtlinien direkt; es gibt keinen Rollout-Modus und keine manuelle Umstellung.

Die Geofence-Vererbung bleibt unabhängig von Access Policies. Auch bei zutreffenden Richtlinien werden der wirksame Geofence sowie alle anderen Sicherheits- und Geräteprüfungen weiterhin durchlaufen.

Was die OTP-Anmeldung bewirkt und was nicht

Die Anmeldung bei der mobilen App (Einmalcode per SMS oder E-Mail) dient nur der Authentifizierung – sie belegt, wer der Benutzer ist. Sie gewährt keinen Türzugang von sich aus. Jede Entsperrung wird einzeln anhand des oben beschriebenen Entscheidungsablaufs autorisiert. Ein Benutzer kann in der App angemeldet sein und trotzdem „You don't have access to this door.“ sehen.

Glossar

Verwandte Seiten

• Access Policies – Who, Where, When und der automatische Import
• Zeitpläne für Access Policies – Anytime, Weekly und One-time
• Access Scopes – wiederverwendbare Türbündel
• Geofencing – Standortprüfungen
• Users – benutzerbezogene Berechtigungen und der Not-Aus-Schalter
• Referenz – alle Ablehnungsgründe und Standardwerte in einer Tabelle
• Türen können auch in Duress-Reaktionen einbezogen werden. Siehe Reaktionsaktionen unter Duress.