Automatización del ciclo de vida en Monosign

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

Nuevo módulo sobre asignaciones, aprobaciones y gobernanza: envío SCIM a las aplicaciones, pertenencias a grupos y escritura en el directorio, importación del organigrama, colas de aprobación, delegación y propietarios, paquetes de acceso y campañas de certificación. Estos temas forman parte del examen MCSA y antes no se trataban.

3 lecciones actualizadas

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

Envío SCIM a las aplicaciones

Una aplicación cuyo fabricante ofrece los endpoints estándar `/Users` y `/Groups` habla SCIM 2.0. Una aplicación así no necesita conector: Applications → aplicación → pestaña `Provisioning` → pestaña `SCIM` envía a las personas asignadas a ella, de modo que la cuenta existe cuando se asigna al usuario y desaparece cuando termina la asignación. ### Dirección: Monosign es el cliente Monosign llama al endpoint SCIM de la aplicación. **No expone un endpoint SCIM propio**, así que otro sistema de identidad, como Microsoft Entra ID, no puede enviar usuarios a Monosign por SCIM. Para traer identidades, use un origen de usuarios: un conector de directorio o una importación. El `SCIM Entitlement Provider` de la lección anterior también es un cliente: lee el endpoint SCIM del otro sistema. ### Ajustes - `Enable Provisioning`: el interruptor general. Mientras está desactivado no se hace ninguna llamada. - `API Url` y `API Key`: la dirección base de SCIM y un token bearer. - `Enable Auto-sync` con `Timing`: un envío programado, cada hora o cada día, en UTC. `Force Sync` ejecuta uno ahora. - También se ejecuta un envío de inmediato cuando se asigna un usuario a la aplicación o se le retira de ella, a mano o por una regla. ### Qué hace un envío con los usuarios Una asignación nueva se busca en el destino y después se crea con `POST /Users` o se actualiza con `PUT /Users/{id}`. Una asignación que pasa a **inactiva se elimina** con `DELETE /Users/{id}`. Monosign nunca envía `active = false`, y cuando la asignación se reactiva el destino crea una cuenta nueva con un **id SCIM nuevo**. Si la aplicación conserva el historial de un usuario solo mientras existe la cuenta, acuerde con el propietario de la aplicación cómo se exporta ese historial antes de que cambie la asignación de una persona que se va. ::diagram lc-scim-push-lifecycle Un usuario cuyo perfil predeterminado no tiene nombre de pila se omite sin ningún mensaje, así que revise el perfil cuando falte una sola persona en el destino. ### Qué hace un envío con los grupos Los `Groups` que usted asigna se envían como grupos SCIM. Después, el envío **elimina todos los grupos del destino que no sean uno de los grupos asignados**, incluidos los que crearon los propios administradores de la aplicación. Un grupo de destino cuyo `externalId` no es un GUID detiene todo el paso de grupos. Antes de activar el envío de grupos en una aplicación que ya tiene grupos, lístelos y decida cuáles serán de Monosign. ### Cuando algo falla Los envíos SCIM no aparecen en Reports → `Provisions`. El único rastro es el registro del servicio: busque una línea como `SCIM API returned error` con el código de estado y el cuerpo de la respuesta. La siguiente ejecución programada lo intenta de nuevo. ### Servicios de aprovisionamiento y datos de usuario Algunas integraciones usan un servicio de aprovisionamiento con reglas en lugar de SCIM. El `User Provisioning Service` evalúa a cada usuario con esas reglas. Trata a un usuario **sin dirección de correo electrónico, a un usuario inactivo o a un usuario cuyo estado no es `Enabled` como si no cumpliera ninguna regla**, y eso lo desaprovisiona. Tras una importación de directorio, rellene el atributo de correo antes de que se evalúe a esos usuarios. > Consejo: Ejecute el primer envío contra un entorno de prueba de la aplicación. Una eliminación en el destino no se puede deshacer desde Monosign. ::shot lc-provisions

Aprobaciones, delegación y propietarios

