Los diferentes tipos de clientes que pueden atacar Historian, pueden consultar la información de muy diversas maneras
En todos los supuestos, la gestión de los permisos para el acceso a la información histórica de un tag la gestiona Historian. Es ahí donde se debe configurar la seguridad.
El siguiente enlace de Historian v2022 muestra cómo implementar la seguridad en el acceso, a nivel de cada tag. Como se explica en el enlace anterior, para ello se ha de referenciar cada tag a grupos de seguridad de Windows, ya sean los estándar o nuevos grupos que el administrador desea añadir a los "Historian Security Groups" estándar.
El siguiente enlace, muestra una technote en la que se ofrece más detalle sobre como se aplican estos "Historian Security Groups" en la seguridad a nivel de tag, pero cuando se realizan consultas desde los clientes web de Historian (que son un escenario muy similar al de la "Trend Card" de Operations Hub).
Como puede leerse, se da la circunstancia de que, aunque la seguridad esté aplicada a nivel de tag, cuando el usuario pida hacer un browse de los puntos en Historian, se le presentará el listado completo. La seguridad entrará en juego únicamente a la hora de mostrar la información de un tag (no así a la hora de enumerarlo).
Esta misma situación se repite por tanto en el caso de consultar Historian desde Operations Hub.
Nótese que LDAP no es lo mismo que UAA. Los usuarios de LDAP son los de Windows AD, mientras que los de UAA no tienen nada que ver, al ser una gestión de seguridad implementada por Proficy Authentication. Si estamos trabajando con UAA como proveedor de seguridad en Historian u Operations Hub, será necesario mapear los grupos de Proficy Authentication contra los grupos de seguridad de Windows, vía LDAP (enlace con la explicación de ejemplo, para el caso de OperationsHub)
Referencias Internas
- Tickets #21574, #21759
- Documentación online de Historian
- Technote #000059043