Qué ha cambiado

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

Versión 12 → 13

Actualización

Nuevo módulo sobre la operación de SSO en producción: audiencias, certificados de firma por aplicación, duración de los tokens y claims de perfil, duración de la sesión, cierre de sesión y revocación, inicio de sesión con Kerberos, acuerdos y el catálogo de aplicaciones. La lección de federación trata ahora los conflictos de enrutamiento.

4 lecciones actualizadas

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

Aplicaciones SAML 2.0

En SAML saliente, **Monosign es el proveedor de identidad (IdP)** y la aplicación es el **proveedor de servicios (SP)**. La configuración está en una clave de aplicación de tipo `SAML`: Applications → aplicación → `Keys` → tarjeta de la clave `Configure` → pestaña `SAML Settings`. La tarjeta de la clave también ofrece la URL de inicio de sesión, los metadatos y el certificado que debe entregar al SP. ::diagram saml-sp-initiated Ajustes clave: - **`Metadata Import`**: introduzca XML o una URL, revise con `Preview changes` y aplique con `Apply to Configuration`. Rellena el entity ID, los endpoints ACS, el formato de NameID, la URL de cierre de sesión y los certificados del SP. Requiere una clave guardada, y Monosign no vuelve a comprobar los metadatos de la aplicación en segundo plano. - **URL de ACS**: `Additional Assertion Consumer Urls` es la lista de endpoints permitidos. `ACS Validation Mode` es `Off (Legacy)`, `Warn Only` o `Enforce`. Una clave creada en la consola empieza en `Enforce`, pero una clave guardada antes de v2026.07 se comporta como `Warn Only` y enviará a cualquier URL solicitada. Solo `Enforce` rechaza. La coincidencia es exacta, así que una barra final es otra URL. - **`Name Id` y `NameId Format`**: `Name Id` indica qué valor se envía (por defecto `UserName`, o una propiedad de perfil o un token). `NameId Format` es la etiqueta de formato que espera el SP. Si el valor está vacío para un usuario, el inicio de sesión se detiene con una auditoría `DATA_MISSING`. - **Enlaces**: inicio de sesión iniciado por el SP mediante HTTP-POST y HTTP-Redirect, e inicio de sesión iniciado por el IdP, que usa el ACS predeterminado. Evite HTTP-Artifact detrás de un balanceador: la resolución de artefactos se guarda por nodo y falla con `Unknown artifact` en otro. - **`Signing Algorithm`**: `System Default (SHA 256)` o SHA-1. Use SHA-1 solo si el SP no admite nada mejor. - **`Signing Certificates`**: `Organization-Based` (compartido, se define en System → `Configurations`) o `Application-Based`. ::shot sso-saml-settings ### Límites que debe conocer el cliente - Monosign **no cifra** las aserciones ni las respuestas. `Don't Encrypt Entire Message` y `Don't Encrypt Assertion` son etiquetas engañosas: eliminan una **firma**, así que déjelas desactivadas salvo que el SP lo exija. - Cerrar sesión en una aplicación no envía un `LogoutRequest` SAML a las demás aplicaciones del usuario. > Consejo: Elija un valor de `Name Id` que no cambie durante toda la vida del usuario. Las direcciones de correo cambian, y la etiqueta de formato por sí sola no le protege.

Asignación de claims y proveedores de identidad entrantes

