Qué ha cambiado

Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.

Versión 1 → 2

Corrección menor

2 lecciones actualizadas

Correcciones menores como erratas o traducciones. No se notifica a los estudiantes.

Los tenants de clientes se gestionan desde el tenant predeterminado de su instalación, en **System → Tenants**. La página solo existe cuando la instalación funciona con `MONOPAM_TENANT_MANAGEMENT=true`, y solo para un `monopam_superadmin`. Cualquier otra persona que escriba su dirección recibe `Page not found.` ### New Tenant - **Title** y **Name**: el nombre admite minúsculas, dígitos y guiones, y queda fijo tras la creación. - **Type** (`Standard` o `Trial`) y la caducidad. - **Host Name**, **Port**, **HTTPS**: la primera dirección del tenant. Introduzca solo el nombre, por ejemplo `a.pam.example.com`; el puerto va en `Port`. La dirección debe ser única entre todos los tenants. - La elección de base de datos (véase el curso de arquitectura). **Test Connection** indica si el servidor responde y si la base de datos se puede crear. - **Copy authentication, Monosign API and storage settings from the default tenant**: activado por defecto. Desactívelo para dar al tenant su propia conexión con Monosign. - **Sign-in Policy**: `Delegated only` cuando se copian los ajustes; en otro caso `Local and delegated`. - **Run the seed right after creation**: activado por defecto. ### Seguir la preparación La preparación inicial (seed) deja listo el tenant en nueve pasos y se ejecuta en segundo plano. La pestaña **Overview** muestra cada paso con su estado y su error. Un tenant creado sin preparación espera en `Waiting for Seed`; **Run Seed** la inicia o la repite. Los pasos conservan los datos existentes, así que repetirla es seguro. El tenant está listo con `9 / 9 steps`, estado `Ready for use`. ::diagram msp-open-customer-steps > Advertencia: Un tenant creado con ajustes copiados es `Delegated only`. Nadie puede iniciar sesión en su dirección hasta que usted conceda acceso de proveedor o cambie la política. Es lo previsto, no un fallo.

Dar a su personal acceso a un cliente

Su personal nunca recibe una cuenta creada a mano en el tenant del cliente. Recibe un **acceso de proveedor**: una concesión desde su tenant principal hacia el tenant de un cliente. ### Grant Access Abra **System → Tenants → el tenant → Provider Access → Grant Access**: - **Who**: un usuario de su tenant principal o un grupo de Monosign de este. Una concesión a un grupo encaja con equipos que rotan y alcanza también a quien se una después. - **Role**: `Tenant Admin` administra el tenant, `Operator` se conecta y trabaja como un usuario estándar, `Auditor` solo mira. - **Policies**: las políticas de acceso del tenant del cliente de las que la persona pasa a ser miembro. Deciden qué espacios, recursos y elementos de Vault ve. - **Access ends** y **Reason**. Un acceso sin políticas solo ve lo que dan las reglas propias del tenant, normalmente solo el espacio predeterminado. Las políticas se crean dentro del tenant, por ejemplo por alguien con acceso `Tenant Admin`, y aquí solo se eligen. ### Entrar La persona abre **Open tenant** en la cabecera del tenant principal y elige el cliente. El tenant se abre en una pestaña nueva sin un segundo inicio de sesión. La insignia de la cabecera muestra `tenant · rol`: es la única señal visual de que la pestaña es el tenant de un cliente. Una sesión delegada dura como máximo 8 horas, o hasta `Access ends`. ### Pedir en lugar de decidir El personal con el permiso `monopam.federation.request` puede pedir acceso. La concesión espera como `Pending approval` hasta que alguien con `monopam.federation.full` la aprueba o la rechaza en **System → Provider Access**. Nadie recibe aviso de una solicitud pendiente, así que quienes aprueban deben consultar esa página. ::diagram msp-provider-access-path > Consejo: **System → Provider Access** lista todas las concesiones de todos los clientes en una página. Úsela para sus revisiones.