Hola!
Estamos pasando una auditoría del ENS (Esquema Nacional de Seguridad, la normativa española de seguridad exigida a proveedores del sector público) y nos ha salido una carencia recurrente en Jira Service Management , que aplica tanto a datacenter como a Cloud: los controles de identidad para nuestros clientes externos (cuentas portal-only, que viven en el directorio local de Jira y no en un IdP federado). Concretamente, el ENS exige que estos usuarios tengan:
- Expiración de contraseña — hoy las contraseñas de las cuentas portal-only no caducan nunca.
- Bloqueo de cuenta tras N intentos fallidos, con umbral configurable por el administrador.
- Histórico de contraseñas — que no se pueda reutilizar ninguna de las últimas N
- Checkbox de aceptación de Términos y Condiciones al recibir la contraseña o en el primer login.
- Visibilidad para el propio usuario de la fecha/hora de su último login al autenticarse.
Antes de preguntar, hemos investigado lo que da Atlassian de fábrica, y el resumen es que ninguno de los cinco puntos está cubierto de forma nativa para cuentas portal-only:
- Las políticas de contraseña de Atlassian Guard solo aplican a managed accounts de un dominio verificado por vuestra organización. La documentación oficial es explícita: "You can't create a password policy for Jira Service Management customers with portal-only accounts".
- No existe en Cloud un bloqueo por intentos configurable por el admin (ni para portal-only ni para managed accounts) — solo un CAPTCHA/throttle automático no configurable que salta por heurística antibot, sin umbral ni duración ajustables.
- No existe histórico/prevención de reutilización de contraseñas en Cloud, en general.
- No hay checkbox nativo de T&C en el portal de clientes. El único add-on de Marketplace que lo implementa (Terms and Conditions for Jira) es solo para Data Center/Server, no para Cloud.
- No hay "último login" visible para el cliente. Ni siquiera el dato interno (Last Active) es fiable para portal-only, porque no se actualiza si el cliente interactúa solo por email.
- Es una carencia conocida y ya reportada: JSDCLOUD-8323 (abierta desde 2019, ~180 votos). Un PM de Atlassian confirmó en el propio ticket que lo están evaluando, sin fecha comprometida. El único workaround oficial que dan es migrar la autenticación de clientes a SAML SSO externo.
La pregunta real: si gestionáis JSM con clientes externos bajo una normativa que exige estos controles (ENS, ISO 27001, ENS+, lo que sea), ¿qué planteamiento habéis seguido en producción?
- ¿Migrasteis los portal-only customers a SSO con un IdP externo (Entra ID, Okta, Keycloak...)? Si vuestros clientes no tienen IdP corporativo propio, ¿montasteis un CIAM (Entra External ID, Auth0, Okta CIC) solo para alojar sus identidades?
- ¿Cubristeis el checkbox de T&C y/o el aviso de último login con una app propia? ¿Alguna limitación con la que os hayáis topado (por ejemplo, el bloqueo de consentimiento que hubo en junio de 2026 para apps Forge en el portal de clientes)?
Gracias por leer hasta aquí y gracias por vuestro feed :)
Saludos!!!
