Saltar al contenido

Proveedores e identidades en Jitterbit App Builder

Descripción general

Toda aplicación App Builder, fuente de datos y servicio web necesita una forma de confirmar quién o qué está realizando una solicitud y controlar qué puede hacer ese solicitante. App Builder maneja ambos aspectos a través de proveedores de seguridad, que son módulos configurables de forma independiente que se habilitan y configuran según tu entorno, en lugar de un único sistema de inicio de sesión integrado. Por ejemplo, un proveedor de seguridad podría verificar un nombre de usuario y contraseña contra la tabla de usuarios propia de App Builder, otro podría validar una clave de API enviada por un sistema externo, y un tercero podría delegar la decisión completamente a un servicio de identidad de terceros como Salesforce o un proveedor de SSO.

Algunos proveedores de seguridad también admiten identidades: registros que vinculan una cuenta de usuario o grupo definido por un sistema externo, como un proveedor de identidades de terceros o una fuente de datos externa, a su usuario o grupo de seguridad correspondiente en App Builder. Una identidad permite que App Builder reconozca a un usuario que inicia sesión a través de un proveedor externo como un usuario específico de App Builder que ya existe, en lugar de tratar cada inicio de sesión externo como desconocido.

Esta página cubre:

Proveedores

No todos los proveedores de seguridad realizan el mismo trabajo. Según su tipo, un proveedor de seguridad puede desempeñar uno o más de los siguientes roles:

  • Autenticación de usuarios: Confirma la identidad de una persona que inicia sesión en una aplicación App Builder.
  • Autenticación de fuentes de datos: Confirma la identidad que presenta App Builder cuando se conecta a una fuente de datos externa, como una base de datos o una API de terceros.
  • Seguridad a nivel de conexión: Asegura la conexión subyacente entre App Builder y una fuente de datos, independientemente de la identidad utilizada para autenticarse.
  • Políticas de autorización: Rige qué puede hacer un usuario o conexión ya autenticado, distinto de confirmar quién es.

Cada proveedor de seguridad que configures define su propio conjunto de parámetros, que el administrador del sitio establece para adaptarse a tu entorno. App Builder incluye una configuración predeterminada que ya habilita un conjunto inicial de proveedores de seguridad, por lo que la autenticación generalmente funciona lista para usar; los administradores pueden ajustar, deshabilitar o agregar más según sea necesario. También se pueden importar y exportar configuraciones de proveedores de seguridad.

Tipos de proveedor predeterminados

App Builder incluye los siguientes tipos de proveedor predeterminados, cada uno cubriendo un esquema de autenticación o autorización específico. Selecciona el nombre de un proveedor para acceder a su guía de configuración.

Tipo de proveedor Descripción
Active Directory (AD) Proveedor de autenticación basado en formularios.
Clave de API Proveedor de autenticación de API REST.
Servidor de autorización Permite que App Builder funcione como un servidor de autorización OAuth 2.0 y OpenID Connect (OIDC).
HTTP Autentica solicitudes de cliente HTTP a API REST.
Autenticación integrada de Windows (IWA) Esquema de SSO para dominios de Active Directory.
Jitterbit Harmony Autentica solicitudes HTTP a puntos finales de Jitterbit API Manager.
SSO con JWT Protocolo de inicio de sesión único (SSO) personalizado.
Usuario local Proveedor de autenticación basado en formularios.
OAuth Proveedor de autorización OAuth.
OData Esquemas de autenticación de fuentes de datos OData.
OpenID Connect Habilita la compatibilidad con OpenID Connect 1.0.
Reescribir URL Restaura una URL reescrita por un proxy inverso.
Salesforce Autenticación y autorización de Salesforce mediante OAuth2.
SAML Inicio de sesión único (SSO) SAML.
Proveedor de identidades SAML Autenticación de inicio de sesión único (SSO) SAML.
Servicios OData de SAP Esquemas de autenticación del servicio OData de SAP NetWeaver Gateway.
OData de SuccessFactors Esquemas de autenticación del servicio web OData de SuccessFactors.
Contraseña de SuccessFactors Proveedor de autenticación de usuario basado en formularios.
Aprovisionamiento de usuarios Registro de usuarios programático.
Gestión de acceso web (WAM) Esquema de SSO para sistemas heredados de gestión de acceso web.
WS-Federation SSO de WS-Federation.

Asociaciones de servicio web

Un servicio web, en este contexto, es un endpoint al que los sistemas externos hacen llamadas de forma programática, a diferencia de una página que una persona consulta. Desde App Builder 4.67, se deben asociar explícitamente tres tipos de servicio web con proveedores específicos e individualmente configurados autorizados para autenticar sus solicitudes. Anteriormente, cualquier proveedor habilitado de un tipo elegible podía autenticar solicitudes a cualquier servicio web, independientemente del tipo.

Servicio web Ruta Tipos de proveedor elegibles Configurar autenticación
REST API /rest/v1 Clave API, HTTP, Servidor de autorización Publicar una aplicación Jitterbit App Builder como endpoint de REST API
Webhook /webhook/v1 Clave API, HTTP, Servidor de autorización Webhooks en Jitterbit App Builder
Conector de App Builder /connect/v1 Clave API, HTTP, Servidor de autorización Conector de App Builder en Jitterbit App Builder

Cada instancia de servicio web (cada endpoint de REST individual, endpoint de Webhook o aplicación de Conector remoto) se asocia con proveedores específicos e individualmente configurados de esos tipos, no solo del tipo en general; las páginas vinculadas describen cómo hacer esa asociación. Cuando se actualiza desde una versión anterior de App Builder, una migración asocia automáticamente todos los proveedores existentes de un tipo elegible con todos los servicios web existentes del tipo correspondiente, para que las integraciones existentes continúen autenticándose sin reconfiguración manual. Un servicio web creado después de actualizar a App Builder 4.67 no se asocia automáticamente con ningún proveedor y no autenticará solicitudes hasta que se asocie explícitamente uno.

Los pasos de Configurar autenticación vinculados arriba se realizan desde dentro de la aplicación misma, lo que solo funciona para una aplicación que aún se puede editar. Para una aplicación sellada, que no se puede modificar desde dentro de la app, consulta Servicios web de aplicación sellada a continuación.

Servicios web de aplicación sellada

Sellar una aplicación, como ocurre cuando se envía a un entorno de control de calidad o producción, bloquea todos los cambios desde dentro de la app, incluidas las asociaciones de servicio web por endpoint anteriores.

Para una aplicación sellada que expone un servicio web, asocia sus proveedores de seguridad desde fuera de la app, usando Manage Applications. Ve a IDE > Security Providers, luego, en User Authentication, selecciona More > Manage Applications y haz clic en el icono en la columna Web Service de la aplicación. Esto abre el mismo diálogo de Authentication Providers descrito arriba.

A partir de App Builder 4.68, este icono también aparece para la aplicación Vinyl - Release Management, la aplicación del sistema integrada que expone la API de REST que usa implementación con un clic en el sistema de destino (control de calidad o producción).

Autenticación predeterminada

Cada aplicación, ya sea creada por el usuario o una aplicación del sistema integrada, tiene un proveedor de Default Authentication: el proveedor usado, cuando se combina con la opción Redirect On Challenge de ese proveedor, para redirigir a un usuario no autenticado a un proveedor de inicio de sesión cuando intenta acceder a una página protegida. Ve a IDE > Security Providers, luego, en User Authentication, selecciona More > Manage Applications, haz clic en el icono Edit para la aplicación, selecciona un proveedor en el campo Default Authentication y haz clic en Proceed.

Gestión de identidades

Cuando un proveedor de seguridad delega la autenticación a un sistema externo, ya sea un proveedor de identidades de terceros como Salesforce o SAML SSO, o una fuente de datos externa, App Builder necesita una forma de traducir lo que ese sistema externo informa sobre el usuario en sus propios términos: una cuenta de usuario específica de App Builder y, opcionalmente, los grupos de seguridad de App Builder de los que deben provenir los permisos de ese usuario. Esta sección cubre los dos mecanismos que usa App Builder para realizar esa traducción:

  • Identidades, que vinculan una cuenta de usuario externa a un usuario de App Builder.
  • Grupos de proveedores, que vinculan un grupo, rol o ámbito externo a un grupo de seguridad de App Builder, para que los permisos de un usuario se deriven de su pertenencia a grupos externos, en lugar de asignarse a cada usuario individualmente.

Identidades

Una identidad vincula una cuenta de usuario externa, según la reporta un proveedor de seguridad específico, a un usuario de App Builder. Cada vez que ese proveedor autentica una solicitud en nombre de una cuenta externa, App Builder necesita una identidad coincidente para saber cuál de sus propios usuarios corresponde a esa cuenta. Sin una, App Builder no tiene forma de determinar qué usuario de App Builder representa la cuenta externa. Un usuario puede tener solo una identidad por proveedor de seguridad, pero puede tener identidades separadas para diferentes proveedores, por ejemplo, si la misma persona puede iniciar sesión tanto a través de Salesforce como de SSO SAML.