### Asignación de claims Cada aplicación debe recibir solo los atributos que necesita. Las pestañas están en la clave de la aplicación: - SAML: `Attribute Mapping`, `Group Mapping`, `Role Mapping`, `Permission Mapping`. - OIDC: `Claim Mapping`, `Profile Claim` y pestañas de asignación de grupos, roles, permisos y recursos. Las pestañas de grupos, roles y permisos están desactivadas por defecto. Cada una tiene un nombre de atributo (por defecto `Groups`), un filtro y un formato (por defecto `{{Name}}`). Use el filtro para que la aplicación reciba sus propios grupos, no toda la lista de pertenencia. En OIDC, una fila de `Claim Mapping` con el nombre de un claim que Monosign emite por sí mismo, como `email` o `sub`, **sustituye** a ese claim. ::diagram sso-claim-mapping ::shot sso-providers-list ### Federación entrante En Identity → `Providers`, Monosign también puede *confiar* en IdP externos. `Add New` ofrece plantillas para proveedores como Microsoft Entra ID, Okta, Google, Apple y GitHub, o un proveedor en blanco `SAML 2.0`, `OpenID Connect` o `WS-Federation`. - **Enrutamiento**: `Matches any user`, `Matches regex` o `Matches email domain` envía al usuario al proveedor. No use `Matches user attribute`: nunca enruta. Tampoco se enruta una visita directa a la página de inicio de sesión sin una solicitud de inicio de sesión detrás. Cuando dos proveedores activos coinciden con el mismo dominio, la lista muestra `Routing Conflicts Detected` y solo se usa la primera coincidencia: asigne un único proveedor a cada dominio y confirme el resultado en `Routing Overview` con `Test Routing`. - **`Access rules`**: se evalúan antes de buscar ninguna cuenta. Gana la primera coincidencia y el valor por defecto es `Allow`. - **`Account link policy`**: el valor por defecto es `Auto (match by email)`. `Manual (link only by source key)` rechaza las coincidencias por correo y así evita la usurpación mediante un claim de correo, pero las cuentas deben estar vinculadas de antemano. - **Aprovisionamiento just-in-time**: desactivado por defecto. `Enable Just-in-Time provisioning` crea al usuario en el primer inicio de sesión con los campos asignados y `Default groups`. - **Actualización de perfil**: los grupos del IdP se añaden en cada inicio de sesión pero nunca se quitan, así que no confíe en ello para revocar accesos. - **Rotación de certificados**: `Secondary certificate (rotation)` guarda un segundo certificado de confianza. Con `Keep in sync from this metadata URL`, Monosign actualiza los metadatos cada hora y coloca allí un segundo certificado publicado. Los metadatos de WS-Federation no se actualizan automáticamente. ::diagram sso-inbound-federation > Limitación conocida, verificada por última vez en v2026.09: el formulario de proveedores entrantes muestra `Require PKCE`, `Max clock skew (seconds)`, `Response verification`, `Sign authentication requests` y `Use persistent NameID format`, pero estos ajustes no tienen efecto. No los prometa a un cliente.

Resolución de problemas de federación

La mayoría de los fallos de federación responden a unos pocos patrones. Revíselos en orden. ::diagram sso-federation-checks ### SAML y OIDC salientes 1. **¿Llegó el usuario a Monosign?** Reports → `Audit` (registros de auditoría) y la pestaña `Audits` de la aplicación muestran los eventos de inicio de sesión. Los endpoints OIDC no escriben registros de auditoría propios, así que en un cliente OIDC lea también los logs de Account. 2. **Discrepancia de ACS**: el log indica `SAML ACS validation failed`. Compare `RequestedUrl` con el `Location` registrado carácter por carácter, incluidas las barras finales. 3. **La aserción va a una URL inesperada**: la clave está en `Warn Only` u `Off (Legacy)`. Busque `SAML ACS validation warning` y pase la clave a `Enforce`. 4. **Errores de redirección o de ámbito en OIDC**: compruebe `Allowed Redirect URIs` y `Scope`, y también que el prefijo de la URL corresponda al tipo de clave. 5. **El SP no reconoce al usuario**: compruebe `Name Id` y la asignación de atributos. `Your Email seems empty…` con una auditoría `DATA_MISSING` significa que la propiedad está vacía para ese usuario. 6. **El SP rechaza la firma**: compare el certificado de `/saml/{idpId}/Metadata` con la copia del SP y lea los dos interruptores `Don't Encrypt`. Si solo falla una aplicación tras una rotación, su tipo de `Signing Certificates` probablemente sea `Application-Based`. 7. **Discrepancia de emisor**: `does not match the configured Entity Id` es solo una advertencia. Si la ve, siga buscando el fallo real en la misma solicitud. `Enable Debug Mode` en una clave SAML registra completas todas las solicitudes y respuestas. Úselo poco tiempo y vuelva a desactivarlo. ### Proveedores entrantes - **Los usuarios no se envían al IdP**: ejecute `Routing Overview` → `Test Routing` con la dirección. Busque un proveedor inactivo o `Routing Conflicts Detected`. - **`No matching user found for the federated identity`**: la política es `Manual` sin vínculo, o el claim de correo no está asignado. `Interactive test` muestra los claims y el `Mapped profile preview` sin iniciar sesión a nadie. Puede ejecutarlo cualquiera con permiso de edición del proveedor, y muestra los claims sin procesar. - **SAML falla tras renovar el IdP su certificado**: compruebe la columna `Certificate` y la fila `Signing certificate` de `Test connection`. - **Nadie recibió aviso del vencimiento**: Monosign escribe `IDENTITY_PROVIDER_CERTIFICATE_EXPIRING`, pero el aviso solo llega a las personas si vincula un webhook o un trigger a ese evento. ::shot sso-provider-attribute-mapping