Los triggers preventivos y las solicitudes de acceso ponen a personas en el camino de una asignación. Tres cosas deciden si la persona adecuada ve una solicitud a tiempo. ### Dónde queda una asignación en espera Un trigger con `Require approval` necesita un `Approval workflow` si hay que avisar a alguien. Con el campo vacío, la solicitud va a una **cola manual**: aparece en la pestaña `Approvals` del trigger y no se avisa a nadie. El acceso solo se concede después de `Approve`. Defina un flujo de trabajo o haga que revisar esa pestaña sea parte de la rutina de alguien. ### Quién puede actuar en un paso Un paso de flujo de trabajo puede asignarse a personas o, con `Group Approval`, a grupos. Los pasos de grupo se resuelven con la **pertenencia actual** cada vez que se lee el paso. Quien entra en el grupo puede actuar de inmediato. Quien sale de él pierde la fila de la pestaña `Active` de su bandeja `Approvals` de inmediato, mientras que las filas de `History` se conservan para quien actuó. Cualquier miembro actual completa el paso, y un grupo vacío lo deja en espera. ### Delegación Security → `Delegations` traspasa las aprobaciones de un usuario a otro durante un periodo: `Assign`, después `User (from)`, `Delegated User (to)` y las fechas de inicio y fin. Las asignaciones del delegado se añaden **cuando se crea un paso**. Una delegación configurada después no se aplica a los pasos que ya están en espera, así que entregue esos pasos a mano a otro aprobador. Configure las delegaciones antes de una ausencia prevista, no en su primer día. ::diagram lc-approval-routing ::shot lc-delegations ### Propietarios Muchas decisiones van "al propietario", así que los propietarios deben estar registrados. Governance → `Owners` guarda quién es propietario de una aplicación, un usuario, un grupo, un rol, un permiso, un recurso o un agente de IA, como `Direct Manager` o como `Governance Owner`. Los grupos, roles y permisos tienen además una pestaña `Owners` en su propia página. **Las aplicaciones no**: asigne un propietario de aplicación en Governance → `Owners` o mediante la API de propietarios de objetos (`v1.5/object-owners`). Las campañas de certificación eligen a los revisores a partir de estas filas, y los triggers les envían avisos. Una campaña solo lee el `Owner Type` para el que está configurada, de modo que no se elige a un propietario registrado con el otro tipo. > Consejo: Cuando una aprobación parece haber desaparecido, revise tres cosas en este orden: la pertenencia del grupo asignado, si otro miembro ya decidió y si el flujo se canceló.

Paquetes de acceso y campañas de certificación

La automatización del ciclo de vida concede lo que las personas necesitan por defecto. Los paquetes de acceso cubren lo que piden, y las campañas de certificación confirman que lo que tienen sigue siendo correcto. ### Paquetes de acceso Governance → `Access Packages` define conjuntos que las personas pueden solicitar: un título, una `Policy`, un `Lifetime`, un `Workflow` opcional para la aprobación y recursos de un catálogo. `Assigned Object(s)` muestra quién tiene un paquete. - **Quitar una asignación** (v2026.10) revoca las concesiones que creó su solicitud aprobada. El acceso que el usuario tiene por otra vía, por ejemplo una asignación directa de rol, se mantiene. Una revocación rechazada queda registrada. - **La política está bloqueada mientras se usa.** Una definición de política a la que hace referencia un paquete no se puede desactivar ni quitar. Primero desvincúlela de todos los paquetes. Quitarla es un borrado lógico, así que el historial se conserva. ::shot lc-access-packages ### Campañas de certificación Governance → `Certifications` guarda definiciones: qué se revisa, quién revisa, con qué frecuencia y durante cuántos días. Un servicio convierte una definición vencida en una campaña con elementos y revisores. - **Los revisores se determinan cuando empieza la campaña**, a partir de `Reviewer Type`: usuarios concretos, `User Manager`, una regla o propietarios. Un cambio posterior de responsable o de propietario no mueve los elementos. Un gestor de certificación usa `Reassign` o `Add Reviewer`. - **Nada se escala.** El único seguimiento son los correos de recordatorio y la reasignación manual. - **La fecha de fin no decide.** Si la definición no marca las decisiones de antemano con `Approve All` o `Reject All`, los elementos que nadie revisó quedan sin decidir y la campaña simplemente se marca como `Completed`. Insista a los revisores durante la campaña e informe de los elementos sin decidir como un hallazgo abierto. ::diagram lc-campaign-course ### Cómo encajan las piezas | Necesidad | Herramienta | | --- | --- | | Acceso que todos en un grupo deben tener | Regla de automatización | | Acceso que una persona pide, con aprobación y fecha de fin | Paquete de acceso | | Prueba de que el acceso sigue justificado | Campaña de certificación | | Alguien responsable que decida | Governance → `Owners` | > Consejo: Antes de que empiece una campaña, compruebe que cada elemento tendrá un revisor: responsables rellenados en los perfiles y propietarios registrados con el tipo que lee la campaña.