Saltar al contenido

Proveedores e identidades en Jitterbit App Builder

Descripción general

Toda aplicación de App Builder, fuente de datos y servicio web necesita una forma de confirmar quién o qué está realizando una solicitud, y de controlar qué se le permite hacer a quien la realiza. App Builder gestiona ambos aspectos a través de proveedores de seguridad, que son módulos configurables de forma independiente que se habilitan y configuran para adaptarse al 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 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, con su usuario o grupo de seguridad correspondiente de 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. Dependiendo de su tipo, un proveedor de seguridad puede cumplir 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 de App Builder.
  • Autenticación de fuente 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: Protege la conexión subyacente entre App Builder y una fuente de datos, independientemente de la identidad utilizada para autenticar.
  • Políticas de autorización: Gobierna qué se permite hacer a un usuario o conexión ya autenticado, diferenciado de confirmar quién es.

Cada proveedor de seguridad que se configura define su propio conjunto de parámetros, que el administrador del sitio establece para adaptarse al 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 desde el principio; los administradores pueden ajustar, deshabilitar o agregar a estos según sea necesario. También se pueden importar y exportar configuraciones de proveedores de seguridad.

Tipos de proveedores predeterminados

App Builder incluye los siguientes tipos de proveedores 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 API Proveedor de autenticación de API REST.
Servidor de autorización Permite que App Builder funcione como servidor de autorización OAuth 2.0 y OpenID Connect (OIDC).
HTTP Autentica solicitudes de clientes 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 de 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 fuente 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 usando OAuth2.
SAML Inicio de sesión único SAML (SSO).
Proveedor de identidades SAML Autenticación de inicio de sesión único SAML (SSO).
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 usuario 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 que sistemas externos llaman programáticamente, a diferencia de una página que una persona consulta. Desde App Builder 4.67, tres tipos de servicio web deben asociarse explícitamente con proveedores específicos configurados individualmente que estén 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 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 REST individual, endpoint Webhook o aplicación Remote Connector) se asocia con proveedores específicos configurados individualmente de esos tipos, no solo con el tipo en general; las páginas vinculadas describen cómo realizar esa asociación. Cuando se actualiza desde una versión anterior de App Builder, una migración asocia automáticamente cada proveedor existente de un tipo elegible con cada servicio web existente del tipo correspondiente, por lo que las integraciones existentes continúan 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 uno explícitamente.

Los pasos para 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 pueda editar. Para una aplicación sellada, que no se puede cambiar desde dentro de la app, consulta Servicios web de aplicación sellada abajo.

Servicios web de aplicación sellada

Sellar una aplicación, como sucede cuando se envía a un entorno de QA o producción, bloquea cada cambio en ella desde dentro de la app, incluyendo las asociaciones de servicio web por endpoint arriba.

Para una aplicación sellada que expone un servicio web, asocia sus proveedores de seguridad desde fuera de la app en su lugar, usando Applications. Ve a IDE > Security Providers, luego, en el panel Security Providers, selecciona More > Applications y haz clic en el icono en la columna Web Service de la aplicación. Esto abre el mismo diálogo 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 de sistema integrada que expone la API REST que usa el despliegue con un clic en el sistema de destino (QA o producción).

Autenticación predeterminada

Cada aplicación, ya sea creada por el usuario o una aplicación de sistema integrada, tiene un proveedor de Default Authentication: el proveedor utilizado, cuando se combina con la opción Redirect On Challenge de ese proveedor, para redirigir 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 el panel Security Providers, selecciona More > Applications, haz clic en el icono Edit de 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 reporta sobre el usuario a 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 del usuario. Esta sección cubre los dos mecanismos que App Builder usa para realizar esa traducción:

  • Identidades, que asignan una cuenta de usuario externa a un usuario de App Builder.
  • Grupos de proveedores, que asignan 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, tal como la reporta un proveedor de seguridad específico, a un usuario de App Builder. Siempre que ese proveedor autentique 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 saber 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 SAML SSO.

Las identidades tienen las siguientes propiedades:

  • Proveedor: El proveedor de seguridad (usuario o fuente 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 típicamente devuelve un conjunto de notificaciones, fragmentos de información sobre el usuario, como su nombre o un ID único, transmitidos en el token de autenticación o la aseveración; esta propiedad corresponde a la notificación Name.
  • Identificador: Un identificador único e inmutable asignado por el proveedor de seguridad, correspondiente a la notificación NameIdentifier. A diferencia de Name, este parámetro es opcional, pero recomendado cuando el proveedor lo soporta, ya que no cambia incluso si el nombre o nombre de usuario del usuario posteriormente lo hace.

Las identidades son necesarias cuando se delega la autenticación de usuarios a proveedores de seguridad externos como Salesforce o SAML Single Sign-On (SSO). 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 recurriendo a la notificación Name si no se encuentra coincidencia.

Las identidades también son relevantes para la autenticación de fuentes de datos. La mayoría de las conexiones de fuentes de datos se autentican como una única cuenta de servicio compartida, lo que significa que cada usuario de App Builder accede a la fuente de datos con las mismas credenciales. Sin embargo, algunas fuentes de datos soportan autenticación restringida por usuario, donde la conexión se autentica como el usuario específico de App Builder que ha iniciado sesión en lugar de ello. Para estas, el proveedor de seguridad utiliza el Nombre de la identidad si se define uno para el usuario, recurriendo al nombre de usuario de App Builder si no; el Identificador de la identidad no se utiliza para este propósito.

Grupos de proveedores

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

Los grupos de proveedores de seguridad tienen las siguientes propiedades:

  • Proveedor: El proveedor de seguridad (usuario o fuente 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 asigna el grupo del proveedor de seguridad.

Registro

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

  • Manual: Los administradores inician sesión en App Builder y agregan grupos de proveedores de seguridad directamente. Esto es típicamente necesario para proveedores de seguridad de fuentes de datos, que no tienen forma de reportar sus grupos a App Builder por sí solos.
  • 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 al grupo del usuario al mismo tiempo. Los proveedores de seguridad SAML y WS-Federation lo soportan, pero solo una vez que se habilitan explícitamente usando la bandera Supplies Group Membership de ese proveedor.

Asignación

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

Pertenencia

Un grupo de seguridad del proveedor amplía 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 los grupos de seguridad a los que el usuario pertenece a través de un grupo de seguridad del proveedor asignado.