Audiencias, certificados de firma y duración de los tokens

Una vez que una aplicación inicia sesión, la mayoría de las preguntas posteriores giran en torno a unos pocos ajustes de la clave. Todos están en la clave de la aplicación: Applications → aplicación → `Keys` → `Configure`. ::shot sso-application-keys ### SAML: a quién va dirigida la aserción Cada aserción nombra a su destinatario previsto. Monosign toma ese valor del campo `Audience` de la clave. Si el campo está vacío usa `Entity Id`, y si este también lo está, el emisor de la solicitud entrante. Cuando un proveedor de servicios responde con un error de audiencia, la aserción se emitió para otro destinatario: compare `Audience` y `Entity Id` en la clave con el entity ID que espera el SP. El NameID y el certificado de firma no intervienen en ese error. ::diagram sso-saml-audience-source ### SAML: un certificado para todos o uno por aplicación Una clave en `Organization-Based` firma con el certificado compartido de la organización. Cuando ese certificado se rota, todas las aplicaciones que lo usan cambian en el mismo momento, por lo que todos sus proveedores de servicios deben actualizarse a la vez. Para un proveedor de servicios que debe rotar según su propio calendario, abra la pestaña `Signing Certificates` y use `Generate New Certificate` (o `Create to Application-Based Signing Certificate`), guarde la clave y entregue al SP los nuevos metadatos. A partir de entonces, una rotación del certificado de la organización ya no afecta a esa aplicación, y su propio certificado puede renovarse por separado. Los certificados que llegan con la importación de metadatos de un SP se guardan solo como referencia. Monosign no firma con ellos. ### OIDC: la audiencia pertenece al access token `Audience` y `Resource` en una clave OIDC se escriben únicamente en el **access token**, y de nuevo en cada renovación. El ID token conserva el `client_id` como `aud`, tal como espera OpenID Connect. Por tanto, una API que necesite su propio valor de audiencia debe validar access tokens, no ID tokens. ### OIDC: duraciones y lo que un usuario deshabilitado aún puede hacer - Los tres campos de duración están en **minutos**. Hasta v2026.07-hf02, un cliente que usaba client credentials los leía como segundos. Una clave ajustada en una de esas versiones, por ejemplo `3600` para una hora, emite tokens que viven 60 horas tras actualizar a v2026.09 o posterior. Revise estas claves durante la actualización y vuelva a introducir el valor en minutos, aquí `60`. - La duración se aplica cuando se emite un token. Los tokens ya emitidos conservan su caducidad. - Deshabilitar a un usuario no retira un access token. El token sigue siendo válido hasta su `exp`, y la siguiente renovación se rechaza con *The refresh token is no longer valid.* Mantenga `Access Token Lifetime` corto en las API donde ese intervalo importa. ### OIDC: envíe solo los datos de perfil que el cliente necesita Cuando `Profile Access Type` permite claims de perfil, el claim de perfil lleva **todas** las propiedades del perfil salvo que usted lo limite. En la pestaña `Profile Claim`, seleccione en `Included Properties` solo las propiedades que lee el cliente. Así los datos personales quedan fuera de los tokens, y los tokens siguen siendo lo bastante pequeños para proxies con límites de cabecera. `Included Properties` limita solo el token. El endpoint userinfo sigue devolviendo el modelo de usuario completo, así que revise qué clientes lo llaman. > Consejo: Después de cualquiera de estos cambios, decodifique un token o una aserción emitidos **después** del cambio. Uno anterior no le dice nada.