Configuración de Okta (OIDC)
Guía paso a paso para configurar el inicio de sesión único con Okta utilizando OpenID Connect.
Requisitos previos
- Cuenta de administrador en Okta
- Cuenta de administrador de organización en SecureCodingHub
Paso 1 — Cree una aplicación de Okta
Vaya a Okta Admin Console → Applications → Create App Integration
Método de inicio de sesión: OIDC
Tipo de aplicación: Web Application
Nombre de la aplicación: SecureCodingHub
URI de redirección de inicio de sesión: https://api.limeplate.com/api/sch/auth/sso/callback/oidc
Asignaciones: asígnela a sus usuarios/grupos
Paso 2 — Copie las credenciales
Recopile los siguientes valores de su aplicación de Okta:
| Ajuste | Dónde encontrarlo |
|---|---|
| Client ID | General → Client Credentials |
| Client Secret | General → Client Credentials |
| Dominio de Okta | Su URL de Okta (p. ej., dev-12345.okta.com) |
| URL de descubrimiento | https://{okta-domain}/.well-known/openid-configuration |
Paso 3 — Configure SSO en SecureCodingHub
Inicie sesión como administrador de organización → Ajustes de SSO
Protocolo: OIDC
Entity ID / Client ID: pegue su Client ID de Okta
URL de Discovery / Metadata: pegue su URL de configuración OpenID de Okta
Client Secret: pegue el secreto
Activar SSO
Haga clic en Guardar
Paso 4 — Pruebe
Abra una ventana de navegador en modo incógnito/privado
Vaya al inicio de sesión de SecureCodingHub
Introduzca una dirección de correo con el dominio de su organización
Debería ser redirigido al inicio de sesión de Okta
Tras la autenticación, debería iniciar sesión en SecureCodingHub
Errores comunes de SAML con Okta
Aunque esta guía se centra en OIDC, muchos tenants de Okta ejecutan SecureCodingHub sobre SAML, y los mismos problemas específicos de Okta se repiten. El primero es un desajuste en la URI de audiencia. Okta llama a este campo Audience URI (SP Entity ID) en SAML General Settings, y el valor debe coincidir exactamente con lo que SecureCodingHub publica como su entity ID. Un error habitual es introducir la URL del sitio web de SecureCodingHub en lugar del entity ID de la API. Verifique el valor frente al campo SP Entity ID en la página de ajustes SSO de SecureCodingHub antes de guardar la aplicación de Okta.
El segundo error es la política de inicio de sesión de la aplicación en Okta. Okta aplica una política a nivel de aplicación que puede requerir factores adicionales, restringir por zona de red o denegar el acceso por completo en función de la pertenencia a grupos. Si un usuario final informa de que SSO le redirige a Okta y luego rebota con un error de acceso denegado, la causa casi siempre es una regla de la política de inicio de sesión de la aplicación que no coincide con el usuario. Compruebe Sign On Policy en la aplicación y confirme la regla que se aplica al usuario de prueba. El tercer error común es un formato de Name ID no coincidente. Okta usa por defecto Unspecified, pero SecureCodingHub espera el formato emailAddress. Establezca el formato de Name ID en EmailAddress en los ajustes de la aplicación y confirme que el atributo origen es user.email o user.login.
Cómo verificar que SSO funciona de extremo a extremo
La verificación comienza en una sesión de navegador en modo incógnito para evitar cualquier cookie de inicios de sesión anteriores. Vaya a la página de login de SecureCodingHub, introduzca una dirección de correo corporativa con su dominio verificado y confirme que el navegador redirige a su tenant de Okta. Tras autenticarse en Okta, la redirección debería llevarle a SecureCodingHub, al panel de la organización correcta. Si aterriza en una página genérica o en un 404, la causa más probable es que el usuario aún no exista en SecureCodingHub y que el aprovisionamiento JIT esté desactivado o haya rechazado el evento de creación.
Segundo, verifique la asignación de rol y de asiento. Los usuarios aprovisionados mediante JIT siempre aterrizan con el rol learner — SecureCodingHub no lee información de rol desde los claims de grupos de Okta hoy en día, por lo que la promoción a org_admin debe hacerse desde la UI de administración de SecureCodingHub después de que el usuario exista. Tercero, cierre sesión y vuelva a iniciar sesión. El segundo inicio de sesión debería ser casi silencioso gracias a la cookie de sesión de Okta. Si el segundo inicio de sesión fuerza una reautenticación completa, la duración de la sesión de Okta está configurada con un tiempo demasiado corto para el uso normal; ajuste la política global de sesión o la política de inicio de sesión de la aplicación en consecuencia. Para los detalles a nivel de protocolo, consulte la Guía de configuración de SAML.