© 2001 Ronald Schmidt

1. Einleitung

• CRONOS wird im URZ und 5 weiteren Struktureinheiten benutzt
• seit Oktober: zentrale Zugangsverwaltung für CRONOS in MOUSE
  MOUSE ... Management of User and Services
  Arbeitstitel ... URZ-Datenbank
• 26 verschiedene Zugangsklassen

  +----------+----------------------+ | count(*) | benutzerklassen_name | +----------+----------------------+ | 7884 | stino | | 42 | URZ-Admins | * * * | 1189 | SUN-Pool | | 41 | SUN-VR-Pool | | 21 | SUN-DK-Pool | | 2 | DK-Labor-Samstag | +----------+----------------------+

• 8002 Karten sind ausgegeben
  CRONOS-Karten + TUC-Card mit CRONOS-Funktionalität

• u.U. wird es Zugangssysteme an den UNI-Eingängen geben

  Mittarbeiter brauchen CRONOS-Karten

• Mitarbeiterausweis (TUC-CARD) wird kommen

  Mitarbeiter wollen CRONOS-Funktion nutzen

• steigende Studentenzahlen
  Prognose uni: 8000

• es werden bald mehr als 10.000 Karten im Umlauf sein

• CRONOS beherrscht NUR 9999 Karten

weitere Nachteile von CRONOS:

• Konfiguration ist kompliziert

• jeder Server wird einzeln gewartet
  Raum-Zeit-Zonen (RZZ)

• geschlossenes System
  schlechte (keine?) Weiterentwicklung

• Kosten für Neuanschaffung und Erweiterungen sind hoch
  RAM-Erweiterung

• als Stand-Alone-System entwickelt
  keine Netzwerkintegration

• System skaliert schlecht

  • 32 Geräte pro Bus (RS485 Spezifikation) und pro Server

  • keine Netzwerkintegration der Server

  • Server voneinander unabhängig (Wartungsaufwand)

• Überwachungsfunktionen nur direkt am Server

• viele Extrafunktionen, welche nicht benötigt werden

• es funktioniert

• relativ ausfallsicher
  alle wichtigen Informationen sind auf den Terminal (Endgeräte+Kartenleser)

• Reaktionszeit ist schnell

2. CRONOS an der TUC

• 17 Terminals (Endgeräte+Kartenleser) in der StraNa
• 10 Terminals in der Reichenhainer-Straße
• 6 CRONOS-Server

• DOS-System als CRONOS-Server

• Netzwerk über Samba

• Raum-Zeit-Zonen (RZZ) von Hand gepflegt
  werden später in RZZ-Bits abgebildet

  RZZ-Bit=1(stino) door=1,3,10-20 von bis so mo di mi do fr so 06:00 12:00 x x x x x 14:00 20:00 x x x x

• Zugangsdaten aus MOUSE - stündlich als Flatfile

  09310 Schmidt 1239 00 011101000000000... 00641 Grunewald 0026 00 000000010000000...

• Nachbearbeitung der Daten
  löschen unwichtiger Sätze

• "Job-Funktionalität" von CRONOS
  stündlich werden Zugangsdaten aus Samba-Freigabe eingelesen

Fluß der Zugangsdaten

Kommunikation

• RS232 für Server mit einem Terminal (z.B. beim Pförtner)

• RS485 bidirektionaler Bus bei >1 Terminals an einem Server

• RS485 4-Draht-Bus (DIN 66 348)

• Master-Slave Prinzip
  CRONOS-Server ist Master; Clienten antworten nur auf "Zuruf"

• große Entfernungen ~1000m

• für BUS ~1000m sind Übertragungraten bis 100 kbit/s möglich

• z.B. StraNa: 13 Geräte an einem Server
  Bus geht von Nutzerservice bis B204

Endgeräte (Terminals)

• Siemens Mikrocontroller (80C535?)

• verschiedene RAM-Ausstattung
  abhängig vom Personenkreis

• autarkes System
  funktioniert auch ohne Kommunikation zum Server

• alle Zugangsdaten sind auf Terminal gespeichert

• Stromausfall-kompatibel
  alte Zugangsdaten sofort wieder verfügbar

3. Ansprüche an eine Neuentwicklung

• es muss alles Notwendige können, was CRONOS kann

• alle ausgegebene Karten müssen funktionieren

• alle vorhandene Terminals + Lesegeräte müssen funktionieren

• Nachteile von CRONOS beseitigen

• FLEXIBEL

  • veschiedene Authorisierungssysteme
    Magnetkarte, berührungsloser Chip (TUC-CARD), Biometrie-Systeme

  • einfaches Erweitern des Systems
    Terminals, Server, Bus-Systeme, Subsysteme

