Seguridad y permisos

Un asistente conectado por MCP actúa como un usuario de Beas. Lo que puede hacer lo deciden tres barreras independientes, y las tres tienen que permitir una operación antes de que se lleve a cabo. Entenderlas en orden es lo que hace que el endpoint se pueda exponer con seguridad.

Las tres barreras

Barrera	Definida por	Efecto
La configuración	EnableWriteTools y EnableODataQueryTool en el servidor	Una herramienta desactivada no se ofrece a nadie, sean cuales sean sus permisos. Es el interruptor de toda la implantación.
El esquema de autenticación	La forma en que se conectó el asistente	Un llamante con clave de API es de solo lectura: las herramientas de escritura y la herramienta OData genérica lo rechazan antes de consultar los permisos. Una sesión de usuario supera esta barrera.
El permiso del usuario	Las autorizaciones de Beas del usuario	Cada herramienta de escritura exige el mismo permiso Control total que exige el Web Client para la acción equivalente.

El orden importa cuando se diagnostica un rechazo. La configuración prevalece sobre la autenticación, y la autenticación prevalece sobre los permisos, de modo que "el usuario es administrador" no explica nada por sí solo.

Por qué las herramientas de escritura no pueden sortear el Web Client

Cada herramienta de escritura resuelve el permiso del usuario mediante la misma política que usan los controladores REST, por lo que un usuario que no puede crear una orden de trabajo en el Web Client tampoco puede crearla a través de un asistente. La barrera no es una reimplementación que pueda desviarse con el tiempo: es la misma comprobación, con el mismo nombre de recurso y el mismo nivel requerido.

Herramienta	Permiso necesario
work_orders_create, work_orders_update	Control total en Órdenes de trabajo
production_times_create	Control total en Tiempos de OT activos
resource_downtimes_create	Control total en Recursos

La clave de API

El acceso por clave de API usa el valor BeasWebServerKey de la configuración de Beas, con cabeceras que indican la base de datos de la empresa y el código de usuario con el que se actúa.

precaución

Se trata de una única clave de servidor compartida y de larga duración, no de una credencial que usted emite para cada asistente. Cualquiera que la tenga puede leer los datos de cualquier base de datos de empresa a la que llegue el servidor, con cualquier código de usuario que indique, y revocar el acceso a un consumidor significa cambiar la clave para todos. Manténgala en el lado del servidor y utilice una sesión de usuario para cualquier uso interactivo.

Su única protección estructural es que no puede escribir: las herramientas de escritura y beas_odata_query requieren ambas una sesión, y ambas lo indican claramente cuando rechazan la llamada.

Qué revelan los errores

Una herramienta que falla devuelve un mensaje redactado para que el asistente pueda actuar. Los problemas de negocio se devuelven completos (un registro que no existe, una regla de validación, un motivo de cambio obligatorio, una operación fallida), porque el asistente, o el usuario que lee su respuesta, puede hacer algo al respecto. Cualquier cosa inesperada se devuelve como un aviso general de que se ha producido un error interno, y el detalle va al registro del servidor. Ningún stack trace ni detalle interno llega al cliente.

Antes de habilitarlo

1. Decida si las herramientas de escritura deben estar disponibles en esta implantación. Están activadas de forma predeterminada. Desactivarlas hace que el endpoint sea de solo lectura para todos, que es el punto de partida adecuado para un primer despliegue.
2. Decida si la herramienta genérica de consulta OData debe estar disponible. También está activada de forma predeterminada y amplía el acceso de lectura a todas las entidades que expone la API, mucho más allá de la lista seleccionada de herramientas.
3. Decida cómo se autentican los asistentes y mantenga la clave de API en el lado del servidor.
4. Revise quién tiene Control total en Órdenes de trabajo, Tiempos de OT activos y Recursos: los permisos de esos usuarios son ahora también lo que puede hacer un asistente conectado con su identidad.
5. Active VerifySSL en una implantación reforzada. Está desactivado de forma predeterminada para que un certificado de desarrollo autofirmado no bloquee la propia llamada de loopback del servidor.

Ejemplos

Un despliegue de solo lectura que sigue respondiendo a la mayoría de las preguntas. Deje Enabled activado, desactive EnableWriteTools y deje EnableODataQueryTool activado. El asistente conserva las 68 herramientas de lectura y la consulta genérica, y ningún error de configuración ni usuario con demasiados permisos puede modificar datos, porque las herramientas de escritura no se publican en absoluto.

Un rechazo que menciona un permiso que el usuario sí tiene. El mensaje cita el recurso y el nivel que necesita la operación. Si el usuario realmente tiene ese nivel, está conectado con la clave de API y no con una sesión: la barrera de solo lectura produce un rechazo que menciona permisos porque usa la misma vía de mensajes. Vuelva a conectarse con una sesión de usuario.

Funcionalidad relacionada

• Conexión: los ajustes de configuración y los dos esquemas de autenticación.
• Autorizaciones: cómo se conceden los permisos de Beas.