Haga que las personas inicien sesión con su proveedor de identidad

Qué hace

• Una conexión por organización. Un administrador de la organización la configura en Configuración de la organización del dashboard, en Inicio de sesión único.
• Sus dominios deciden quién lo usa. La página de inicio de sesión pide primero el correo electrónico. Una dirección de uno de sus dominios verificados continúa hacia su proveedor.
• Su proveedor decide quién entra. Una persona cuya dirección no tiene cuenta se crea en su primer inicio de sesión, a menos que desactive Create accounts at first sign-in en la conexión. Una persona nueva no tiene proyecto hasta que una invitación o un grupo aprovisionado le da uno.
• Sus personas son miembros. Una persona que inicia sesión mediante su proveedor es miembro de su organización. Solo su proveedor la elimina.
• Require single sign-on rechaza las contraseñas y los passkeys en sus dominios.

Antes de empezar

• Usted es administrador de la organización.
• La organización tiene un dominio verificado. En Configuración de la organización, en Dominios verificados, ingréselo en Agregar un dominio, elija Obtener registro DNS, publique el registro TXT que se muestra y luego elija Verificar example.com (su propio dominio en su lugar). Deje el registro en su lugar: screenRIG lo comprueba a diario y elimina un dominio cuyo registro sigue ausente durante 7 días, y el inicio de sesión único se detiene para sus direcciones.
• Los cambios en la conexión 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, pero solo cuando su proveedor indica cuándo se autenticó la persona (auth_time en OpenID Connect, AuthnInstant en SAML). De lo contrario, screenRIG pide a la persona que inicie sesión de nuevo en el proveedor antes del cambio.

Su proveedor pide estos valores:

Cada conexión tiene su propio URI de redirección, porque el ID de conexión forma parte de la dirección. Tras guardar una conexión, la configuración de Inicio de sesión único en Configuración de la organización muestra el valor exacto de cada uno en Valores para su proveedor de identidad, con su ID de conexión ya completado.

Microsoft Entra ID

La opción predefinida de Entra permite iniciar sesión a las personas de un solo tenant mediante OpenID Connect.

1. En el Microsoft Entra admin center, abra App registrations y elija New registration. Póngale nombre y elija Accounts in this organizational directory only. Deje vacío el URI de redirección: el paso 6 lo agrega.
2. Abra Certificates & secrets, cree un secreto de cliente y copie ahora su Value, no su ID.
3. Abra Token configuration, elija Add optional claim, elija el tipo ID y agregue email y, junto a él, auth_time. Sin auth_time, Entra no indica cuándo se autenticó la persona, y una acción sensible devuelve a la persona a Entra para que inicie sesión de nuevo (vea Lo que ven las personas).
4. En Overview, copie el Application (client) ID y el Directory (tenant) ID.
5. En Configuración de la organización, en Inicio de sesión único, elija Configurar inicio de sesión único y luego Microsoft Entra ID. Ingrese un Nombre, que las personas ven en la página de inicio de sesión, el ID de inquilino, el ID de cliente y el Secreto del cliente, y elija Guardar conexión.
6. En Valores para su proveedor de identidad, copie el URI de redirección, https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback con su ID de conexión. En Entra, abra Authentication, agregue la plataforma Web (no Single-page application: el intercambio del código se ejecuta en nuestro servidor) e ingrese el valor.
7. Haga una prueba de inicio de sesión.

screenRIG reconoce a una persona por su ID de objeto de Entra, nunca por correo electrónico ni por nombre principal de usuario, que los administradores de Entra pueden editar: cambiar el nombre de un usuario conserva su cuenta. Se rechazan los tokens de cualquier otro tenant. screenRIG lee la dirección del claim email y, en un tenant de Entra, recurre a preferred_username cuando falta email; el claim opcional del paso 3 hace que sea la dirección de correo de la persona. Entra no envía email_verified, así que screenRIG acepta la dirección porque pertenece a un dominio que usted verificó. Entra permite que inicie sesión todo usuario del tenant, salvo que Assignment required de la aplicación empresarial sea Yes.