• SICHER

  • Überwachung der Funktionalität

  • Logfiles nur für Berechtigte

  • Änderung der Zugangsdaten für verschiedene Struktureinheiten

  • Kopierschutz der Karten (z.B. eine Spur mit Defekt)

• EINFACH

  • zentrale Wartung der Zugangsdaten (Räume, Zeiten, Personen)

  • flexible Definition der Zugangsdaten (Gruppen, Sicherheitsstufen, Gäste ...)

  • modular (einfachere Entwicklung, Teamarbeit)

  • einfach konfigurierbar (Webinterface, Unix-Tools, Telnet)

  • einfach wartbar (zentrale Konfiguration, zentrales Logfile, Paging)

• ROBUST, PERFORMANT

  • so wenig Logik wie möglich auf den Terminals

  • schnelles Propagieren neuer Zugangsdaten

  • kein online-System als Ablösung für CRONOS

• rasche (Ab)Lösung

• die Wunschliste ist noch offen

4. Distributed Access Controll System

DACS-Server

DACS-Server

• Server für ...

  • Anfragen der Authorisierungs-Clienten

  • Abfragen Statistik,Kontrolle, Überwachung

  • Konfiguration der Systeme

  • einheitliche, generische Datenbasis für alle Authorisierungs-System

• zentrale Zugangsdaten

  • Abbildung CRONOS_ID zu Person

  • Abbildung Biometrie-Hash zu Personen

  • benutzt aber Personendaten aus MOUSE falls notwendig
    Cronos-Funktionalität muss aus MOUSE ausgekoppelt werden

  • Zugangsdaten als Access-Controll-Listen (ACL)
    Vorteile:
    • generisch
    • flexibel
    • für alle Systeme offen

Access Controll List

chain       | user        | action       | door  | condition 
-----------------------------------------------------------------------
feiertag    |             | DENY         |       | now()=2001-01-01  
feiertag    |             | DENY         |       | now()=2001-01-01  
feiertag    |             | DENY         |       | now()=2001-01-01  
weekend     |             | DENY         |       | dayofweek(now())=6
weekend     |             | DENY         |       | dayofweek(now())=7
urz_pool    |             | ACCEPT       | 1     | 
urz_pool    |             | ACCEPT       | 2     | 
urz_pool    |             | ACCEPT       | 3     | 
urz_pool    |             | ACCEPT       | 4     | 
dklabor     |             | ACCEPT       | 11    | 
sunpool     |             | ACCEPT       | 12    | 
stino       |             | feiertag     |       | 
stino       |             | weekend      |       | 
stino       |             | DENY         |       | time(now()) > 18:00
stino       |             | DENY         |       | time(now()) < 07:00
URZ-stino   |             | stino        |       | 
URZ-stino   |             | urz_pool     |       | 
URZ-HIWI    |             | urz_pool     |       | 
gott        |             | ACCEPT       |       | 
            | otto        | URZ-stino    |       | 
            | test        | URZ-stino    |       | 
            | xyz         | gott         |       | 
            | ronsc       | stino        | 67    | 
            | ronsc       | URZ-HIWI     |       | 
            | ronsc       | URZ-stino    |       | 
            | gast9       | stino        |       | 
            | gast9       | ACCEPT       | 123   | 

• Zentral oder verteilt ?

  • Online-Systeme erzeugen Abfragelast
    Clienten ohne eigenen Cache, oder mit großen Auth.-Daten

  • Lastverteilung durch verteilte DACS-Server
    Standard-Algorithmen für konsistente Daten

  • Ausfallsicherheit

DACS-Protokoll

• Abfragesprache für Zugangsdaten
  ACL, Abbildung auf Personen
  einzeln, Gruppen, alle

• Steuerung der Module
  Überwachung

• Propagieren von Informationen
  neue Daten, alle Türen AUF/ZU bei Notfall

• Transport der Log-Messages

• Konfiguration
  

• des weiteren ...

  • Authorisierung

  • Verschlüsselung

DACS-Clienten

• DACS-Client (Module)

  • Client für DACS-Server

  • kennen unterschiedliche Anforderungen der End-Systeme

    • CRONOS-Karte

    • Stimmerkennung

    • berührungsloser Chip

CRONOS-Server

• ein CRONOS-Server ist ein Client vom DACS-Server

• Steuert je ein CRONOS-BUS

• enthält CRONOS-relevante Logik

• Umrechnung der Zugangsdaten in RZZ + ACCESS-Listen
  RZZ sind geeigneter für leistungsarme Mikrocontroller
  Auflösung ACL nach Zugangsdaten für Mikrocontroller

