Open successbyfailure opened 6 years ago
Hola,
Sigue esto siendo relevante?
Absolutamente! Hay que terminar de definir la solución técnica global.
A la larga sería un directorio activo para almacenar los usuarios, unos lectores RFID con esphome que transmiten el id del usuario por mqtt. Ahí faltaría una pieza que escucha el mqtt y cuando ve el código del rfid comprueba en el directorio activo si está activo y entonces lanza la señal mqtt para abrir la puerta correspondiente.
Por otro lado molaría una app web para dar de alta los tags, escucha el mqtt para obtener el código del tag que se acaba de pasar por el lector y lo guarda en el directorio activo.
Para primeras pruebas igual podemos postergar el directorio activo y empezar unos jsones hardcodeados
Ok, pues vamos a por la solución técnica global.
Podemos empezar definiendo algunos diagramas de tipo C4 Modeling para refinar la solución y averiguar qué queremos construir.
Estos son diagramas creados con PlantUML.
Evitemos hablar de tecnologías especificas y pongamos primero el foco en los requerimientos para entender la responsabilidad que va a tener esta app.
Tal como me lo has descrito, entiendo que queremos un servidor web que contenga la información de esos jsons que representan las listas de acceso por cada estación RFID en el espacio.
También me parece que queremos tener un log o estado global de los eventos relacionados con los RFIDs, por lo que de alguna manera tiene que llegarle a la web.
Primero definimos el tipo de usuarios y quien interactua con qué componentes. Esta es una visión a muy alto nivel del sistema distribuido y las relaciones entre los componentes involucrados. Todavía no hablamos ni de caches ni de donde están los datos.
Usuarios
Componentes
@startuml
actor RfidUser
component RfidCard
component RfidStation
RfidUser "has" -> RfidCard
RfidCard "sends ID" --> RfidStation
actor AppUser
component RfidApp
AppUser "manages" -> RfidApp
RfidStation "is ID authorized?" --> RfidApp
RfidStation "Yes/No" <-- RfidApp
@enduml
Si ese diagrama es correcto, entonces lo que necesitamos es efectivamente un servidor de autenticación como ActiveDirectory, LDAP o incluso una API REST que permita consultar cual es la ACL (Access Control List) por cada estación de lectura RFID.
El diagrama de entidades del json y por lo tanto el contenido dentro del servidor de autenticación seguiría esta estructura verdad?
@startuml
entity RfidStation
entity RfidStationID
entity RfidStationACL
entity RfidIdentity
entity UserId
entity AccessLevel
RfidStation *-- RfidStationID
RfidStation *-- RfidStationACL
RfidStationACL *-- RfidIdentity
RfidIdentity *-- UserId
RfidIdentity *-- AccessLevel
@enduml
Derivado de esto y antes de entrar más en detalle, me asaltan varias dudas.
Respuestas
Si, la identidad RFID es un número en hexadecimal.
El par UserId-AccessLevel
Pienso que si usamos un servidor MQTT que soporte TLS con usuario y contraseña eso podría garantizar autenticación y confidencialidad suficiente.
Los usuarios están definidos en el Active Directory.
Seguimos el principio de responsabilidad única. Solo queremos una interfáz gráfica para gestionar las listas de acceso.
Podemos empezar a hacer un sistema desacoplado del active directory hasta que encontremos un controlador aceptable para los requerimientos del espacio.
Preparar una web/formulario/app para dar de alta los tags rfid en el sistema.
He estado trabajando en un sistema de autorización en el firmware de glados. La idea es que el servidor almacena unos json por ámbitos ("laser.json","puerta.json","reactor.json"), dentro del json estan los ids de los rfid asociados a su nivel de acceso(0-5) y a su nombre de usuario, los dispositivos se descargan y guardan los json en la spi interna, y los actualizan por http si sale una versión nueva.
Ahora mismo se actualizan los datos editando los json a pelo, habría que hacer alguna aplicación para gestionarlo.