Proveedor de seguridad OAuth en Jitterbit App Builder

Introducción

El proveedor de seguridad OAuth habilita la compatibilidad con OAuth 2.0. El proveedor de seguridad es responsable de autorizar solicitudes de servicios web. Los siguientes tipos de fuentes de datos admiten OAuth:

• REST

• OData

• RDBMS (limitado a proveedores CData compatibles)

Además, es posible configurar un proveedor de seguridad OAuth como proveedor de autenticación externo. Consulta a continuación para obtener información adicional.

Concesiones de OAuth 2.0

El proveedor de seguridad OAuth admite las siguientes concesiones de OAuth 2.0:

• Código de autorización RFC 6749.

• Credenciales del cliente RFC 6749.

• Credenciales de contraseña del propietario del recurso RFC 6749.

• Aserción de portador SAML 2.0 RFC 7522.

• Token de portador JWT RFC 7523.

Código de autorización

La concesión de código de autorización de OAuth 2.0 proporciona autorización delegada a nivel de usuario. Esta concesión se define en RFC 6749.

En el flujo de código de autorización, App Builder redirige el agente de usuario (navegador) al servidor de autorización. Una vez que el usuario ha iniciado sesión correctamente y aprobado la solicitud de autorización, el servidor de autorización redirige el agente de usuario de vuelta a App Builder. La redirección incluye un código de autorización. App Builder realiza una solicitud por canal trasero al servidor de autorización, intercambiando el código de autorización por un token de acceso. El token de acceso se puede utilizar para autorizar solicitudes a servicios web.

Por sí solo, OAuth proporciona autorización, no autenticación. Por lo tanto, los proveedores de seguridad OAuth no se utilizan típicamente como proveedores de autenticación externos: se utilizan para autorizar solicitudes a un proveedor de datos compatible, como OData o REST. Sin embargo, si el proveedor de seguridad OAuth publica un punto de conexión que proporciona la identidad del usuario, el proveedor de seguridad OAuth se puede utilizar como proveedor de autenticación externo. Consulta el Punto de conexión de información del usuario para obtener más detalles.

Credenciales del cliente

La concesión de credenciales del cliente de OAuth 2.0 proporciona autenticación a nivel de cliente, similar a una cuenta de servicio. En este flujo, se intercambian las credenciales del cliente OAuth por un token de acceso OAuth. La concesión de credenciales del cliente se define en RFC 6749.

Credenciales de contraseña del propietario del recurso

La concesión de credenciales de contraseña del propietario del recurso de OAuth 2.0 se define en RFC 6749. Sin embargo, la concesión ha sido deprecada.

Tal como se concibió originalmente, la concesión de credenciales de contraseña del propietario del recurso de OAuth 2.0 proporciona autorización a nivel de usuario. El usuario proporciona su nombre de usuario y contraseña a un cliente de confianza. El cliente de confianza intercambia las credenciales por un token de acceso.

App Builder proporciona compatibilidad parcial con la concesión de credenciales de contraseña del propietario del recurso de OAuth 2.0. App Builder no solicita al usuario sus credenciales. En su lugar, se utiliza una única credencial para autorizar a todos los usuarios. De esta manera, la concesión es funcionalmente equivalente a una cuenta de servicio.

Aserción de portador SAML 2.0

La concesión de aserción de portador SAML 2.0 de OAuth 2.0 proporciona autenticación de fuente de datos a nivel de usuario. En este flujo, se intercambian aserciones SAML por tokens de acceso OAuth. La concesión de aserción de portador SAML 2.0 de OAuth 2.0 se define en RFC 7522.

Token de portador JWT

La concesión de token de portador JWT de OAuth 2.0 proporciona autenticación de fuente de datos a nivel de usuario. En este flujo, se intercambian tokens web JSON (JWT) por tokens de acceso OAuth. La concesión de token de portador JWT de OAuth 2.0 se define en RFC 7523.

Configuración

La configuración varía según la concesión de OAuth. Como mínimo, OAuth requiere:

• Identificador de cliente (client_id) y secreto de cliente (client secret).

• Punto final de token.

Las concesiones de OAuth individuales requerirán configuración adicional según se indica a continuación.

Autenticación

Las propiedades de autenticación determinan la concesión de OAuth y los esquemas de autenticación.

• Tipo de autenticación: OAuth

• Concesión de OAuth: Selecciona una concesión de OAuth compatible.

• Autenticación de cliente OAuth: Determina el esquema de autenticación de cliente OAuth 2.0 RFC 6749 Sección 2.3. Las opciones incluyen:

  • Básico: Indica que se utilizará el esquema de contraseña de cliente. Las credenciales se suministrarán mediante autenticación HTTP Basic. (client_secret_basic.)

  • JWT de secreto de cliente: El cliente se autentica mediante un token web JSON (JWT) firmado con el secreto de cliente (client_secret_jwt). (Consulta Tipos de autenticación de cliente JWT.)

  • Ninguno: Indica que el cliente no debe autenticarse. (none.)

  • Publicación: Indica que se utilizará el esquema de contraseña de cliente. Las credenciales se suministrarán como parámetros de formulario en el cuerpo de la solicitud. (client_secret_post.)

  • JWT de clave privada: El cliente se autentica mediante un token web JSON (JWT) firmado con una clave privada (private_key_jwt). (Consulta Tipos de autenticación de cliente JWT.)

