¿Qué es Atlassian Access?
Empecemos por el principio, ¿Qué es Atlassian Access? ¿Por qué es importante conocerlo y entenderlo? ¿Por qué se está hablando tanto de ello? Vamos a intentar resolver todas las dudas relacionadas con este producto de Atlassian, así como ayudarte a entender realmente cómo funciona, compartiendo nuestros mejores consejos.
Atlassian Access es una suscripción para toda la organización que permite conectar cualquier producto de Atlassian Cloud con tu proveedor de identidades. ¿Qué quiere decir realmente esto?
- Permite habilitar funciones de autenticación y supervisión en todos los dominios de la empresa.
- Permite habilitar un inicio de sesión único de SAML.
- Permite automatizar el aprovisionamiento de usuarios.
- Permite aplicar una verificación obligatoria en dos pasos.
- Permite revocar tokens de API no autorizadas.
Teniendo esto en cuenta, no importa cuántos productos
de Atlassian tengas (Jira, Confluence, Bitbucket…) ya que el acceso a todos ellos puede estar controlado desde tu proveedor de identidades.
Ahora bien, es importante saber que Atlassian Access tienen muchas peculiaridades que hay que conocer y entender para poder realizar una correcta configuración.
Configuración general
Es muy importante que cuando decidas empezar con la configuración de Atlassian Access lo hagas con las personas adecuadas: debe haber un encargado del directorio activo, con permisos suficientes para poder realizar cambios y conocimiento para hacerlo. Debe haber un administrador de Jira que se coordine en todo momento con esta persona. Se trata de un trabajo en equipo, es lo único que asegurará el éxito
Los pasos a seguir para la configuración de Atlassian Access, de una forma simplificada serían los siguientes:
- Verificar dominio: Antes de configurar Atlassian Access en el entorno es necesario verificar el dominio. Se pueden verificar tantos dominios como sea necesario.
- Reclamar cuentas: Al reclamar las cuentas existentes en Atlassian del dominio verificado las convertirá en cuentas gestionadas. No es necesario hacer este paso en el mismo momento que se verifica el dominio pero será necesario para poder usar Atlassian Access. A partir de este momento todas las cuentas que tengan acceso a algún producto Atlassian comienzan a ser facturables para Atlassian Access. Eso no significa que sean facturables para el producto correspondiente si no lo era antes.
- Instalar Atlassian Access: Ten en cuenta que desde este momento empezarán a contar los 30 días del free trial. A partir de ese momento empezarán a cobrar por el producto, por todos aquellos usuarios sincronizados con acceso a algún producto de Atlassian.
- Creación directorio: Una vez instalado Atlassian Access tenemos que crear un nuevo Directorio. El directorio inicialmente no tendrá usuarios ni grupos.
- Sincronización con Directorio Activo: Esta configuración se realizará en paralelo entre el directorio activo y Jira. Es necesario que el responsable del directorio activo introduzca las claves API que habremos extraído de Jira. En este momento, los usuarios pasarán a ser usuarios aprovisionados. La sincronización inicial puede tardar varios minutos. Según el volumen de usuarios. Cuando termine, se verán los usuarios en Atlassian Access.
- Configuración SSO: Si se quiere tener un inicio de sesión único, entonces hay que configurarlo en el Directorio activo. Dependiendo de la configuración más adecuada en cada caso. Y habrá que configurarlo también en Atlassian Access.
- Políticas de autenticación: Se pueden tener múltiples políticas de autenticación para definir qué usuarios se loguean con SSO y cuales no así como establecer una política para que algunos usuarios no sean facturables.
Si quieres asegurarte el éxito mientras los llevas a cabo, entonces deberías tener en cuenta las siguientes recomendaciones:
Verificar dominio:
¿Cuánto tiempo se tarda en verificar un dominio?
Cuando vas a verificar el dominio, te dan 3 opciones:
HTTPS -> Tarda entre 24h y 72h en hacer la verificación del dominio.
DNS -> Tarda entre 24h y 72h en hacer la verificación del dominio.
GSUIT, que es el directorio de Google -> la verificación del dominio se hace instantánea y el provisionamiento de los usuarios también.
¿Se avisa a los usuarios de alguna forma?
Se pondrá un banner en la aplicación avisando a todos los usuarios. Por eso es preferible avisar previamente que se está realizando esta configuración, antes de que los usuarios empiecen a preguntar qué está pasando en la instancia.
Reclamar cuentas:
¿Cómo podemos saber los usuarios que tienen licencia (facturables) antes de reclamar las cuentas del AD? Una vez verificado el dominio nos da la opción de Reclamar cuentas y antes de completar ese paso nos da la oportunidad de descargar un archivo de Excel para ver todos los usuarios del dominio y a que aplicación tienen acceso. Podemos hacer esta parte sin llegar a reclamar los usuarios. Sin tener incluso Atlassian Access se puede verificar el dominio y reclamar las cuentas ya que eso no es una feature exclusiva de Atlassian Access.
¿Qué son cuentas gestionadas? son todas aquellas cuentas de Atlassian que forman parte de tu dominio verificado.
¿Qué te aporta tener cuentas gestionadas si luego no instalas Atlassian Access? Te permite verificar el dominio de todos los usuarios y ajustar la configuración de la instancia para que solo los usuarios de ese dominio puedan acceder al portal o a Jira por ejemplo.
¿Qué ocurre con las cuentas gestionadas si se si decide eliminar el reclamo de dominio? Las cuentas gestionadas dejarían de estar gestionadas por la organización y serían usuarios normales pero no se eliminan, modifican ni se pierden accesos a Jira, Confluence…
¿Qué son usuarios facturables para Atlassian access? Atlassian te cobrará por cada cuenta de usuario que haya sido reclamada que tenga acceso a alguno de los productos de Atlassian (Jira, Confluence, Bitbucket, Trello…) y no esté en una política de No Facturable. Solo en productos Cloud, si los usuarios tienen cuentas en productos server o data center (Jira, Confluence, Bitbucket…) no cuentan como facturables. La licencia de Atlassian Access va separada a la licencia de los productos (Jira, Confluence, Bitbucket, Trello…).
Instalar Atlassian Access:
¿Qué es lo que incorpora Atlassian Access que no se pueda hacer de forma nativa? ¿Por qué instalarlo? Verificar el dominio y el reclamo de cuentas NO es una mejora exclusiva de Atlassian Access. Se necesita Atlassian Access en el caso de que se quiera usar SSO y provisionar (sincronizar) usuarios desde los proveedores de identidades (AD). Esta tabla incluye una lista de lo que está disponible para las cuentas gestionadas en cualquier organización:
Sincronización con Directorio Activo:
¿Qué son usuarios provisionados? son los usuarios que sincronizo con el AD y además me permite tener SSO y verificación en dos pasos.
¿Los usuarios sincronizados tendrán acceso a Jira automáticamente? Depende de lo que tenga configurado en Product Access. Si tiene la opción de que se le dé automáticamente acceso a los nuevos usuarios sí. Si se sincroniza un grupo y ese grupo tiene acceso a Jira también tendrán licencia de Jira todos los usuarios de ese grupo.
¿Qué ocurre con los usuarios/grupos provisionados (sincronizados con el AD automáticamente o manualmente) si se decide dejar de usar Atlassian access y se elimina la suscripción? Los usuarios no pierden sus cuentas ni accesos a productos Atlassian ( Jira, Confluence, Bitbucket, Trello..) ni se desactivan y siguen siendo cuentas gestionadas por la organización lo que significa que solo un administrador de la organización puede desactivarlas y modificarlas (solo desde la interfaz en este escenario) pero no se podrían sincronizar ni utilizar SSO si se quita Atlassian Access. Las cuentas gestionadas NO son una mejora exclusiva de Atlassian Access pero el poder usar SSO y la sincronización sí. Los grupos y usuarios aprovisionados permanecen intactos. Sin embargo, sus vínculos entre Atlassian y el proveedor de identidad se romperán y el proveedor de identidad ya no mantendrá las cuentas.
¿Qué pasa si se mueve o quita un usuario de un grupo provisionado desde el AD? En ese caso la cuenta de Atlassian será automáticamente desactivada. Los datos del usuario (Issues, comentarios, asignaciones etc) se mantienen.
¿Se pueden sincronizar varios Azure AD diferentes contra un solo Atlassian Access? En principio y por ahora, una organización de Atlassian solo se puede conectar a un único proveedor de identidad externo para el inicio de sesión único SAML por organización. Esto significa que si se verifican y reclaman varios dominios en una organización, todas las cuentas administradas realizarán el inicio de sesión único SAML a través del único proveedor de identidad configurado. La razón de esto es que Atlassian Access controla el acceso de toda la empresa para todos los usuarios en el dominio reclamado y no específicamente el acceso al sitio.
¿Es posible sincronizar dos AD diferentes contra un solo Atlassian Access? Por ejemplo, Azure AD + Gsuite. Ahora mismo no es posible, aunque está en el Roadmap de Atlassian a futuro, seguramente para Enterprise solo. Lo que recomiendan es quitar una configuración y poner la nueva en su lugar. Desconectar una y conectar la otra. Eso sí, confirman que los usuarios no perderían sus registros en Atlassian ni se les eliminarían los accesos.
Configuración SSO:
¿Los usuarios no facturables pueden usar SSO? Si son usuarios no facturables significa que están en una política de no facturable que no pueden tener SSO habilitado o no tienen acceso a ningún producto (Jira, Confluence, Bitbucket, Trello..) , estos últimos si podrían acceder al site mediante SSO mientras estén en una política con el SSO habilitado.
¿Cómo habilitar la autenticación por dos pasos? Se tiene que hacer en el proveedor de identidad. En el caso de Azure Ad, asumiendo que el 2FA está activado en Azure a nivel general, se tiene que crear un Conditional Access en cada Enterprise Application y es ahí donde se puede configurar esa parte.
Políticas de autenticación:
Se pueden tener múltiples políticas de autenticación para definir que usuarios se loguen con SSO y cuales no así como establecer una política para que los usuarios que estén dentro no sean facturables. Se pueden mover miembros entre las políticas.
Existen varios casos de uso de las políticas que se pueden configurar
Políticas facturables: cualquier política que se cree será por defecto facturable. Puedes crear tantas como quieras pero siempre habrá una «por defecto» que no puedes eliminar.
- A las políticas facturables se les puede activar las mejoras que no dejan a las políticas no facturables (SSO, verificación de dos pasos).
- Si quieres eliminar esta política, tendrás que pasar otra de las políticas facturables a «por defecto».
- Esta política no se puede eliminar a no ser que pase a ser otra política la predeterminada.
- Es la que se establece por defecto para los nuevos usuarios sincronizados con el AD automáticamente o manualmente.
Política no facturable: cualquier política se puede configurar como «no facturable», pero solo puede existir 1.
- En esta política se puede agregar a usuarios para que cuenten como no facturables y no sumen en la suscripción de Atlassian Access.
- No se puede usar SSO
- No se puede requerir la verificación en dos pasos
- No se pueden agregar usuarios que hayan sido sincronizados con el AD automáticamente o manualmente
- No puede ser una política por defecto
Otras preguntas frecuentes
¿Cómo se borra un usuario gestionado? Desde la interfaz en User Managment > Managed accounts y se hace manualmente. Si un org admin borra manualmente un usuario, este tiene un periodo de gracia de 14 días y aparece con el texto «for deletion». Si se elimina un usuario en el AD se desactiva pero no se borra nunca un usuario mediante el aprovisionamiento (sincronizados con el AD automáticamente o manualmente) y no tiene periodo de gracia en ese escenario.
¿Como conseguir el SEN de Atlassian Access? Exactamente igual que el resto de productos de Atlassian, desde esta página. El problema es que no es tan intuitivo de ver a qué instancia corresponde, porque el nombre es un código y no el nombre de la instancia como habitualmente. Por norma general justo debajo de la suscripción de la instancia (Atlassian Cloud) aparecerá su Atlassian Access correspondiente. Será necesario este SEN cada vez que haya que reportar un ticket al soporte de Atlassian sobre Access.
* Ten en cuenta que esta información está sujeta a cambios, ya que los productos en Cloud evolucionan continuamente.
María Ferreño 27 de diciembre de 2022
