View source for AuthBox

{{Historical}}
== Description ==

AuthBox is a gizmo that controls access to (the power/enable signal of) a tool, based on a local list of authorized users. That list is updated when needed, based on a master copy stored in the [[CRM]] or probably actually the [[Equipment Access Project]].

== Hardware ==

Power: Be able to cope with 24VAC, full-bridge onboard and a linear reg for logic (we don't need much), though an RFID reader might turn out to be thirsty. (One linear reg down to 12, another down to 5, would spread out the heat and give a handy 12 tap for some readers.)

RFID reader: Anything that reads 125kHz EM40xx tags. Most readers send their bits over 2400bps UART, or 2-wire Wiegand, and the box should accommodate both. Be able to power a 5v or 12v reader.

Equipment-monitoring input: Voltage sense capable of tolerating 240v AC RMS, optoisolated. (Socket for a MID400 and datasheet example circuit, basically.) Current-sense input, assume a small CT so we should have pads for a burden resistor and a few zeners or something, this might deserve some more research. Also, optoisolator for logic-level input. Be nice if these came to separate input pins. TVSS diodes on all these.

Enable output: Suitable for driving a relay coil. Open-collector on a discrete Darlington or FET would be nice, bonus points if the flyback diode and stuff are built in. Output-status LED for diagnosis.

Local storage: Serial flash or FRAM, partly for the user database, partly for logging (all activity is logged locally before being dumped back to the master). Target 300+ user records (each 26 bits of ID plus a few bits of privilege, optionally ~16 chars each for a friendly-name) and 1000+ logged events.

User interaction: Two pushbuttons, two LEDs minimum. Display in the deluxe model. (16x2 character LCD, probably) TVSS on these. A beeper would be nice to register RFID recognition, etc.

RTC: Optional, would be nice for logging.

Communication: Assume esp8266 UART-WIFI module, 115200bps serial. Probably also sane to reserve an extra pin for SPI in case we end up with a different thing, but most are UART or SPI.

== Tool properties ==
Each tool should have the following configuration knobs:

MAC address: This is the tool's unique ID and only one config should reference a given MAC.

Friendly name: For use in reports, also displayed on the tool's idle screen if equipped.

Clone-of: If this points to another tool, all properties below this line are inherited from the other tool and the rest of this config is ignored. This would be so that multiples of a tool could have identical behaviors and user lists, but still be logged separately.

Parent zone: Is this a tool property or specified elsewhere in access control? Would control who can authorize new users, among other things.

Server-unreachable behavior: Fail open, fail to last user db (default), fail closed.

Not-active-yet timeout: When a user first auths up but hasn't activated the tool yet, how long we wait for before logging them out. Set 0 to remain logged in forever until explicit redbutton out.

Has-been-active timeout: When a user has been using the tool but stops, how long we wait before logging them out. Set to 0 to disable timeout, as above.

Pre-timeout warning: If this much time is left before timeout, chirp. Set to 0 to disable.

Extend how many times: To ward off the timeout, hit the green pushbutton, up to this many times. (Note: Sense transitions, not state, to avoid wedged-button defeat.)

Training expires days: Used by auth-list compiler to remove people who haven't used the tool in a long time and need a refresher. (Wishlist feature: Online self-quiz to regain access.)

Key format: Either key-only or key-and-name16 or key-and-name20, depending on whether this tool has a display and how wide it is.

[[Category:Member Projects]] [[Category:Networking]] [[Category:Infrastructure]]