• Autenticación de recursos de OAuth: Determina el esquema de autenticación de solicitud de recursos. Las opciones incluyen:

  • Portador: Esquema de autenticación de portador. Predeterminado.

  • Formulario: Añade el token de acceso al cuerpo codificado en URL de formulario.

  • Consulta: Añade el token de acceso a la cadena de consulta.

• Propietario del token: Determina si los tokens se emiten a usuarios individuales o al sistema cliente. Las opciones incluyen:

  • Usuario: Los tokens se emiten a usuarios individuales.

  • Cliente: Los tokens se emiten al sistema cliente.

• Eliminar token al cerrar sesión: Cuando está habilitado, App Builder elimina el token almacenado cuando el usuario cierra sesión. Predeterminado: Deshabilitado.

Tipos de autenticación de cliente JWT

Los tipos de autenticación de cliente JWT admiten las siguientes opciones de configuración:

• Aserción:

  • Emisor: Sin valor predeterminado. A menudo utiliza un identificador de aplicación o el ID de cliente. Consulta la documentación del servidor de autorización.

  • Audiencia: Por defecto, el punto final del token (tal como se define en el panel Puntos finales) según el estándar.

  • Asunto: Por defecto, el ID de cliente (tal como se especifica en el panel Credenciales) según el estándar.

• Credenciales:

  • Tipo: Client

    Se requiere ID de cliente. Secreto de cliente se ignora y puede omitirse.

• Certificados:

  • Uso: Signing

    Un certificado solo lo utiliza el tipo de autenticación de cliente JWT de clave privada. El JWT de secreto de cliente utiliza el secreto de cliente como clave.

• Propiedades:

  • Parámetro: JwtClaimSet

  • Parámetro: SigningAlgorithm

Token

Las siguientes concesiones generan tokens que se intercambian por tokens de acceso de OAuth:

• Aserción de portador SAML 2.0.

• Token de portador JWT.

Aserción de portador SAML 2.0

• Emisor: El emisor de la aserción SAML.

• Audiencia: La restricción de audiencia de la aserción SAML. Aunque la especificación SAML indica que la audiencia es un URI, muchas implementaciones no lo respetan. En consecuencia, App Builder no requiere que la audiencia sea un URI.

