Gestión de identidad y acceso

La gestión de identidad y acceso determina quién puede usar Cherri Code en tu organización y qué puede hacer. Configurarás la autenticación, automatizarás el aprovisionamiento de usuarios y aplicarás políticas mediante la gestión de dispositivos.

Configura los controles de identidad en este orden:

1. Configurar SSO: Primero configura la autenticación centralizada
2. Habilitar SCIM: Automatiza la gestión del ciclo de vida de los usuarios
3. Aplicar políticas MDM: Aplica los ID de equipo y extensiones permitidos
4. Asignar roles: Otorga acceso de administrador a las personas adecuadas

Single Sign-On (SSO) y SAML

SSO permite que tus usuarios se autentiquen en Cherri Code con tu proveedor de identidad existente. En lugar de crear contraseñas separadas para Cherri Code, los usuarios inician sesión con sus credenciales corporativas.

Cherri Code admite SAML 2.0 con proveedores como Okta, Azure AD, Google Workspace y OneLogin. Cuando habilitas SSO, puedes exigirlo para todos los miembros del equipo y bloquear por completo la autenticación basada en contraseñas.

Si tu empresa ejecuta varios equipos vinculados, usa SSO compartido a nivel de organización mediante Organizations. El SSO a nivel de equipo sigue siendo compatible con requisitos de identidad específicos de cada equipo.

Consulta la configuración de SSO y SAML para obtener instrucciones de configuración detalladas.

Aprovisionamiento de SCIM

El aprovisionamiento mediante SCIM 2.0 gestiona automáticamente los miembros de tu equipo y los grupos de directorio a través de tu proveedor de identidad. Disponible en los planes Enterprise con SSO activado.

Sin SCIM, añades usuarios manualmente a tu equipo de Cherri Code y los eliminas cuando se van. Con SCIM:

• Los nuevos empleados obtienen acceso a Cherri Code automáticamente al añadirse al grupo adecuado
• Los empleados que se van pierden el acceso al eliminarse de tu proveedor de identidad
• Los cambios en la pertenencia a grupos se propagan automáticamente

Consulta Aprovisionamiento de SCIM para ver las instrucciones de configuración. Si gestionas varios equipos vinculados, también puedes sincronizar grupos de directorio a nivel de organización y reutilizarlos entre equipos. Consulta Identidad a nivel de organización.

Identidad a nivel de la organización

Si tienes varios equipos vinculados, gestiona la identidad una sola vez a nivel de la organización mediante Organizations. Así tendrás una única configuración compartida en lugar de una configuración de identidad independiente para cada equipo.

• SSO de la organización: una única configuración de inicio de sesión para todos los equipos. Consulta Organizations.
• SCIM de la organización: sincroniza grupos de directorio desde tu proveedor de identidad con Cherri Code y luego úsalos en todos los equipos mediante Grupos de la organización.
• Membresía de equipo desde grupos: sincroniza un grupo de directorio con un Grupo de la organización y luego asigna ese grupo a un equipo para que la membresía y los roles del equipo queden alineados con la cohorte. Consulta Usar grupos para impulsar equipos.
• Consolida los proveedores de identidad de los equipos: los Admins de la organización pueden fusionar varios proveedores de identidad independientes a nivel de equipo en un único proveedor de identidad compartido a nivel de la organización desde el Panel de control. Consulta Consolidar los proveedores de identidad de los equipos.

Control de acceso basado en roles (RBAC)

Los equipos de Cherri Code tienen tres roles: miembros, administradores y administradores sin plan de pago.

Consulta Miembros, roles y tipos de asiento para obtener más información.

Políticas de MDM

Los sistemas de Mobile Device Management (MDM) permiten aplicar políticas en los dispositivos de los usuarios. Cherri Code admite políticas basadas en MDM en macOS e Intune / Directiva de grupo en Windows para garantizar que los usuarios cumplan los requisitos de la organización.

Consulta Patrones de implementación para obtener instrucciones de configuración de MDM específicas para cada plataforma.

IDs de equipo permitidos

La política MDM más importante evita que los usuarios inicien sesión en cuentas personales de Cherri Code en dispositivos corporativos.

Cuando configuras una política de IDs de equipo permitidos, Cherri Code solo permite la autenticación para esos IDs de equipo específicos. Si un usuario intenta iniciar sesión con un ID de equipo diferente (como una cuenta personal), Cherri Code cierra su sesión de inmediato.

Por ejemplo, si tus empleados tienen portátiles corporativos, puedes configurar el ID de equipo permitido como el ID de tu equipo empresarial. Esto evita que usen por accidente cuentas personales que podrían no tener el Modo de privacidad activado.

La configuración de Cherri Code cursorAuth.allowedTeamId controla qué IDs de equipo tienen permiso para iniciar sesión en Cherri Code. Esta configuración acepta una lista separada por comas de IDs de equipo autorizados para acceder.

Por ejemplo, configurar cursorAuth.allowedTeamId como "1,3,7" permite que los usuarios de esos IDs de equipo específicos inicien sesión.

Cuando un usuario intenta iniciar sesión con un ID de equipo que no está en la lista permitida:

• Se cierra su sesión de forma inmediata y forzada
• Se muestra un mensaje de error
• La aplicación bloquea nuevos intentos de autenticación hasta que se use un ID de equipo válido

