SSO y un registro de auditoría, sin una llamada de ventas enterprise

El inicio de sesión único se trata como una función de nivel enterprise en la mayoría de las plataformas, encerrada tras una conversación de ventas y un precio que asume unos cientos de puestos. La mayoría de los equipos que de verdad lo quieren son chicos —un puñado de ingenieros que preferirían no mantener una contraseña separada para la única herramienta que puede reiniciar producción.

Cómo configurarlo

Settings → Single sign-on, solo admins. Los dos casos comunes están soportados directamente, no uno con el otro agregado después:

OpenID Connect —Google Workspace, Okta, Microsoft Entra, Authentik, Keycloak, o cualquier otro proveedor OIDC:

1. Crea una app web de OpenID Connect en tu proveedor de identidad, usando el redirect URI que muestra la página.
2. Completa la Issuer URL, el Client ID, el Client secret y el dominio de correo al que aplica.
3. Elige el rol con el que se une la gente nueva —lector, desarrollador o admin.
4. Opcionalmente, exige SSO para ese dominio, lo que apaga por completo el login con contraseña para él.

SAML 2.0 —elígelo en la misma página, pega la URL de inicio de sesión del proveedor de identidad y el certificado, y Railyard muestra la ACS URL, el entity ID y los metadatos del SP para entregarle a Okta, Entra, OneLogin, JumpCloud o ADFS. Las respuestas se revisan por firma, audiencia, tiempo e ID de solicitud —no se aceptan solo porque se pudieron parsear.

Antes de que alguien pueda iniciar sesión de verdad por cualquiera de los dos métodos, el dominio tiene que verificarse con un registro TXT (_railyard-sso.<domain>) —SSO nunca inicia sesión en una cuenta de operador del sitio ni en una cuenta fuera del equipo, y la autenticación en dos pasos sigue siendo obligatoria incluso para quienes entran por SSO.

SCIM, una vez guardado el SSO

Apunta la app SCIM 2.0 de tu proveedor de identidad a https://app.railyard.run/scim/v2 con un token bearer generado, y la membresía del equipo deja de ser un paso manual: asignar a alguien en el proveedor de identidad lo agrega al equipo, desactivarlo lo quita. A los propietarios nunca se los elimina de esta forma —ese rol sigue siendo una acción humana y deliberada.

El registro de auditoría, y qué cubre realmente

Activity en la barra lateral registra despliegues, cambios de variables, cambios de miembros, aprobaciones y jobs de datos —filtrable por miembro, app, tipo y rango de fechas, exportable como CSV. Los cambios de variables muestran quién cambió qué nombre y cuándo, nunca el valor en sí, así que el registro es útil sin convertirse en un segundo lugar desde donde se filtren secretos.

Lo que vale la pena saber: las acciones que un operador de Railyard toma sobre tu propio equipo —cambiar límites, suspender, reincorporar— terminan en este mismo registro, no en uno separado que solo nosotros podamos ver. Si se hizo algo con tu equipo, puedes verlo igual que verías cualquier cosa que hicieran tus propios miembros.

El puntaje que te dice si todo esto realmente está activo

Settings → Security revisa diez cosas y le pone al equipo un puntaje de 0 a 100: autenticación en dos pasos en cada miembro, admins que no iniciaron sesión en 90 días, servidores con actualizaciones de seguridad pendientes, sistemas operativos fuera de soporte, puertos abiertos, vencimiento de certificados, verificación de backups, stagings sin proteger, y tokens de API sin vencimiento. Cada comprobación que falla enlaza directo a su solución, así que “tenemos un puntaje de seguridad” no se queda sin leer al fondo de una página de configuración.

Referencia completa: Equipos, SSO y acceso.