Administrar la Configuración empresarial de autoservicio
Use la Configuración empresarial de autoservicio para delegar la configuración de SSO en sus clientes B2B.
La Configuración empresarial de autoservicio proporciona a los clientes B2B las herramientas necesarias para delegar la configuración de SSO en sus clientes empresariales y requiere una configuración mínima en su Tenant de Auth0 para ofrecer a sus clientes un asistente de autoservicio que los guíe durante el proceso de habilitación.Una vez que el cliente complete la configuración, la integración de SSO se agregará automáticamente a su Tenant como una conexión empresarial.
Los usuarios con los siguientes roles del Dashboard pueden usar esta funcionalidad:
Los usuarios con los roles Admin y Editor - Connections pueden crear y administrar perfiles de autoservicio.
Los usuarios con el rol Viewer - Config solo pueden ver perfiles de autoservicio.
Para habilitar la Configuración empresarial de autoservicio, configurará los siguientes componentes mediante la o el :
Perfil de autoservicio: Define elementos clave de las implementaciones de SSO de sus clientes, incluidos los (IdP) que pueden usar y qué atributos de usuario deben capturar, como el correo electrónico. Puede crear hasta 20 perfiles en su Tenant para distintos clientes o segmentos.
Ticket de acceso de autoservicio: Otorga a los administradores del cliente acceso al asistente de autoservicio y establece detalles específicos para la conexión empresarial resultante. Los tickets de acceso permiten a los administradores del cliente crear conexiones nuevas o modificar las existentes.
En las siguientes secciones se describen en detalle los pasos para configurar perfiles de autoservicio y generar tickets de acceso de autoservicio para compartir con los administradores del cliente.
Puede crear perfiles de autoservicio mediante el Auth0 Dashboard o la Management API.Los perfiles de autoservicio se utilizan para definir elementos clave de las implementaciones de los clientes, entre ellos:
Qué proveedores de identidad pueden usar los administradores del cliente para SSO.
Qué atributos de usuario deben recopilar mediante SSO, como el correo electrónico o el apellido.
Opciones de marca que personalizan el aspecto y la experiencia de uso del asistente de autoservicio.
Puede crear hasta 20 perfiles, según sea necesario, para adaptarse a distintos clientes o segmentos.
Auth0 Dashboard
Management API
Para crear un perfil de autoservicio en el Auth0 Dashboard:
Vaya a Authentication > Enterprise y abra la sección Configuración empresarial de autoservicio. Luego, seleccione Crear perfil.
En el espacio proporcionado, introduzca un nombre y, de forma opcional, una descripción para el perfil. Luego, seleccione Crear.
A. Opcional Adjunte un User Attribute Profile.
Si crea y adjunta, o habilita, un User Attribute Profile existente, no tendrá la opción de agregar atributos desde la pestaña User Profile.
1. Seleccione un UAP existente o cree uno nuevo. Para crear un UAP nuevo:
a. Agregue un nombre.
b. Revise las asignaciones para asegurarse de que los atributos del perfil se asignen a los atributos de Auth0 que prefiera.
En la pestaña Settings, complete las secciones a continuación. Luego, seleccione Save.
Proveedores de identidad (IdP): Habilite uno o varios proveedores de identidad. En el asistente de autoservicio, los administradores del cliente pueden seleccionar la opción que prefieran de la lista de proveedores habilitados.
Marca: Proporcione un logotipo y un color principal para el asistente de autoservicio.
Introducción personalizada: Modifique o sustituya el mensaje predeterminado según sea necesario. Este texto introductorio se muestra a los administradores del cliente en la página de inicio del asistente de autoservicio. El mensaje puede incluir opciones básicas de formato, como texto en negrita o hipervínculos, y está limitado a 2000 caracteres.
En la pestaña Perfil de usuario, agregue hasta 20 atributos de usuario que sus clientes deban recopilar mediante SSO, como correo electrónico o apellido. Puede establecer cada atributo como required u optional.
Durante el flujo del asistente de autoservicio, se pedirá a los administradores del cliente que asignen estos atributos de usuario definidos a su proveedor de identidad para garantizar que los valores necesarios se envíen a Auth0.
Para crear un perfil de autoservicio, primero llama al endpoint de Self-Service Profiles para crear el perfil. Luego, usa una llamada PUT para modificar su texto de introducción si es necesario.
Especifique los siguientes parámetros en el cuerpo de la solicitud, según corresponda:
Parámetro
¿Obligatorio?
Descripción
name
Sí
Cadena. La longitud máxima es de 100.
Un nombre descriptivo para el perfil de autoservicio.
description
No
Cadena. La longitud máxima es de 140.
Descripción del perfil de autoservicio.
allowed_strategies
No
Array.
Uno o más proveedores de identidad que los administradores del cliente pueden usar para implementar SSO. Si no se selecciona ningún parámetro, se incluyen todos de forma predeterminada.
Las opciones incluyen:
okta para Okta Workforce Identity
waad para Entra ID
google-apps para Google Workspace
keycloak-samlp para Keycloak
adfs para Microsoft Active Directory Federation Services
pingfederate para PingFederate
oidc para OIDC genérico
samlp para SAML genérico
branding
No
Objeto.
Se utiliza para personalizar el estilo del asistente de autoservicio que se muestra a los administradores del cliente.
branding.logo_url
No
Cadena. La longitud máxima es de 1024.
Una URL HTTPS que apunta a una imagen de logotipo. Si se proporciona, el logotipo se muestra en la esquina superior derecha del asistente de autoservicio.
branding.colors
No
Objeto.
Establece un color primario para ciertos elementos del asistente de autoservicio, como los botones interactivos.
branding.colors.primary
Sí, cuando se define branding.colors.
Cadena.
Especifica el valor hexadecimal del color principal que utiliza el asistente de autoservicio.
user_attributes
No
Objeto. La longitud máxima es de 20.
Almacena la información de asignación que se muestra a los administradores del cliente durante el flujo del asistente de autoservicio. Se indica a los administradores del cliente que asignen estos atributos a su Proveedor de identidad para garantizar que los atributos especificados se envíen a Auth0.
user_attributes[].name
Sí, al definir user_attributes.
Cadena. La longitud máxima es de 255.
Nombre del atributo del usuario en Auth0.
user_attributes[].description
Sí, al definir atributos de usuario.
Cadena. La longitud máxima es de 255.
Descripción del atributo de usuario legible para las personas.
user_attributes[].is_optional
Sí, al definir atributos de usuario.
Booleano.
Indica si un atributo es opcional o si el cliente debe proporcionarlo para que la aplicación funcione.
Para marcar un atributo como obligatorio, use true.
Cuando un admin de cliente accede al asistente de autoservicio, primero llega a una página de introducción que le da la bienvenida. De forma predeterminada, se muestra el siguiente mensaje:“Estás a pocos pasos de configurar el SSO. Este proceso de configuración implica realizar algunos cambios en tu proveedor de identidad. Antes de comenzar, abre tu proveedor de identidad en una pestaña o ventana separada del navegador.”Puede modificar este texto realizando una llamada PUT al endpoint Custom Text for Self-Service Profiles.
Tenga en cuenta que esta llamada sobrescribe cualquier mensaje configurado actualmente para el perfil de autoservicio. Asegúrese de que la llamada incluya el texto completo que desea mostrar a los administradores de sus clientes.
Llame a PUT /api/v2/self-service-profiles/{id}/custom-text/{language}/{page}, donde
id es el ID del perfil de autoservicio
language se establece en en
page se establece en get-started
En el cuerpo de la solicitud, especifique lo siguiente:
Propiedad
Descripción
introduction
Cadena. La longitud máxima es de 2000.
Texto completo de introducción que se mostrará en la página de inicio del asistente de autoservicio. El texto puede incluir opciones básicas de formato, como negrita o hipervínculos.
El texto personalizado proporcionado mediante este parámetro sobrescribe por completo cualquier mensaje anterior. Para obtener los mejores resultados, asegúrese de proporcionar el mensaje completo que desea mostrar a los administradores del cliente.
Enviar un cuerpo vacío \{} restablece cualquier mensaje personalizado al texto predeterminado.
Como respuesta, se devuelve la entidad creada.
Ejemplo de llamada
PUT /api/v2/self-service-profiles/ssp_1234567890/custom-text/en/get-started{ introduction: "Welcome! With <b>only a few steps</b>, you'll be able to setup your new connection. For assistance, contact <a href="https://www.examplesupportsite.com"> our support team </a>." }
Ejemplo de respuesta
{ introduction: "Welcome! With <b>only a few steps</b>, you'll be able to setup your new connection. For assistance, contact <a href="https://www.examplesupportsite.com"> our support team </a>." }
Después de crear al menos un perfil de autoservicio, puede generar tickets de acceso de autoservicio desde el Auth0 Dashboard o la Management API.Los tickets de acceso de autoservicio tienen dos objetivos principales:
Dar a los administradores del cliente acceso al asistente de autoservicio, donde pueden configurar una nueva conexión de SSO o modificar una conexión existente.
Predefinir detalles y comportamientos clave de las nuevas conexiones de SSO que configurarán los administradores del cliente, como qué aplicaciones u organizaciones se habilitarán para la nueva conexión.
Al generar tickets de acceso, también puede habilitar determinadas funciones, como SSO iniciado por el IdP, configurar dominios del Proveedor de identidad (que determinan Home Realm Discovery) y la verificación de dominio.
El SSO de SAML iniciado por el IdP es un tipo de implementación que permite que los proveedores de identidad inicien el SSO y redirijan a los usuarios al proveedor de servicios para la autenticación.Al habilitar esta opción para la Configuración empresarial de autoservicio, debe proporcionar la aplicación predeterminada y el protocolo de respuesta. También puede proporcionar una cadena de consulta opcional para personalizar aún más el comportamiento de la conexión.Para obtener más información sobre estas opciones, consulte Configurar el inicio de sesión único de SAML iniciado por el proveedor de identidad.
Verificación de dominios de correo electrónico y dominios preverificados
La Configuración empresarial de autoservicio admite tres formas de asociar dominios de correo electrónico con una conexión empresarial. Estos métodos rellenan el mismo campo: options.domain_aliases , que controla Home Realm Discovery (HRD) y, de forma condicional, los dominios de la organización para el descubrimiento:
Dominios preverificados (administrados por el Tenant): el administrador del Tenant agrega dominios conocidos directamente a la conexión.
Dominios por verificar: el administrador del Tenant especifica dominios que el administrador de TI debe verificar
durante la configuración. Estos dominios aparecen como pendientes en la organización y/o no se asocian automáticamente con la conexión hasta que el administrador de TI complete la verificación.
Verificación del dominio de correo electrónico (autogestionada): el administrador de su cliente verifica el dominio durante la configuración en el asistente de autoservicio.
Estos mecanismos para asociar dominios de correo electrónico se aplican a los dominios de correo electrónico que se usan para el enrutamiento de HRD y SSO. No están relacionados con la verificación de Custom Domain a nivel de Tenant.Para que un dominio aparezca tanto en los dominios de la organización para el descubrimiento como en HRD, el ticket debe:
Incluir solo un enabled_organization
Tener dominios preverificados o la Verificación de correo electrónico establecida en Required u Optional
Tener habilitada la casilla Allow the Use of Domains for Organization Discovery
Dominio preverificado
Use un dominio preverificado para asociar dominios de correo electrónico a una conexión empresarial a nivel de Tenant. Los dominios agregados se consideran de confianza y se escriben directamente en options.domain_aliases.Puede proporcionar dominios al generar tickets de acceso de autoservicio ya sea mediante Auth0 Dashboard o la Management API.
Auth0 Dashboard: En la página Generate Ticket, especifique la lista de dominios en el campo Pre-verified Domains.
Management API: Establezca connection_config.options.domain_aliases con la lista de dominios. De forma predeterminada, use_for_organization_discovery se establece en true. Opcionalmente, seleccione Allow the Use of Domains for Organization Discovery.
Los dominios agregados por los administradores del Tenant se consideran de confianza y no requieren que el administrador del cliente complete la verificación. Si quiere que los administradores de TI verifiquen un dominio en lugar de tratarlo como de confianza, establezca domain_aliases_config.domain_verification en required u optional para solicitar la verificación desde el asistente de autoservicio. La opción Allow Use of Domains for Organization Discovery requiere exactamente un enabled_organization en el ticket.
Dominios que se deben verificar
Use los dominios que se deben verificar para especificar qué dominios deben verificar los administradores de TI durante la configuración. A diferencia de los dominios preverificados, los dominios pendientes no se asocian automáticamente con la conexión ni con la Organización. Los administradores de TI deben completar la verificación en el asistente de configuración antes de que estos surtan efecto.Puede proporcionar dominios al generar tickets de acceso de autoservicio a través del Auth0 Dashboard o de la Management API:
Auth0 Dashboard: En la página Generate Ticket, especifique la lista de dominios en el campo Domains to be Verified.
Management API: Establezca connection_config.options.domain_aliases con la lista de dominios. De forma predeterminada, use_for_organization_discovery se establece en true. Opcionalmente, seleccione Allow the Use of Domains for Organization Discovery
Se aplican los siguientes límites:
Si la Organización está asociada con el ticket, el total combinado de dominios existentes y pendientes de la Organización no debe superar los 100.
Si no hay ninguna Organización o hay más de una Organización asociada con el ticket, el total combinado de alias de dominio existentes y pendientes no debe superar los 1.000.
Si al agregar los dominios pendientes se supera cualquiera de estos límites, la creación del ticket fallará con un error.
Verificación del dominio de correo electrónico
A diferencia de los dominios verificados previamente, la verificación del dominio de correo electrónico confirma que un administrador de TI es el propietario del dominio que proporciona durante la configuración de autoservicio. Cuando se completa la verificación, el dominio verificado se agrega a la misma matriz options.domain_aliases de la conexión.Puede habilitar la verificación para administradores de TI cuando genere tickets de acceso de autoservicio:
Auth0 Dashboard: En la página Generate Ticket, use el campo Domain Verification Requirement. De forma opcional, seleccione Allow the Use of Domains for Organization Discovery.
Management API: Use domain_aliases_config.domain_verification y, opcionalmente, use_for_organization_discovery con una de las siguientes opciones:
none (predeterminado): El asistente de autoservicio no solicita al administrador del cliente que verifique su dominio.
required: El asistente de autoservicio solicita al administrador del cliente que verifique sus dominios.
optional: El asistente de autoservicio solicita al administrador del cliente que verifique su dominio. El administrador del cliente puede optar por introducir su dominio para verificarlo o por omitir este paso.
La opción Allow Use of Domains for Organization Discovery requiere exactamente una Organización en el campo Enabled Organizations y que Domain Verification esté configurado como Optional, Required o dominios verificados previamente. En algunos casos, la verificación puede tardar hasta 48 horas, y es posible que deba emitir un ticket de acceso de seguimiento para que el administrador del cliente pueda volver y habilitar la conexión. Los tickets de acceso vencen cinco horas después de abrirse por primera vez. Consulte Generar tickets de acceso para conexiones existentes.
Eliminar un dominio
Los administradores de TI pueden eliminar dominios verificados desde el asistente de autoservicio. Se aplican las siguientes reglas según el requisito de verificación de dominio establecido en el ticket:Opcional: se pueden eliminar todos los dominios verificados.
Obligatorio: debe permanecer al menos un dominio verificado. Aparece una advertencia si el administrador de TI intenta eliminar el último dominio verificado.
Puede generar tickets de acceso para conexiones nuevas a través de Auth0 Dashboard o de Management API.
De forma predeterminada, las URL de los tickets de acceso siguen siendo válidas durante cinco días después de generarse. Después de acceder a la URL del ticket, el administrador del cliente dispone de cinco horas para completar la configuración. Se puede acceder a una URL de ticket de acceso un máximo de 10 veces; una vez alcanzado este límite, se debe solicitar un nuevo ticket de acceso.Si es necesario, puede revocar un ticket de acceso antes de que venza para interrumpir de inmediato el acceso al asistente de autoservicio.
Auth0 Dashboard
Management API
Para generar un ticket de acceso para una nueva conexión a través del Auth0 Dashboard:
Vaya a Authentication > Enterprise y acceda a la sección Configuración empresarial de autoservicio. Luego, seleccione el perfil de autoservicio con el que desea crear un ticket de acceso.
Seleccione Generate Ticket para abrir el formulario del ticket. En Select ticket type, elija Create a new connection.
En Ticket configuration, proporcione un nombre obligatorio para la conexión que configurará el administrador del cliente.
En la sección Settings, configure las opciones adicionales necesarias para la nueva conexión:
Domain: Seleccione el dominio personalizado que se usará en la URL del ticket. Solo está disponible cuando hay varios dominios personalizados.
Display Name: Un nombre descriptivo para la conexión que se muestra en las pantallas de Universal Login.
Enabled Clients: Una lista de ID de cliente separados por comas para asociarlos con la conexión.
Enabled Organizations: Una lista de ID de organización separados por comas para asociarlos con la conexión.
Display connection a as button: Muestra la conexión como una opción de autenticación en la pantalla de inicio de sesión.
Display connection as a button for organizations: Muestra la conexión como una opción de autenticación en la pantalla de inicio de sesión para las organizaciones especificadas.
Assign membership on login for organizations: Asigna automáticamente la membresía de la organización a los usuarios que se autentican con la conexión.
Enable as a domain level connection: Permite que aplicaciones de terceros usen la conexión; requiere Dynamic Client Registration.
En Domain-Based Discovery, opcionalmente proporcione una lista separada por comas de dominios de IdP ya verificados o pendientes de verificación para compararlos con los dominios de correo electrónico de los usuarios. Estos dominios se almacenan en options.domain_aliases y controlan HRD. Para obtener más información, consulte Home Realm Discovery.
En Domain Verification Requirement, elija el nivel de verificación que desee:
Off: No se solicita a los administradores del cliente que verifiquen su dominio al configurar SSO. Off es la configuración predeterminada para los nuevos tickets de acceso.
Optional: Se solicita a los administradores del cliente que verifiquen su dominio al configurar SSO. Sin embargo, pueden omitir este paso y habilitar su conexión sin completar la verificación.
Required: Los administradores del cliente deben verificar su dominio al configurar SSO. No podrán habilitar su conexión hasta que se complete la verificación.
En Provisioning, opcionalmente habilite Sync user profiles using provisioning. Cuando esta opción está habilitada, hay configuración adicional disponible:
Bearer Token Expiration: Defina una fecha de vencimiento para el Bearer Token de SCIM. De forma predeterminada, los Bearer Token no vencen.
Bearer Token Permissions (Scopes): Elija qué acciones puede realizar el token. De forma predeterminada, todos los alcances de aprovisionamiento están habilitados:
get:users
post:users
put:users
patch:users
delete:users
En Time to Live, establezca un período de vencimiento para el ticket de acceso en segundos. De forma predeterminada, el tiempo de vida se establece en 432000 segundos (lo que equivale a cinco días).
Time to Live determina durante cuánto tiempo una URL de ticket de acceso permanece activa antes de que un administrador del cliente inicie el asistente de autoservicio. No determina durante cuánto tiempo el administrador del cliente tendrá acceso al asistente después de iniciarlo. El vencimiento del propio asistente de autoservicio es de 5 horas y no se puede configurar.
En Metadata, agregue hasta 10 metadatos asociados con la conexión.
Revise la configuración del ticket de acceso para comprobar que sea correcta. Luego, seleccione Create Ticket.
A continuación, se muestra una ventana emergente de información del ticket que contiene la URL del ticket de acceso. Copie y guarde esta URL en un lugar seguro, ya que no podrá recuperarla nuevamente después de cerrar la ventana emergente.Puede compartir la URL del ticket de acceso con el administrador de su cliente por correo electrónico, chat u otro canal de comunicación para otorgarle acceso al asistente de autoservicio. Luego, el asistente le guiará en la configuración de la conexión SSO. Para obtener más información sobre esa experiencia, consulte Experiencia del asistente de autoservicio.
Para generar un ticket de acceso mediante la Management API.
Llame al endpoint Ticket de acceso SSO usando el ID del perfil de autoservicio correspondiente:
POST /api/v2/self-service-profiles/{id}/sso-ticket
Use el encabezado auth0-custom-domain para establecer el dominio personalizado que se usará en la URL del ticket. Esto solo está disponible cuando la función Multiple Custom Domains está habilitada.
En el cuerpo de la solicitud, especifique los parámetros descritos en la siguiente tabla.
Parámetro
Descripción
connection_config
Objeto.
Obligatorio al generar un ticket de acceso para una nueva conexión de SSO. Los administradores del cliente podrán modificar elementos clave de la conexión, como el certificado SAML o el ID o el secreto de OIDC.
connection_config.name
Obligatorio. cadena.
Nombre de la conexión creada mediante el asistente de configuración de SSO. Longitud máxima: 128.
connection_config.display_name
Opcional. Cadena.
Nombre descriptivo de la nueva conexión creada mediante el asistente de autoservicio. Este nombre se muestra en las pantallas de Universal Login. La longitud máxima es de 128.
connection_config.is_domain_connection
Opcional. Booleano.
Establézcalo en true si la conexión está configurada en el nivel de dominio; requiere Dynamic Client Registration.
connection_config.show_as_button
Opcional. Booleano.
Si es true, la conexión se muestra como una opción de autenticación en la pantalla de Login de tu aplicación.
connection_config.metadata
Opcional. Objeto[].
Metadatos asociados a la nueva conexión.
El objeto puede contener hasta 10 pares clave-valor. Los valores de tipo cadena están limitados a 255 caracteres.
connection_config.options
Opcional. Object[].
Opciones de la nueva conexión, incluidas:
icon_url
domain_aliases[]
idpinitiated
connection_config.options.icon_url
Opcional. cadena.
URL de la imagen de icono que se utilizará si connection_config.show_as_button está habilitado. Debe usar HTTPS.
connection_config.options.domain_aliases
Opcional. cadena[].
Dominios que se usarán para Home Realm Discovery.
Los dominios especificados en domain_aliases se marcan automáticamente como verificados. Si quiere que un administrador del cliente verifique un dominio por sí mismo, no especifique este atributo y use en su lugar domain_aliases_config (descrito más adelante en esta tabla). Esta opción le permite solicitar al administrador del cliente que verifique su dominio mediante el asistente de autoservicio.
Para obtener todos los detalles, consulte el endpoint SSO Access Ticket en el API Explorer de Management API.
domain_aliases_config
Opcional. Objeto.
Contiene las propiedades domain_verification y pending_domains para configurar cómo funciona la verificación de dominio.
domain_aliases_config.domain_verification
Opcional. cadena.
Determina si la verificación del dominio es obligatoria, opcional o si está deshabilitada.
Las opciones incluyen:
none: Deshabilita la verificación del dominio. También puede deshabilitar la verificación del dominio si omite el objeto domain_aliases_config de la solicitud.
optional: Permite que los administradores del cliente omitan la verificación del dominio durante la configuración.
required: Exige que los administradores del cliente verifiquen su dominio durante la configuración.
domain_aliases_config.pending_domains
Opcional. cadena[].
Dominios que el administrador de TI debe verificar durante la configuración. A diferencia de los dominios verificados previamente, estos dominios figuran como pendientes en la organización y no se asocian automáticamente con la conexión; el administrador de TI debe completar la verificación en el asistente de autoservicio antes de que surtan efecto.
domain_aliases_config.domain_verification debe establecerse en optional o required para usar este parámetro.
Se aplican las siguientes cuotas:
Si una organización está asociada al ticket, el total combinado de dominios de la organización existentes y pendientes no debe superar los 100.
Si no hay ninguna organización o hay más de una organización asociada al ticket, el total combinado de alias de dominio existentes y pendientes no debe superar los 1.000.
enabled_organizations
Opcional. Object[].
Una lista de organizaciones que se asociarán con la nueva conexión.
enabled_organizations[].organization_id
Obligatorio al usar enabled_organizations.
Cadena.
ID de una organización específica que se asociará con la nueva conexión.
Cuando es true, los usuarios que inicien sesión con la nueva conexión obtendrán automáticamente la membresía en la organización especificada.
enabled_organizations[].show_as_button
Opcional. Booleano.
Cuando es true, la nueva conexión se muestra como una opción de autenticación en la pantalla de Login de la Organización de su aplicación.
provisioning_config
Opcional. Objeto. Determina si el administrador del cliente puede configurar SCIM. Si la conexión se crea sin todos los scopes de aprovisionamiento, get:users, post:users, put:users, patch:users, delete:users, SCIM no se habilitará. Use google_workspace para configurar Google Workspace Directory Sync.
ttl_sec
Opcional. Número.
Número de segundos que una URL de ticket de acceso permanece activa antes de que un administrador del cliente inicie el asistente de autoservicio. Si no se especifica o se establece en 0, el valor predeterminado es 432000 (un máximo de 5 días).
Tenga en cuenta que este período de expiración no determina durante cuánto tiempo un administrador del cliente puede acceder al autoservicio una vez iniciado. La expiración del propio asistente es de 5 horas y no se puede configurar.
use_for_organization_discovery
Opcional. Booleano.
Indica si debe usarse un dominio verificado para detectar la organización durante la autenticación.
Una vez que reciba la URL del ticket, comparta el enlace con el Admin de su cliente para otorgarle acceso al asistente de autoservicio. El asistente lo guiará por el proceso de configuración de la conexión SSO. Para obtener más información sobre esta experiencia, consulte Experiencia del asistente de autoservicio.Puede integrar la generación de tickets de acceso en su propio portal de autoservicio o enviar las URL de los tickets directamente a los administradores de clientes por correo electrónico, chat u otros canales de comunicación.
Generar tickets de acceso para conexiones existentes
Puede generar tickets de acceso para conexiones existentes a través del Auth0 Dashboard o la Management API.
De forma predeterminada, las URL de los tickets de acceso siguen siendo válidas durante cinco días después de generarse. Después de acceder a la URL del ticket, el administrador del cliente dispone de cinco horas para completar la configuración. Se puede acceder a la URL de un ticket de acceso un máximo de 10 veces; una vez alcanzado este límite, se debe solicitar un nuevo ticket de acceso.Si es necesario, puede revocar un ticket de acceso antes de que venza para interrumpir de inmediato el acceso al asistente de autoservicio.
Si un administrador del cliente inicia la verificación de dominio a través del asistente de autoservicio, es posible que necesite un ticket de acceso adicional para completar el proceso de configuración.La verificación de dominio se realiza en el paso final del asistente de autoservicio. En este punto del flujo de trabajo, la conexión ya se ha creado, pero aún no se ha habilitado. Si se requiere la verificación de dominio, el administrador del cliente no podrá habilitar su conexión hasta que se complete la verificación.Aunque la verificación suele completarse en un plazo razonable, en algunos casos puede tardar entre 24 y 48 horas. Si esto ocurre, el administrador del cliente no podrá usar su ticket de acceso original para habilitar su conexión, ya que los tickets vencen cinco horas después de acceder a ellos por primera vez.Para completar este proceso, puede generar un ticket de acceso que permita al administrador del cliente modificar la conexión que configuró con su ticket inicial. Al crear este ticket, asegúrese de especificar el ID de la conexión que configuró con su primer ticket de acceso.
Auth0 Dashboard
Management API
Para editar un ticket de acceso a través del Auth0 Dashboard:
Vaya a Authentication > Enterprise y acceda a la sección Configuración empresarial de autoservicio. Luego, seleccione el perfil de autoservicio para el que desea crear un ticket de acceso.
Seleccione Generate Ticket para abrir el formulario del ticket. En Select ticket type, elija Edit an existing connection.
En Ticket configuration, proporcione el ID de la conexión existente que desea que modifique el administrador del cliente.
Seleccione Next.
En Enabled features, elija a qué flujos puede acceder el administrador de TI. Todas las opciones están habilitadas de forma predeterminada.
Edit SSO connection: Permite al administrador de TI modificar la conexión SSO. Deshabilite esta opción para darle acceso solo al aprovisionamiento o a la configuración del dominio, sin permitirle editar la conexión.
Provisioning: Permite al administrador de TI configurar el aprovisionamiento.
Domain configuration: Permite al administrador de TI verificar o administrar dominios.
En Domain Verification, elija el nivel de verificación que desee:
Off: No se solicita a los administradores del cliente que verifiquen su dominio al configurar SSO. Esta opción está seleccionada de forma predeterminada para los tickets de acceso nuevos.
Optional: Se solicita a los administradores del cliente que verifiquen su dominio al configurar SSO. Sin embargo, pueden omitir este paso y habilitar su conexión sin completar la verificación.
Required: Los administradores del cliente deben verificar su dominio al configurar SSO. No podrán habilitar su conexión hasta que se complete la verificación.
En Provisioning, habilite opcionalmente Sync user profiles using provisioning. Al habilitarlo, habrá opciones de configuración adicionales:
Bearer Token Expiration: Defina una fecha de vencimiento para el Bearer Token de SCIM. De forma predeterminada, los Bearer Token no vencen.
Bearer Token Permissions (Scopes): Elija qué acciones puede realizar el token. De forma predeterminada, todos los scopes de aprovisionamiento están habilitados:
get:users
post:users
put:users
patch:users
delete:users
En Time to Live, establezca un período de vencimiento para el ticket de acceso en segundos. De forma predeterminada, el tiempo de vida está configurado en 432000 segundos (equivalente a cinco días).A. El tiempo de vida determina durante cuánto tiempo una URL de ticket de acceso permanece activa antes de que un administrador del cliente inicie el asistente de autoservicio. No determina durante cuánto tiempo el administrador del cliente puede acceder al asistente una vez iniciado. El vencimiento del propio asistente de autoservicio es de cinco horas y no se puede configurar.
Revise la configuración del ticket de acceso para verificar que sea correcta. Luego, seleccione Create Ticket.
A continuación, aparecerá una ventana emergente de información del ticket que contiene la URL del ticket de acceso. Copie y guarde esta URL en un lugar seguro, ya que no podrá recuperarla después de cerrar la ventana emergente.Puede compartir la URL del ticket de acceso con el administrador del cliente por correo electrónico, chat u otro canal de comunicación para darle acceso al asistente de autoservicio. El asistente lo guiará durante la configuración de la conexión SSO. Para obtener más información sobre esa experiencia, consulte Self-service assistant experience.
Para generar un ticket de acceso a través de la Management API, siga los siguientes pasos.
No se pueden actualizar los detalles de connection_config de una conexión existente a través del endpoint ticket de acceso SSO. Si necesita modificar esta información en una conexión existente, use en su lugar el endpoint Update a Connection.
Obtén el ID del perfil de autoservicio que quieres asociar con el ticket de acceso mediante el endpoint Retrieve Self-Service Profiles.
Llame al endpoint Ticket de acceso de SSO con el ID del perfil de autoservicio correspondiente:POST /api/v2/self-service-profiles/{id}/sso-ticketEn el cuerpo de la solicitud, especifique los siguientes parámetros:
Parámetro
Descripción
connection_id
Obligatorio. Cadena.
ID de la conexión que un administrador del cliente puede actualizar mediante el asistente de autoservicio. Los administradores del cliente pueden modificar elementos clave de la conexión, como el certificado SAML o el ID y el secreto de OIDC.
Dominios que el administrador de TI debe verificar durante la configuración. Estos dominios figuran como pendientes en la organización y no se asocian automáticamente con la conexión; el administrador de TI debe completar la verificación en el asistente de autoservicio para que surtan efecto.
domain_aliases_config.domain_verification debe establecerse en optional o required para usar este parámetro.
Se aplican las siguientes cuotas:
Si hay una organización asociada al ticket, el total combinado de dominios de organización existentes y pendientes no debe superar los 100.
Si no hay ninguna organización asociada al ticket, o hay más de una, el total combinado de alias de dominio existentes y pendientes no debe superar los 1.000.
enabled_features
Opcional. Object.
Controla a qué flujos puede acceder el administrador de TI. Solo es compatible con tickets de edición de conexión.
Si se omite, las funciones activas se determinan en función de la presencia de otras propiedades de configuración en la solicitud (se conserva el comportamiento actual). Si se incluye, el objeto debe contener al menos una propiedad que no esté establecida explícitamente en false y no puede ser nulo ni estar vacío.
Si enabled_features.provisioning es true, se requiere provisioning_config en el cuerpo de la solicitud.
enabled_features.sso
Opcional. Booleano.
Cuando es true, el administrador de TI puede editar la conexión de SSO. Establézcalo en false para permitir el acceso únicamente a los flujos de aprovisionamiento o verificación de dominio, sin posibilidad de modificar la conexión.
enabled_features.provisioning
Opcional. Booleano.
Cuando es true, el administrador de TI puede configurar Provisioning. Requiere provisioning_config en el cuerpo de la solicitud.
enabled_features.domain_verification
Opcional. Boolean.
Cuando es true, el administrador de TI puede verificar o administrar dominios.
provisioning_config
Opcional. Objeto. Determina si el administrador del cliente puede configurar SCIM. Si la conexión se crea sin todos los scopes de aprovisionamiento, get:users,post:users,put:users, patch:users,delete:users, SCIM no se habilitará. Use google_workspace para configurar Google Workspace Directory Sync.
ttl_sec
Opcional. Número.
Número de segundos durante los que una URL de ticket de acceso permanece activa antes de que un administrador del cliente inicie el asistente de autoservicio. Si no se especifica o se establece en 0, el valor predeterminado es 432000 (equivalente a 5 días).
Tenga en cuenta que este período de expiración no determina durante cuánto tiempo un administrador del cliente tendrá acceso al asistente de autoservicio una vez iniciado. La expiración del asistente en sí es de cinco horas y no se puede configurar.
domain_aliases_config
Opcional. Objeto.
Contiene domain_verification, que se utiliza para determinar si la verificación del dominio es obligatoria, opcional o está deshabilitada.
Las opciones de domain_verification incluyen:
none: Deshabilita la verificación del dominio. También puede deshabilitar la verificación del dominio si omite el objeto domain_aliases_config de la solicitud.
optional: Permite que los administradores del cliente omitan la verificación del dominio durante la configuración.
required: Requiere que los administradores del cliente verifiquen su dominio durante la configuración.
use_for_organization_discovery
Opcional. Booleano.
Indica si debe usarse un dominio verificado para el descubrimiento de organizaciones durante la autenticación.
Una vez que reciba la URL del ticket, comparta el enlace con el Admin de su cliente para otorgarle acceso al asistente de autoservicio. El asistente lo guiará por el proceso de configuración de la conexión SSO. Para obtener más información sobre esta experiencia, consulte Experiencia del asistente de autoservicio.Puede integrar la generación de tickets de acceso en su propio portal de autoservicio o enviar las URL de los tickets directamente a los administradores de clientes por correo electrónico, chat u otros canales de comunicación.
De forma predeterminada, la URL de un ticket de acceso sigue siendo válida durante cinco días. Una vez que se accede a la URL, un administrador del cliente tiene cinco horas para completar la configuración.Si es necesario, puedes revocar un ticket de acceso antes de que venza. Por ejemplo, si un ticket de acceso se comparte con la incorrecta, puedes revocar el ticket para evitar el acceso no autorizado al asistente de autoservicio.Cuando revocas un ticket de acceso, su URL deja de ser válida de inmediato y todas las sesiones asociadas se terminan. Los administradores del cliente que tengan la URL ya no podrán acceder al asistente de autoservicio. Luego, puedes generar y compartir nuevos tickets de acceso según sea necesario.Para revocar un ticket de acceso:
Recupera el ID del perfil de autoservicio asociado al ticket de acceso mediante el endpoint Retrieve Self-Service Profiles.
Localiza el ID del ticket de acceso que quieres revocar. Los ID se encuentran al final de la URL del ticket de acceso.
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma