Qué ha cambiado

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

Versión 10 → 11

Actualización

Dos lecciones nuevas: planificar la instalación con el cliente (comandos del instalador, código de instalación o paquete sin conexión, PoC o producción, qué prepara el cliente), y grupos, políticas de inicio de sesión y proveedores de identidad externos. La comprobación de conocimientos tiene tres preguntas nuevas. Se añadieron diagramas a las lecciones nuevas.

2 lecciones actualizadasduración

Actualización de contenido. Se notificó a los estudiantes inscritos.

La duración cambió de 23 a 24 minutos.

Planificar la instalación con el cliente

Un día de instalación sale bien cuando las preguntas se hicieron una semana antes. Esta lección es la lista de comprobación que un partner repasa con el cliente antes de que nadie toque el servidor. ### Qué es el instalador `monofor` es un único binario de Linux. Prepara el servidor del cliente y despliega Monosign como stacks de Docker Swarm a partir de un único archivo YAML validado. Tiene cuatro comandos: | Comando | Qué hace | | --- | --- | | `monofor check` | Comprueba el servidor y su entorno. No cambia nada. | | `monofor install` | Despliega Monosign. | | `monofor status` | Muestra el estado de salud de la instalación. Solo lee. | | `monofor cert install` | Instala un certificado y su clave en un sistema ya instalado. | Ejecute primero `check` y corrija lo que indique. Cuando diga que el servidor está listo, ejecute `install`. ### Dos formas de empezar - **Con un código de instalación.** Es el inicio habitual desde v2026.10: `monofor install --code <CODE>`. El código lo proporciona su contacto en Monofor y contiene los ajustes de esa instalación. `monofor check --code <CODE>` prueba el servidor sin gastar el código. - **Con un paquete sin conexión.** Para un servidor en una red aislada sin acceso a internet: `monofor install --offline`. La forma de empezar no tiene nada que ver con la base de datos. Eso lo decide el deploy type. ### PoC o producción | `deployType` | Base de datos | Para qué | | --- | --- | --- | | `poc` | Un contenedor PostgreSQL que ejecuta el propio instalador | Pruebas y laboratorios | | `production` | Una base de datos externa PostgreSQL o Microsoft SQL Server. El instalador no ejecuta ningún contenedor de base de datos. | Clientes reales | ### Qué debe preparar el cliente El instalador comprueba estas tres cosas, pero no las hace: - **Registros DNS** para los nombres de host de Monosign. - **Puertos del cortafuegos** entre los usuarios, el servidor y la base de datos. - **La base de datos externa** de una instalación de producción: creada, vacía y accesible desde el servidor. La herramienta, además, solo despliega Monosign. Monopam y Monosync se instalan aparte, aunque el cliente haya comprado los tres. ::diagram msgs-install-plan ### Un ejemplo práctico Un partner instala Monosign en un hospital. El servidor no tiene acceso a internet y el equipo de bases de datos del hospital usa Microsoft SQL Server. El plan que el partner envía una semana antes: 1. Deploy type `production`, con una base de datos SQL Server vacía preparada por el equipo de bases de datos. 2. Registros DNS para los nombres de host, solicitados al equipo de redes. 3. El paquete sin conexión copiado al servidor. 4. `monofor check --offline` hasta que indique que el servidor está listo, y después `monofor install --offline`. > Consejo: Envíe al cliente la lista de nombres DNS, puertos y requisitos de base de datos con bastante antelación al día de la instalación. El instalador no puede arreglar un registro DNS que falta ni una base de datos que no existe; solo puede avisarle.

Grupos, políticas de inicio de sesión y proveedores de identidad externos

En casi todos los primeros proyectos surgen tres preguntas justo después de que funcione la primera aplicación: quién pertenece a qué grupo, cuándo debe un inicio de sesión pedir más pruebas y si las personas pueden iniciar sesión con una cuenta que ya tienen en otro sitio. ### Grupos, y quién recibe una aplicación Los grupos están en Directory → `Groups`. Los miembros entran por una de dos vías: - **A mano**: en la pestaña `Groups` de un usuario, con `Assign New Group`. - **Por regla**: una regla en Workflows → `Automation` con una condición como `Department` igual a `Sales` y la acción `Assign group(s)`. La regla también cubre a quienes se contraten después. Con `Remove access if rule no longer matches` activado, vuelve a quitar el grupo cuando alguien pasa a otro departamento. Un grupo no se llena solo: ningún tipo de grupo lleva su propia condición de pertenencia. Cuando un cliente pide "un grupo con todos los de Sales", la respuesta es un grupo más una regla de Automation. Meter a las personas en un grupo tampoco les abre una aplicación. Una aplicación se abre con una **asignación**: `Assign a User` en la pestaña `Assignments` de la aplicación, o la acción `Assign application(s)` en una regla de Automation. | El cliente dice | Usted configura | | --- | --- | | "Todos los de Sales pertenecen a este grupo" | Una regla de Automation con `Assign group(s)` | | "Todos los de Sales reciben el CRM" | Una regla de Automation con `Assign application(s)` | | "Estas tres personas prueban la aplicación nueva" | `Assign a User` en la aplicación | ### Pedir más pruebas solo a quienes las necesitan Una política de tipo `Authentication` en Security → `Policies` tiene dos partes. El `Scope` dice a quién se aplica: una regla formada por condiciones sobre el usuario, por ejemplo la pertenencia a un grupo. El flujo de la pestaña `Actions` dice qué debe contener el inicio de sesión, por ejemplo un segundo factor después de la contraseña. Pedir más solo cuando se cumple una condición es lo que significa **acceso condicional**, y aquí es donde se configura en Monosign. Cada política tiene además una `Priority` de 1 a 10, un `Start Date` y un `End Date` opcionales y un interruptor `Enabled`, de modo que puede preparar una política hoy y dejar que entre en vigor el lunes siguiente. Ejemplo: un cliente quiere el segundo factor primero para el equipo de finanzas, antes que para toda la empresa. Usted crea una política `Authentication`, limita su scope al grupo `Finance` y añade a su flujo un paso de segundo factor. Los demás inician sesión como antes. Ampliar el despliegue más adelante significa ampliar el scope, no rehacer la política. ::diagram msgs-policy-scope ### Iniciar sesión con una cuenta de otro sitio En Identity → `Providers` se definen los **proveedores de identidad externos** en los que Monosign confía para el inicio de sesión. Si el personal de un cliente ya inicia sesión con Microsoft Entra, Entra pasa a ser uno de esos proveedores: el usuario es enviado a Entra, inicia sesión allí y vuelve a Monosign ya verificado. Los proveedores se conectan por SAML 2.0, OpenID Connect o WS-Federation, y hay plantillas para los habituales, como Microsoft Entra, Google y Okta. Las reglas de enrutamiento deciden a quién se envía adónde, por ejemplo a todos aquellos cuya dirección de correo termina en el dominio del partner. A la vuelta, Monosign asocia a la persona con un usuario existente. Un usuario que aún no existe solo se crea si el aprovisionamiento just-in-time está activado para ese proveedor. No confunda las dos direcciones: | Situación | Quién es el proveedor de identidad | | --- | --- | | El CRM deja entrar a las personas porque Monosign responde por ellas | Monosign | | Monosign deja entrar a las personas porque Entra responde por ellas | Entra, y Monosign es la parte que confía | > Consejo: Antes de activar una política que afecta a todos, deje una cuenta de administrador fuera de su scope, para que un error en la política no pueda dejar fuera a todos los administradores.