• Destinatario: El URI del destinatario de la aserción SAML (por ejemplo, http://example.com/service).

Token de portador JWT

• Emisor: Reclamación de emisor JWT (https://tools.ietf.org/html/rfc7523#section-3). Por defecto, el identificador de cliente (client_id).

• Asunto: Reclamación de asunto JWT (https://tools.ietf.org/html/rfc7523#section-3).

• Si el Propietario del Token es Usuario, se establece de forma predeterminada la identidad del usuario actual.

• Si el Propietario del Token es Cliente, se requiere el Asunto.

• Audiencia: Reclamación de audiencia JWT (https://tools.ietf.org/html/rfc7523#section-3). Se establece de forma predeterminada en el Punto de Conexión de Token.

Puntos de Conexión

Credenciales

Certificados

Propiedades

El proveedor de seguridad OAuth admite los siguientes parámetros adicionales:

Código de autorización

Las siguientes propiedades adicionales se aplican a la concesión de Código de Autorización.

Aserción de portador SAML 2.0

Las siguientes propiedades adicionales se aplican a la concesión de Aserción de Portador SAML 2.0.

Token portador JWT

Las siguientes propiedades adicionales se aplican a la concesión de Token Portador JWT.

Rest

Las siguientes propiedades adicionales se aplican cuando se utiliza el proveedor de seguridad OAuth para autenticar fuentes de datos REST. Se ignoran para puntos finales OAuth y otros tipos de fuentes de datos, incluidos OData y RDBMS.
Los encabezados de solicitud deben separarse por un retorno de carro (aparecer en su propia línea).

Compatibilidad de protocolos

Tokens de actualización

Si la solicitud de token de acceso incluye un token de actualización, App Builder intentará automáticamente utilizar el token de actualización para adquirir un nuevo token de acceso después de recibir una respuesta 401 Unauthorized.

Código de autorización

Solicitud de autorización

Al construir una solicitud de autorización, App Builder incluirá el identificador del cliente (client_id), el secreto del cliente (client_secret) y los alcances (scope). Además, App Builder añadirá automáticamente los siguientes parámetros estándar:

• redirect_uri: App Builder construye el parámetro redirect_uri a partir de la URL actual. Toma la forma https://example.com/Vinyl/signin-OAuth, donde OAuth es el esquema del proveedor de seguridad OAuth.

• state: El parámetro state es una carga útil cifrada y opaca. Incluye un token de falsificación de solicitud entre sitios (CSRF) según RFC 6749.

Punto final de redirección

Según se define en RFC 6749, la concesión de código de autorización expone un punto final de redirección. Este punto final escucha las respuestas de autorización en la dirección:

• https://example.com/Vinyl/signin-OAuth

Donde https://example.com/Vinyl es la URL absoluta al directorio raíz de la aplicación App Builder y OAuth es el esquema que distingue entre mayúsculas y minúsculas del proveedor de seguridad. Cualquier carácter especial debe estar codificado en URL.

La mayoría de las aplicaciones de terceros deberán configurarse con el punto final de redirección antes de autorizar cualquier solicitud.

Proxy inverso

Desde App Builder 4.59, el URI de redirección de OAuth omite el número de puerto cuando se utiliza el puerto predeterminado. Esto garantiza compatibilidad con proveedores OAuth cuando App Builder se aloja detrás de un proxy inverso.

Para solucionar este problema con App Builder 4.58 o anterior, configura un proveedor de seguridad URL Rewrite para eliminar el puerto explícito del URI de redirección:

1. Navega a IDE > Security Providers.
2. En el panel Configuration, expande el menú More y haz clic en Import Provider.

3. Pega la siguiente configuración, reemplazando example.com con el nombre de host de App Builder:

   {
     "name": "URL Rewrite",
     "type": "rewrite_url",
     "settings": {
       "MatchUrl": "https://example.com:443",
       "RewriteUrl": "https://example.com"
     }
   }
   

4. Haz clic en el botón Import, luego haz clic en Proceed para confirmar.

5. Regresa a la página Security Providers. En el panel Configuration, expande el menú More y haz clic en Request Pipeline.
6. Localiza el proveedor URL Rewrite importado. Establece su Priority (por ejemplo, 10) y marca la opción Enabled.

Para verificar la corrección, regresa a la página Security Providers, expande el menú More y haz clic en Inspect Request. El Port debe estar vacío y Default debe estar marcado.

Uso de OAuth para autenticación externa

Como se mencionó anteriormente, OAuth es un protocolo de autorización, no de autenticación. Sin embargo, algunas implementaciones de proveedores extienden el protocolo OAuth para incluir autenticación. Típicamente, esto se hace publicando un endpoint que identifica al usuario. App Builder se refiere a tal endpoint como el Endpoint de Información del Usuario.

App Builder puede configurarse para consultar el Endpoint de Información del Usuario y recuperar la identidad del usuario. Esto permite usar un proveedor de seguridad OAuth para autenticación externa. Sin embargo, ten en cuenta que el endpoint debe cumplir con los siguientes requisitos:

• El endpoint debe ser accesible por App Builder.

• El endpoint debe responder a una solicitud HTTP GET que no incluya un cuerpo de solicitud.

• El endpoint debe respetar la autenticación de cliente OAuth Basic (como se describe arriba).

• La respuesta HTTP debe tener un código de estado 200.

• La respuesta HTTP debe incluir un cuerpo con un Content-Type de application/json.

• El documento JSON debe incluir una propiedad de nivel superior que identifique al usuario.

Después de adquirir el token de acceso, App Builder realizará una solicitud autenticada de cliente al Endpoint de Información del Usuario. App Builder analizará el cuerpo de la respuesta como JSON, tratando las propiedades de nivel superior como reclamaciones.

Por ejemplo, dada la siguiente respuesta de ejemplo:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "user_name": "arthur.dent",
    "name": "Arthur Dent",
    "email": "arthurdent@example.com"
}

Los siguientes tipos de reclamación estarán disponibles:

• user_name

• name

• email

Además de especificar el Endpoint de Información del Usuario, el desarrollador debe asignar la reclamación que identifica al usuario (en este caso, la reclamación user_name) al tipo de uso de reclamación Nombre.

Aserción portadora SAML 2.0

Al usar el flujo de Aserción Portadora SAML 2.0, las aserciones SAML pueden obtenerse de una de dos formas:

1. App Builder genera y firma las aserciones SAML bajo demanda. En este caso, App Builder actúa como el IdP.

2. (Obsoleto) un proveedor de identidad (IdP) de terceros emite una aserción SAML durante el proceso de inicio de sesión único (SSO) SAML. consulta el tipo de proveedor SAML para obtener más información.

Cada origen requiere configuración adicional.

Generar aserciones SAML bajo demanda

Para generar una aserción SAML bajo demanda, configura las propiedades de Token como se describe arriba. Además, la concesión de Aserción Portadora SAML 2.0 requiere un certificado de Firma con una clave privada.

Obtener aserciones SAML de un IdP

Para obtener aserciones SAML de un IdP de terceros, establece el parámetro SamlSingleSignOnProvider.

Limitaciones

• Los tipos de autenticación de cliente JWT no pueden usarse con la concesión JWT Bearer Token. Ambos usan un JWT, pero cada token tiene requisitos diferentes. El proveedor de seguridad OAuth admite configurar solo un único token JWT.