• Kompression der Berechtigungsdaten
  fortlaufende Kartenfolgen mit gleichen Eigenschaften werden als ein Satz gespeichert/übertragen

• Vorbereitung der Suchbäume
  virtuelle Kopie der Bäume für jedes Terminal

• Absenden von Anweisungen, wie die Daten in Terminals gespeichert werden sollen

CRONOS-Kommunikation

• Transportierte Informationen

  • Update der Controller (Software, Zugangsdaten)

  • Log-Messages

  • Anfragen von Terminals (z.B. bei unbekannten Karten)

  • Überwachung, Debug

• entweder Message-basiert
  proprietäres Protoll

• oder mCnet (MikroController-Network)

CRONOS-Terminals

Zugangsdaten

• Zugangsdaten als Baum gespeichert
  Vorteile:
  • einfaches Austauschen und Hinzufügen von Knoten
    Memory-Management nicht nötig, da CRONOS-Server vorberechnet

    add mem=X:x slot=Y value1=Z value2= ... del mem=X:x ...

  • keine komplette Reorganisation nach Updates
  • Berechnung des Baumes auf CRONOS-Server "Handlung auf Anweisung"
  • schnelle und effektive Suche

  Nachteile:

  • Speicheroverhead durch Adressierung der Knoten
  • Kommunikationsoverhead
    relativiert sich, da nicht alles geupdatet werden muss

  3170 relevante Einträgen (gepackt) : - avl-baum: 12 schritte - b-baum: 10 schritte

Zugangsdaten

• serialisiert / binäre Suche
  Vorteile:
  • einfache Struktur
  • einfaches Updaten
  • einfacher zu durchsuchen

  Nachteile:

  • Worst-Case (langsamer)
  • komplette Reorganisation bei jedem Update
  • man benötigt eine 2. Datenbasis um Down-Time zu vermeiden

• Raum Zeit Zonen (RZZ)

  • ... sind auf Terminals nur noch Zeitzonen (ZZ)
    Räume sind bekannt und eingeschränkt

  • Linear
    Adressierung durch ZZ-Bit-Vektor je Zugangs-Datum

  • Informationen: Zeiten, Wochentage

  • Zeitinformationen nur auf wenige Tage beschränken
    z.B. Feiertage nicht nötig
    DACS kann in der Nacht Terminals updaten

Terminalsoftware

CRONOS-Terminal

• Thread-basiert , kooperatives Multitasking

• Main-Thread

  • minimalistische Endlosschleife

  • Kommunikation mit Bus (RX-, TX-Queue)

  • Schedulen anderer Threads

  • Update-Code für Remote-Update der Terminalsoftware

• CRONOS-Thread

  • Abfragen der Lesegeräte

  • Suchen im Datenbestand

  • Steuern der Relais

  • Absetzen von Messages/online-Anfragen
    Logmessages, Nachfrage nach unbekannten Karten

• Update-Thread (Zugangsdaten)

  • Epmfang von Update-Anweisungen

  • Bearbeiten des Datenbestand

  • Löschen alter Informationen

• Service-Thread

  • Ping

  • cachen von Logmessages

  • Debug

• evtl. mCnet-Thread

DACS-Schnittstellen

• Management-GUI

  • Client an DACS-Server

  • Webbasiert

• Application Programing Intarface (API)
  für MOUSE, DACS-GUI

• Funktionen

  • Administration

  • Konfiguration

  • Statistiken

  • Logfiles

  • Direkte Steuerung (Notfall, Einbruch)

  • Überwachung der Clienten

4. weiteres Vorgehen

• Studienarbeit (Theorie, Systementwurf, Spezifikation)

• als HIWI (Implementation, Teamarbeit, Fertigstellung)

• Zeiträume ( MM...Mann-Monate ; für Student: 40h/Monat )

  Zeit	Teilprojekt
  3 Monate	Systementwurf, Spezifikation, Protokolle, Anforderungen (Treffen, BrainStorm)
  4 MM	Anfreunden mit Terminals, Controllern, Bus
  3 MM	Entwicklung der Terminalsoftware
  2 MM	Entwicklung des CRONOS-SERVER
  4 MM	Entwicklung des DACS-Server (Stand-Allone)
  2 MM	Entkoppeln der CRONOS-Funktionalität aus Mouse; Einbinden der DACS-API
  2 MM	Schrittweise Umstellung
  17 MM + 3 Monate Entwurf

• DACS - Entwicklungs-Team notwendig
  Wer hat Lust?

© 2001 Ronald Schmidt