Para administrar de forma centralizada los IDs de equipo permitidos para tu organización, configura la política AllowedTeamId usando tu solución de administración de dispositivos. Esta política reemplaza la configuración cursorAuth.allowedTeamId en los dispositivos de los usuarios. El valor de esta política es una cadena que contiene la lista separada por comas de IDs de equipo autorizados.

Consulta Deployment Patterns para obtener instrucciones de configuración de MDM específicas por plataforma.

Extensiones permitidas

Controla qué extensiones pueden instalar los usuarios en Cherri Code. Las extensiones pueden acceder a tu espacio de trabajo, así que debes asegurarte de que solo se ejecuten extensiones de confianza.

Cómo funciona:

La configuración de Cherri Code extensions.allowed controla qué extensiones se pueden instalar. Esta configuración acepta un objeto JSON donde las claves son nombres de editor o ID completos de extensión, y los valores son booleanos que indican si están permitidos.

Importante: extensions.allowed usa un modelo de lista de permitidos. En cuanto añades cualquier entrada, solo se permiten las entradas autorizadas explícitamente, y todo lo demás se bloquea. No hay ningún fallback implícito de "permitir todo". Por ejemplo, configurar extensions.allowed en {"anysphere": false} no solo bloquea las extensiones de Anysphere; también bloquea las de cualquier otro editor, porque no hay nada más en la lista de permitidos.

Para bloquear extensiones específicas y mantener permitido todo lo demás, usa el comodín "*": true junto con las entradas que quieras denegar. El comodín es la coincidencia menos específica, así que las entradas de editor y de ID de extensión prevalecen sobre él:

{  "*": true,  "untrusted-publisher": false}

Para restringir las instalaciones a un conjunto aprobado de editores y extensiones, omite el comodín y enumera solo los elementos de confianza. Puedes incluir los ID completos de las extensiones, fijarlos a versiones específicas o a un canal de lanzamiento:

{  "anysphere": true,  "github": true,  "esbenp.prettier-vscode": true,  "ms-azuretools.vscode-containers": false,  "dbaeumer.vscode-eslint": ["3.0.0"],  "github.vscode-pull-request-github": "stable"}

Configuración del portal de administración:

Los administradores de equipo pueden configurar las extensiones permitidas a través del panel del equipo, en la sección Security & Identity. La configuración se aplica automáticamente a los clientes de Cherri Code de todos los miembros del equipo. Deja el campo vacío para dejar de enviar un valor a los clientes.

Restablecer los clientes a "permitir todo": Borrar el campo del portal de administración deja de enviar un valor nuevo, pero no elimina la política que los clientes ya aplicaron localmente. Los usuarios siguen aplicando el último valor que recibieron. Para restablecer a todos y volver a permitir todas las extensiones, implementa primero {"*": true}, espera a que los clientes lo reciban y luego borra el campo si ya no quieres gestionar la configuración de forma centralizada.

Nota: La configuración del portal de administración para esta función requiere la versión 2.1 o posterior del cliente de Cherri Code. Los usuarios con versiones anteriores no tendrán aplicadas las restricciones de extensiones.

Configuración de MDM:

Para gestionar de forma centralizada las extensiones permitidas, configura la política AllowedExtensions a través de tu solución de gestión de dispositivos. Esta política prevalece sobre la configuración del portal de administración y sobre los ajustes extensions.allowed configurados por el usuario en los dispositivos de los usuarios. El valor es una cadena JSON que define los editores y las extensiones permitidos.

Consulta Deployment Patterns para ver instrucciones de configuración de MDM específicas de cada plataforma.

La carpeta .cursor

Cuando abres un proyecto en Cherri Code, el Editor crea una carpeta .cursor en la raíz de tu repositorio. Esta carpeta contiene:

• Configuración específica del proyecto
• Reglas y contexto del proyecto

Esta carpeta se puede incluir en el control de versiones. Tu equipo se beneficia de reglas y configuraciones compartidas, pero ten en cuenta que estas configuraciones son visibles para cualquier persona con acceso al repositorio.

Para los repositorios cuyo acceso no controlas, revisa el contenido de la carpeta .cursor antes de hacer commit. No pongas información confidencial en los archivos de reglas.

También puedes gestionar reglas y comandos mediante el servidor en el panel del equipo.

Confianza en el espacio de trabajo

La configuración de Cherri Code security.workspace.trust.enabled controla si la función Workspace Trust está activada. Esta configuración acepta un valor booleano que determina si se solicitará a los usuarios que confíen en los espacios de trabajo antes de habilitar toda la funcionalidad.

Por ejemplo, establecer security.workspace.trust.enabled en true habilita los avisos de confianza en el espacio de trabajo, mientras que establecerlo en false desactiva completamente la función (todos los espacios de trabajo se consideran de confianza automáticamente).

Cuando la confianza en el espacio de trabajo está habilitada:

• Se solicita a los usuarios que confíen en cada nuevo espacio de trabajo cuando lo abren por primera vez
• Los espacios de trabajo no confiables se ejecutan en un modo restringido con funcionalidad limitada
• Las decisiones de confianza se guardan y se recuerdan para cada espacio de trabajo

Para administrar de forma centralizada la confianza en el espacio de trabajo de tu organización, configura la directiva WorkspaceTrustEnabled mediante tu solución de administración de dispositivos. Esta directiva anula la configuración security.workspace.trust.enabled en los dispositivos de los usuarios. El valor de esta directiva es un booleano (true o false).

Consulta Deployment Patterns para obtener instrucciones de configuración de MDM específicas de cada plataforma.