Las identidades tienen las siguientes propiedades:

  • Proveedor: El proveedor de seguridad (usuario u origen de datos) que posee la identidad.
  • Nombre: El nombre de usuario único asignado por el proveedor de seguridad. Durante la autenticación, un proveedor de identidad externo normalmente devuelve un conjunto de notificaciones, información sobre el usuario, como su nombre o un ID único, incluida en el token de autenticación o la aserción; esta propiedad corresponde a la notificación Name.
  • Identificador: Un identificador único e inmutable asignado por el proveedor de seguridad, que corresponde a la notificación NameIdentifier. A diferencia de Name, este parámetro es opcional, pero se recomienda cuando el proveedor lo admite, ya que no cambia aunque el nombre o nombre de usuario del usuario cambien más adelante.

Las identidades son obligatorias cuando se delega la autenticación de usuario a proveedores de seguridad externos como Salesforce o SSO SAML (Inicio de Sesión Único). Para completar el inicio de sesión, App Builder toma las notificaciones suministradas por el proveedor y busca una identidad coincidente, verificando primero la notificación NameIdentifier y retrocediendo a la notificación Name si no se encuentra coincidencia.

Las identidades también entran en juego para la autenticación del origen de datos. La mayoría de las conexiones de origen de datos se autentican como una única cuenta de servicio compartida, lo que significa que cada usuario de App Builder accede al origen de datos con la misma credencial. Sin embargo, algunos orígenes de datos admiten autenticación restringida por usuario, donde la conexión se autentica como el usuario específico de App Builder que ha iniciado sesión. Para estos, el proveedor de seguridad usa el Nombre de la identidad si está definido para el usuario, retrocediendo al nombre de usuario de App Builder si no; el Identificador de la identidad no se usa para este propósito.

Grupos de proveedores

Más allá de identidades individuales, un proveedor externo también puede definir sus propios grupos de seguridad, a veces llamados roles o ámbitos, que agrupan a varios usuarios juntos, por ejemplo, un rol "Gerentes de Ventas" de Salesforce o un grupo "Finanzas" de IdP SAML. En lugar de asignar permisos a cada usuario individualmente a través de su identidad, un administrador de seguridad puede vincular cada uno de estos grupos externos a un único grupo de seguridad de App Builder, de modo que cada usuario perteneciente al grupo externo herede automáticamente los permisos otorgados al grupo de seguridad correspondiente de App Builder.

Los grupos de proveedores de seguridad tienen las siguientes propiedades:

  • Proveedor: El proveedor de seguridad (usuario u origen de datos) al que pertenece el grupo.
  • Identificador: El nombre único asignado al grupo por el proveedor de seguridad.
  • Grupo: El grupo de seguridad de App Builder al que se vincula el grupo del proveedor de seguridad.

Registro

Antes de que un grupo de proveedores de seguridad se pueda vincular, primero debe existir en App Builder como un registro. Los grupos de proveedores de seguridad se pueden registrar de dos formas:

  • Manual: Los administradores inician sesión en App Builder y agregan grupos de proveedores de seguridad directamente. Esto suele ser necesario para proveedores de seguridad de origen de datos, que no tienen forma de reportar sus grupos a App Builder por su cuenta.
  • Automático: App Builder registra nuevos grupos de proveedores de seguridad sobre la marcha, durante el proceso de autenticación del usuario, actualizando la pertenencia del usuario al grupo al mismo tiempo. Los proveedores de seguridad SAML y WS-Federation admiten esto, pero solo una vez habilitados explícitamente mediante la bandera Supplies Group Membership de ese proveedor.

Asignación

Independientemente de cómo se registre un grupo de proveedor de seguridad, se puede asignar a un grupo de seguridad de App Builder. Cada grupo de proveedor de seguridad se puede asignar a uno, y solo uno, grupo de seguridad de App Builder; sin embargo, varios grupos de proveedor de seguridad se pueden asignar al mismo grupo de seguridad de App Builder.

Pertenencia

Un grupo de proveedor de seguridad extiende la pertenencia del grupo de seguridad de App Builder de un usuario en lugar de reemplazarla. Al calcular los derechos de acceso de un usuario, App Builder toma en cuenta tanto los grupos de seguridad a los que el usuario pertenece directamente como cualquier grupo de seguridad al que el usuario pertenece a través de un grupo de proveedor de seguridad asignado.