Aprovisione personas con SCIM

Qué hace el aprovisionamiento

• Altas. Asigne a una persona a la aplicación en su proveedor y screenRIG crea su cuenta y la hace miembro de su organización. La persona inicia sesión mediante el inicio de sesión único y no tiene contraseña. No tiene proyecto hasta que un grupo le da uno.
• Cambios. Un grupo vinculado a un proyecto da ese proyecto a sus miembros. Unirse al grupo o salir de él agrega o quita el acceso.
• Bajas. Al desactivar a una persona o quitarle la asignación, terminan sus sesiones y su acceso. Los agentes y los permisos OAuth que una persona aprobó siguen funcionando hasta que la persona se desactiva, por el aprovisionamiento de usuarios o por el personal de screenRIG: exigir el inicio de sesión único y deshabilitar a la persona en su proveedor no les ponen fin.

Antes de empezar

• El inicio de sesión único está configurado y la organización tiene un dominio verificado. El aprovisionamiento crea solo direcciones en sus dominios verificados.
• Usted es administrador de la organización.

Actívelo

1. En Configuración de la organización, abra Aprovisionamiento de usuarios (SCIM) y elija Activar aprovisionamiento. Copie la URL base, https://api.screenrig.ai/scim/v2. Está en el origen de la API, no en el del dashboard.
2. En Tokens de aprovisionamiento, elija Crear token, ingrese un Nombre del token (Entra, por ejemplo) y confirme. Copie el token ahora: srscim_ seguido de 43 caracteres, se muestra una sola vez. screenRIG guarda solo un hash.

Activar el aprovisionamiento y crear un token piden su passkey o su contraseña. En su lugar, una sesión de inicio de sesión único cuenta como inicio de sesión reciente durante 10 minutos, cuando su proveedor indica cuándo se autenticó la persona; de lo contrario, el dashboard pide a la persona que inicie sesión de nuevo en el proveedor.

Una organización admite hasta cinco tokens. Para rotar uno, cree un token nuevo, péguelo en su proveedor y luego revoque el anterior; el aprovisionamiento sigue funcionando. La lista muestra cuándo se usó por última vez cada token. Desactivar el aprovisionamiento hace que toda solicitud responda 403 y no cambia el acceso de nadie.

Microsoft Entra ID

1. Abra su aplicación empresarial (la que lleva el inicio de sesión único), elija Provisioning y establezca Provisioning Mode en Automatic.
2. En Admin Credentials, ingrese la URL base como Tenant URL y el token como Secret Token. Elija Test Connection y luego Save.
3. Abra Mappings, Provision Microsoft Entra ID Users. Asigne userName a partir de userPrincipalName (o de mail cuando sus nombres principales de usuario no son las direcciones con las que las personas inician sesión), emails[type eq "work"].value a partir de mail, y deje active en su valor predeterminado, Switch([IsSoftDeleted], , "False", "True", "True", "False"). Conserve las demás asignaciones que propone Entra. screenRIG usa el correo electrónico de trabajo; si no existe, el correo principal; si no, userName. Esa dirección debe pertenecer a un dominio verificado y ser la dirección que envía su inicio de sesión único.
4. Mantenga habilitado Provision Microsoft Entra ID Groups para dar acceso por grupo.
5. En Settings, establezca Scope en Sync only assigned users and groups y luego asigne las personas y los grupos en Users and groups.
6. Establezca Provisioning Status en On y guarde. Entra ejecuta un primer ciclo y luego sincroniza aproximadamente cada 40 minutos. Provision on demand sincroniza de inmediato a una persona o un grupo.

Okta

1. Abra su aplicación de screenRIG. En General, edite App Settings y establezca Provisioning en SCIM.
2. Abra Provisioning, Integration, Edit. Ingrese la URL base como SCIM connector base URL y userName como Unique identifier field for users, marque Push New Users, Push Profile Updates y Push Groups, y establezca Authentication Mode en HTTP Header. En una aplicación SCIM personalizada, pegue el token en el campo HTTP Header. Donde Okta pide un API Token (las aplicaciones de prueba SCIM de Okta), ingrese Bearer, un espacio y el token. Ambos funcionan. Elija Test Connector Configuration y luego Save.
3. Abra To App, Edit, y habilite Create Users, Update User Attributes y Deactivate Users. Deje Sync Password desactivado: screenRIG ignora las contraseñas.
4. En Sign On, establezca Application username format en Email.
5. Asigne las personas y los grupos en Assignments, y envíe los grupos que vincule en Push Groups.

Okta desactiva a una persona con active: false y nunca elimina.

Grupos y proyectos

Los grupos aprovisionados se enumeran en Configuración de la organización, en Aprovisionamiento de usuarios (SCIM), en Grupos aprovisionados, con su número de miembros y los proyectos a los que están vinculados. Un grupo no da ningún acceso hasta que una persona que puede aprobar en un proyecto lo vincula:

1. En el proyecto, abra Acceso y luego Grupos. Cualquier miembro puede consultar las vinculaciones; el propietario del proyecto, los miembros que pueden aprobar y los administradores de la organización que son miembros vinculan un grupo.
2. En Vincular un grupo, elija un Grupo y un Rol: Miembro, una membresía simple, o Aprobador, que además aprueba revisiones. Elija Vincular grupo. Quitar vinculación desvincula el grupo.