Okta y otros proveedores de OpenID Connect

Esto sirve para Okta, Auth0, Keycloak y cualquier proveedor con un documento de descubrimiento en /.well-known/openid-configuration.

1. En el proveedor, cree una aplicación web que use el flujo de código de autorización. En Okta, elija Applications, Create App Integration, OIDC, Web Application. Puede que el proveedor pida un URI de redirección antes de que screenRIG tenga uno para usted: ingrese ahora cualquier dirección https y reemplácela en el paso 4. Asigne las personas o los grupos que pueden iniciar sesión.
2. Copie el ID de cliente, el secreto de cliente y el emisor, la dirección https que indica el documento de descubrimiento. En Okta es la URL de la organización, como https://example.okta.com, o la dirección de un servidor de autorización personalizado.
3. En Configuración de la organización, en Inicio de sesión único, elija Configurar inicio de sesión único y luego OpenID Connect. Ingrese un Nombre, el Emisor, el ID de cliente y el Secreto del cliente, y elija Guardar conexión.
4. En Valores para su proveedor de identidad, copie el URI de redirección, https://screenrig.ai/api/sso/oidc/CONNECTION_ID/callback con su ID de conexión, e ingréselo como URI de redirección de la aplicación en el proveedor.
5. Haga una prueba de inicio de sesión.

El proveedor debe admitir PKCE con S256, el modo de respuesta form_post y tokens de ID firmados con un algoritmo asimétrico, y debe permitir los alcances openid, email y profile. Su token de ID debe incluir un claim email: solo un tenant de Entra recurre a otro claim. Un claim email_verified, cuando se envía, debe ser verdadero. Envíe un claim auth_time donde el proveedor pueda: así es como screenRIG sabe cuándo se autenticó la persona.

SAML 2.0

Esto sirve para una aplicación empresarial de Entra, Okta, Google Workspace y cualquier otro proveedor SAML 2.0. Empiece en el proveedor y luego ingrese sus metadatos en screenRIG, que muestra los valores que el proveedor necesita.

screenRIG exige que cada respuesta cumpla estas condiciones:

• La respuesta contiene exactamente una aserción, y no está cifrada.
• La propia aserción está firmada con RSA o ECDSA y SHA-256 o superior. Se rechaza SHA-1, y también una respuesta firmada que envuelve una aserción sin firmar.
• El emisor de la aserción es el ID de entidad de su proveedor, y su restricción de audiencia nombra el ID de entidad de screenRIG.
• El inicio de sesión comienza en screenRIG. Se rechaza un icono en el portal de aplicaciones de su proveedor (inicio de sesión iniciado por el IdP); las personas empiezan en la página de inicio de sesión de screenRIG.
• Los relojes difieren en no más de 3 minutos, y cada aserción se usa una sola vez.
• El NameID está presente, con el formato persistente, dirección de correo electrónico o no especificado. Se rechaza un NameID transitorio, o de cualquier otro formato. El NameID es el identificador de la persona en screenRIG; para Entra es el atributo de ID de objeto.
• El correo electrónico llega como el atributo email, mail, urn:oid:0.9.2342.19200300.100.1.3, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress o http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn, o como un NameID con formato de correo electrónico.

Entra ID

1. Abra Enterprise applications, New application, Create your own application, y elija Integrate any other application you don't find in the gallery.
2. Abra Single sign-on y elija SAML. En SAML Certificates, descargue el Federation Metadata XML y establezca Signing Option en Sign SAML assertion o Sign SAML response and assertion.
3. En Configuración de la organización, en Inicio de sesión único, elija Configurar inicio de sesión único y luego SAML 2.0. Ingrese un Nombre, pegue el XML de metadatos en Documento de metadatos y elija Guardar conexión. Valores para su proveedor de identidad muestra entonces el ID de entidad y la Dirección del servicio de consumidor de aserciones (ACS).
4. En Entra, edite Basic SAML Configuration: el Identifier es el ID de entidad y la Reply URL es la dirección ACS.
5. Deje los claims predeterminados: incluyen el ID de objeto de la persona y su dirección de correo. Compruebe que las personas que asigna tengan una dirección de correo.
6. Asigne personas en Users and groups y luego haga una prueba de inicio de sesión.