Una vinculación también puede limitar lo que da a carpetas de pantallas y pantallas, el mismo alcance de pantallas al que se puede limitar a un miembro: en Vincular un grupo, elija Todo el proyecto o Limitado a pantallas (una vinculación de Aprobador solo nombra carpetas). Las pantallas de una persona en el proyecto son la unión de los alcances de sus vinculaciones, y toda vinculación sin alcance da todo el proyecto; la persona aprueba solo donde sus vinculaciones de Aprobador cubren todas esas pantallas, así que ser Aprobador de una carpeta y Miembro de todo el proyecto hace de la persona un miembro simple de todo el proyecto. El aprovisionamiento nunca reduce un acceso concedido a mano y no limita a una persona mientras estén activos los clientes de servicio que creó: cada rechazo de este tipo aparece en la actividad reciente de Aprovisionamiento de usuarios, y el alcance se aplica en la siguiente sincronización una vez revocados los clientes. El alcance de una vinculación es fijo; para cambiarlo, quite la vinculación y vincule el grupo de nuevo.

• Sin alcances, una persona en varios grupos vinculados tiene el rol más alto: Aprobador sobre Miembro.
• Unirse a un grupo o salir de él agrega o quita la membresía. Desvincular un grupo, o eliminarlo en su proveedor, retira lo que concedió.
• El aprovisionamiento quita solo lo que agregó. Una membresía concedida a mano se mantiene, y un miembro al que un grupo subió a Aprobador vuelve a lo que tenía cuando sale del grupo.
• Una organización admite hasta 200 miembros en todos sus proyectos, contando cada persona una sola vez. Una persona que la organización rechaza se registra como un fallo en los eventos de aprovisionamiento y nada más cambia.
• Los grupos conceden solo roles de proyecto, nunca administrador de la organización. Los administradores ven las vinculaciones y los nombres de proyecto, no el contenido de los proyectos.

A quién se puede aprovisionar

• Una dirección de un dominio verificado sin cuenta crea una, sin contraseña.
• Una persona que no tiene contraseña ni passkey, a quien administra su organización, o que pertenece a una organización que exige el inicio de sesión único, pasa a quedar bajo el aprovisionamiento e inicia sesión mediante el inicio de sesión único.
• Una persona que ya tiene un inicio de sesión propio y es miembro de uno de los proyectos de su organización se vincula solo para el acceso, a menos que su organización exija el inicio de sesión único. El aprovisionamiento administra su acceso a sus proyectos y nunca su nombre, correo electrónico ni inicio de sesión.
• Cualquier otra persona se rechaza con un error que indica el motivo: una cuenta con su propio inicio de sesión que no es miembro de sus proyectos, una persona que administra otra organización y el personal de screenRIG. Invite antes a esa persona a uno de sus proyectos y el aprovisionamiento la vinculará entonces para el acceso.

Desactivación y DELETE

active: false, enviado por PUT o PATCH, y DELETE terminan ambos el acceso de una persona. active: true revierte una desactivación, como indican las tablas.

Una persona desactivada por alguien que no sea su aprovisionamiento, como el personal de screenRIG, permanece desactivada: active: true falla con 400 mutability. Un proyecto que posee una persona nunca se transfiere: una persona vinculada conserva su acceso a él, y el proyecto de una persona administrada queda en espera con el resto de su cuenta hasta la reactivación. Transfiera su propiedad antes de desactivar al propietario si otras personas deben seguir administrándolo. El último administrador de la organización no puede desactivarse como persona administrada; la solicitud falla con 400 mutability, así que agregue antes a otro administrador.

Referencia

URL base https://api.screenrig.ai/scim/v2. El token va en Authorization: Bearer srscim_TOKEN, y también se acepta un token solo. Las solicitudes y las respuestas son application/scim+json; se acepta application/json.

Los filtros son de uno a cuatro términos attribute eq value unidos por and. Un valor es una cadena entre comillas, o true o false para active. Los usuarios se filtran por userName (sin distinguir mayúsculas), externalId (exacto), id, emails o emails.value, displayName y active. Los grupos se filtran por displayName, externalId, id y members o members.value. Cualquier otro filtro da 400 invalidFilter.

PATCH lee las operaciones tal como las envían Entra y Okta, con o sin ?aadOptscim062020. Los nombres de operación no distinguen mayúsculas, y los booleanos son true, false, "True" o "False". Una operación puede omitir path o usar claves con puntos como {"name.givenName": "Ada"}. Las rutas incluyen emails[type eq "work"].value, members (agregar, reemplazar y quitar con un arreglo de valores) y members[value eq "<id>"] (quitar). Los atributos que screenRIG no usa se aceptan y se ignoran.

Límites. Una organización puede enviar 600 solicitudes por minuto entre todos sus tokens, no por dirección, porque Entra y Okta comparten direcciones de origen. Al superar el límite, la respuesta es 429 con Retry-After. Las autenticaciones fallidas se limitan a 30 cada 10 minutos por dirección.

Los errores usan la estructura de error de SCIM con scimType, como invalidFilter, uniqueness o mutability:

{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"], "status": "409", "scimType": "uniqueness", "detail": "…" }

En Configuración de la organización, Aprovisionamiento de usuarios enumera las últimas 500 solicitudes, que se conservan 30 días, con los fallos y su motivo. Mire allí primero cuando algo no llegue.

Solución de problemas

Relacionado

• Inicio de sesión único: conecte Entra ID, Okta, Google Workspace u otro proveedor, y exíjalo.
• Autenticación: cómo inician sesión los agentes y cómo se aprueba el acceso.
• Referencia API: las rutas /scim/v2 y de aprovisionamiento.