Las personas que ya iniciaron sesión mediante OpenID Connect conservan sus cuentas cuando un tenant pasa a SAML, y al revés: ambos protocolos identifican a una persona por el tenant y el ID de objeto de Entra. La respuesta SAML debe incluir el claim del identificador de objeto, que los claims predeterminados de Entra incluyen. Sin él, screenRIG recurre al NameID, y una cuenta vinculada mediante OpenID Connect deja de coincidir (subject_mismatch).

Okta

1. Elija Applications, Create App Integration, SAML 2.0. Okta pide la Single sign-on URL y la Audience URI antes de mostrar sus metadatos: ingrese ahora cualquier dirección https para ambas.
2. Establezca Name ID format en Persistent y Application username en Email, y agregue el attribute statement email con el valor user.email. En Show Advanced Settings, deje Assertion Signature en Signed con Signature Algorithm RSA-SHA256 y Digest Algorithm SHA256, y Assertion Encryption desactivado.
3. Elija Finish, abra la pestaña Sign On y copie los metadatos de Identity Provider.
4. En Configuración de la organización, en Inicio de sesión único, elija Configurar inicio de sesión único y luego SAML 2.0. Ingrese un Nombre, pegue los metadatos en Documento de metadatos y elija Guardar conexión. Copie el ID de entidad y la Dirección del servicio de consumidor de aserciones (ACS) de Valores para su proveedor de identidad.
5. En Okta, edite SAML Settings: la Single sign-on URL es la dirección ACS y la Audience URI es el ID de entidad.
6. Asigne personas y luego haga una prueba de inicio de sesión.

Google Workspace

1. En la Admin console, abra Apps, Web and mobile apps, Add app, y elija Add custom SAML app. Póngale nombre.
2. Descargue los metadatos de Google Identity Provider y continúe.
3. En Configuración de la organización, en Inicio de sesión único, elija Configurar inicio de sesión único y luego SAML 2.0. Ingrese un Nombre, pegue los metadatos en Documento de metadatos y elija Guardar conexión. Copie el ID de entidad y la Dirección del servicio de consumidor de aserciones (ACS) de Valores para su proveedor de identidad.
4. En Google, ingrese la dirección ACS y el ID de entidad. Establezca Name ID format en PERSISTENT y Name ID en Basic Information, Primary email. Deje Signed response sin marcar: así Google firma la aserción, lo que screenRIG exige.
5. Asocie el atributo Primary email de Google Directory con el atributo de la aplicación email.
6. Abra User access de la aplicación y actívelo para las personas que inician sesión; luego haga una prueba de inicio de sesión.

Rotar un certificado

Una conexión confía en hasta cuatro certificados de firma, así que la rotación se hace sin interrupción. Pegue el certificado nuevo junto al anterior (o pegue los metadatos nuevos del proveedor, que incluyen ambos) y guarde, cambie el proveedor al certificado nuevo y luego elimine el anterior.

Test sign-in

Pulse Prueba de inicio de sesión en Configuración de la organización. Usted inicia sesión en su proveedor y regresa al dashboard, que muestra la dirección que envió el proveedor y si envió un identificador estable. Una prueba no inicia sesión de nadie. Una prueba fallida muestra el mensaje de uno de los códigos de error. La dirección debe pertenecer a un dominio verificado.

Una prueba correcta, o un inicio de sesión real, mediante el proveedor, el tenant, el ID de entidad y el protocolo actuales de la conexión es lo que le permite exigir el inicio de sesión único.

Require single sign-on

Elija Exigir inicio de sesión único en Configuración de la organización tras una prueba correcta, seleccione a los administradores de emergencia y confirme. Para todas las personas de sus dominios verificados:

• La página de inicio de sesión ofrece solo su proveedor. Una contraseña o un passkey se rechaza con sso_required. Las contraseñas y los passkeys permanecen en la cuenta, sin usarse, y vuelven a funcionar si desactiva el requisito.
• Una cuenta existente cuya dirección verificada pertenece a su dominio inicia sesión en esa misma cuenta en su primer inicio de sesión único, sean cuales sean los métodos de inicio de sesión que tenga, y conserva sus proyectos. Su organización pasa entonces a administrarla: su correo electrónico sigue lo que indica su proveedor en cada inicio de sesión y la persona no puede cambiarlo.
• Administradores de emergencia. Elija hasta dos administradores de la organización que tengan un passkey. Conservan el inicio de sesión con passkey para el día en que su proveedor no esté disponible, y cada uno de esos inicios de sesión queda registrado. Cambiar administradores de emergencia cambia la elección más adelante.
• Mientras el requisito está activo, el emisor, el ID de tenant, el ID de entidad y el protocolo de la conexión no pueden cambiar y la conexión no puede eliminarse. Los certificados y el secreto de cliente sí pueden rotarse.

Desactivarlo tarda 72 horas. Elija Turn off requirement: el requisito sigue vigente hasta entonces, cada administrador recibe un correo electrónico y cualquier administrador puede elegir Cancel removal.

Lo que ven las personas

• La página de inicio de sesión pide primero el correo electrónico y continúa hacia su proveedor. La respuesta depende solo del dominio, así que no revela si una persona tiene una cuenta.
• Una sesión dura 24 horas desde el inicio de sesión en screenRIG, y el uso no la prolonga. Pasadas 12 horas, el dashboard la renueva en silencio en la página siguiente, y vuelve a iniciar sesión de la misma manera cuando termina una sesión. Un inicio silencioso no envía ninguna sugerencia de inicio de sesión, así que el proveedor responde por la cuenta de la que tiene una sesión; si es otra persona, la renovación falla con subject_mismatch. Una persona cuya sesión en el proveedor sigue activa no escribe nada; en caso contrario, inicia sesión de nuevo.
• Una acción que pide un passkey o una contraseña, como cambiar la conexión, acepta en su lugar una sesión de inicio de sesión único que cuenta como inicio de sesión reciente durante 10 minutos. Solo cuenta cuando su proveedor indica cuándo se autenticó la persona: la hora del propio proveedor (auth_time en OpenID Connect, AuthnInstant en SAML), no la hora del inicio de sesión en screenRIG. Cuando el proveedor no indica ninguna hora, o indica una de hace más de 10 minutos, screenRIG pide a la persona que inicie sesión de nuevo en el proveedor: el dashboard envía a la persona a través del proveedor para una autenticación nueva y la devuelve al lugar donde estaba.
• Una persona que su proveedor deshabilita pierde el acceso en un plazo de 24 horas, y de inmediato con el aprovisionamiento de usuarios. 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.

Vincular una cuenta existente

Un primer inicio de sesión único (account_exists) no abre la cuenta de screenRIG con contraseña o passkey que ya tiene una persona de su dominio verificado, a menos que usted exija el inicio de sesión único. La persona inicia sesión como antes, abre Perfil e inicio de sesión en https://screenrig.ai/dashboard/me, elige Vincular inicio de sesión único e inicia sesión en el proveedor. A partir de entonces, el inicio de sesión único abre la misma cuenta, que conserva sus propios métodos de inicio de sesión. Perfil e inicio de sesión ofrece el vínculo a toda persona de su dominio con sesión iniciada que aún no lo ha vinculado.

Solución de problemas

Un inicio de sesión fallido vuelve a la página de inicio de sesión con el código en la dirección (#sso_error=CODE). Una prueba fallida muestra en la conexión el mensaje correspondiente a su código.

Relacionado

• Aprovisionamiento de usuarios: cree, actualice y elimine personas desde su proveedor, y dé a los grupos acceso a proyectos.
• Autenticación: cómo inician sesión los agentes y cómo se aprueba el acceso.
• Referencia API: las rutas de conexión, política e inicio de sesión.