Saltar al contenido

Proveedor de seguridad OAuth en Jitterbit App Builder

El proveedor de seguridad OAuth habilita el soporte para OAuth 2.0. El proveedor de seguridad es responsable de autorizar solicitudes de servicios web. Los siguientes tipos de fuentes de datos son compatibles con OAuth:

  • REST

  • OData

  • RDBMS (limitado a los proveedores de CData compatibles)

Además, es posible configurar un proveedor de seguridad OAuth como un proveedor de autenticación externo. Consulte 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.

  • Afirmació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 está definida 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 con éxito y ha 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 de canal de retorno al servidor de autorización, intercambiando el código de autorización por un token de acceso. El token de acceso puede ser utilizado para autorizar solicitudes a servicios web.

En sí mismo, 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 final que proporciona la identidad del usuario, el proveedor de seguridad OAuth puede ser utilizado como un proveedor de autenticación externo. Consulte el Punto final de información del usuario para obtener detalles adicionales.

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, las credenciales del cliente de OAuth se intercambian por un token de acceso de OAuth. La concesión de Credenciales del Cliente está definida 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 está definida en RFC 6749. Sin embargo, la concesión ha sido desaprobada.

Importante

La concesión de credenciales de contraseña del propietario del recurso NO DEBE ser utilizada.

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 soporte parcial para 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.

Afirmación portadora SAML 2.0

La concesión de Afirmación Portadora SAML 2.0 de OAuth 2.0 proporciona autenticación a nivel de usuario y de fuente de datos. En este flujo, las afirmaciones SAML se intercambian por tokens de acceso de OAuth. La concesión de Afirmación Portadora SAML 2.0 de OAuth 2.0 está definida en RFC 7522.

Token portador JWT

La concesión de Token Portador JWT de OAuth 2.0 proporciona autenticación a nivel de usuario y de fuente de datos. En este flujo, los JSON Web Tokens (JWT) se intercambian por tokens de acceso de OAuth. La concesión de Token Portador JWT de OAuth 2.0 está definida en RFC 7523.

Configuración

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

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

  • Endpoint de token.

Los permisos individuales de OAuth requerirán configuración adicional como se indica a continuación.

Autenticación

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

  • Tipo de Autenticación: OAuth

  • Concesión de OAuth: Seleccione una concesión de OAuth soportada.

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

    • Ninguna: Indica que el cliente no debe ser autenticado. (none.)

    • Básica: Indica que se utilizará el esquema de Contraseña del Cliente. Las credenciales se proporcionarán utilizando la autenticación básica HTTP. (client_secret_basic.)

    • Post: Indica que se utilizará el esquema de Contraseña del Cliente. Las credenciales se proporcionarán como parámetros de formulario en el cuerpo de la solicitud. (client_secret_post.)

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

    • Bearer: Esquema de autenticación Bearer. Por defecto.

    • Formulario: Adjuntar el token de acceso al cuerpo codificado en URL del formulario.

    • Consulta: Adjuntar 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. Por defecto: Deshabilitado.

Token

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

  • Afirmación Bearer SAML 2.0.

  • Token Bearer JWT.

Afirmación Bearer SAML 2.0

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

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

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

Token portador JWT

Endpoints

Tipo Concesiones Descripción
Endpoint de Autorización Código de Autorización URL del endpoint de autorización OAuth 2.0. RFC 6749
Endpoint de Token Todos URL del endpoint de token OAuth 2.0. RFC 6749
Endpoint de Información del Usuario Código de Autorización Endpoint que proporciona la identidad del usuario. Requerido al tratar OAuth como un proveedor de autenticación externo. No forma parte del estándar OAuth. El endpoint debe devolver una respuesta JSON que incluya la identidad del usuario.

Credenciales

Tipo Concesiones Descripción
Cliente Todas Identificador de cliente OAuth 2.0 (client_id) y secreto (client_secret). RFC 6749
Propietario de Recurso Credenciales de Contraseña del Propietario de Recurso Nombre de usuario (username) y contraseña (password) del propietario de recurso OAuth 2.0. RFC 6749

Certificados

Tipo Concesiones Descripción
Firma Afirmación de Portador SAML 2.0 La concesión de Afirmación de Portador SAML 2.0 requiere un certificado X.509 con clave privada en un contenedor PKCS#12 (.pfx) protegido por contraseña.
Token de Portador JWT La concesión de Token de Portador JWT requiere una clave privada RSA PKCS#1 codificada en PEM (RSA PRIVATE KEY).

Propiedades

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

Parámetro Predeterminado
BearerSchemeIdentifier Bearer Esquema de Authorization al usar la autenticación de recurso Bearer.
ExpiresIn Expiración del token de acceso en segundos. Se puede usar si el punto final del token no proporciona una expiración y el servidor de recursos no devuelve una respuesta 401 Unauthorized cuando el token de acceso ha expirado.
IgnoreTlsErrors False Indica si el App Builder debe ignorar errores de TLS al realizar solicitudes de canal trasero al punto final del token. Esto solo debe usarse para desarrollo y pruebas.
Scopes Lista de ámbitos de token de acceso OAuth 2.0 delimitada por espacios en blanco. RFC 6749
SingleUseAccessToken False Indica si el token de acceso solo se puede usar una vez.
Token Endpoint Parameters Parámetros pasados al punto final del token OAuth. Por defecto, el App Builder generará los parámetros apropiados según el flujo OAuth. Solo use esta configuración para APIs OAuth no conformes o de otro modo no soportadas. Los parámetros deben especificarse en formato URL codificado (application/x-www-form-urlencoded). Si la lista de parámetros comienza con un ampersand (&), los parámetros se fusionarán con los parámetros generados. Si un parámetro tiene el mismo nombre que un parámetro generado, el parámetro generado será sobrescrito. Si un parámetro suministrado no tiene un valor, por ejemplo, &grant_type&username=user&password=password, el parámetro generado será eliminado. De lo contrario, el parámetro suministrado se añadirá a los parámetros generados. La lista de parámetros admite interpolación de cadenas. Las expresiones pueden hacer referencia a parámetros dinámicos, por ejemplo username={{ client_id }}&password={{ client_secret }}. Esto es útil al integrarse con APIs de terceros que no utilizan nombres de parámetros estándar.
RefreshRequiresScopes False Indica si los ámbitos (scope) deben incluirse en el cuerpo de la solicitud enviada al punto final del token al actualizar el token de acceso.

Código de autorización

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

Parámetro Predeterminado
BackchannelAuthorization False Indica si se puede adquirir un código de autorización a través de una solicitud de backchannel (servidor a servidor). Esta es una extensión no estándar a la concesión de Código de Autorización.

Afirmación portadora SAML 2.0

Las siguientes propiedades adicionales se aplican a la concesión de Afirmación Portadora SAML 2.0.

Parámetro
SamlSingleSignOnProvider Nombre de un proveedor de seguridad SAML de App Builder. Este parámetro solo se aplica a la concesión de Afirmación Portadora SAML 2.0.

Token portador JWT

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

Parámetro Predeterminado
JwtClaimSet { "scope": "{{ scope }}" } Los servidores de autorización pueden requerir reclamos personalizados. Por ejemplo, Google requiere un reclamo scope que coincida con el parámetro scope de OAuth. El parámetro JwtClaimSet permite a los administradores proporcionar reclamos adicionales. El valor toma la forma de una plantilla JSON. Los siguientes valores pueden ser sustituidos en la plantilla:
  • client_id - OAuth
  • parámetro client_id.
  • client_secret - parámetro client_secret de OAuth.
  • scope - parámetro scope de OAuth.
  • sub - reclamo sub de JWT.
  • iss - reclamo iss de JWT.
  • aud - reclamo aud de JWT.
SigningAlgorithm RS256 Parámetro de algoritmo JWT según se define en RFC 7518. El único algoritmo soportado es RS256.

Rest

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

Parámetro Predeterminado Ejemplo
RequestHeaders X-Custom-Header: Value X-Another-Header: Value Encabezados HTTP personalizados añadidos a las solicitudes de puntos finales REST. Los encabezados deben estar formateados de acuerdo con RFC 7230. No se admite el plegado de líneas.

Soporte de protocolo

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 nombre del proveedor de seguridad OAuth.

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

Redirection endpoint

Como se define en RFC 6749, el flujo de autorización de Código de Autorización expone un Endpoint de Redirección. Este endpoint 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 del directorio raíz de la aplicación App Builder y OAuth es el nombre del proveedor de seguridad, codificado en URL y sensible a mayúsculas.

La mayoría de las aplicaciones de terceros necesitarán ser configuradas con el endpoint de redirección antes de autorizar cualquier solicitud.

Using OAuth for external authentication

Como se mencionó anteriormente, OAuth es un protocolo de autorización, no un protocolo 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 User Info Endpoint.

App Builder puede ser configurado para consultar el User Info Endpoint para recuperar la identidad del usuario. Esto permite que un proveedor de seguridad OAuth sea utilizado para autenticación externa. Sin embargo, se debe tener 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 Basic de OAuth (como se describió anteriormente).

  • 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 User Info Endpoint. App Builder analizará el cuerpo de la respuesta como JSON, tratando las propiedades de nivel superior como afirmaciones.

Por ejemplo, dada la siguiente respuesta de muestra:

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

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

Los siguientes tipos de afirmaciones estarán disponibles:

  • user_name

  • name

  • email

Además de especificar el User Info Endpoint, el desarrollador debe mapear el reclamo que identifica al usuario—en este caso, el reclamo user_name—al tipo de uso del reclamo Name.

SAML 2.0 bearer assertion

Al utilizar el flujo de SAML 2.0 Bearer Assertion, las afirmaciones SAML pueden obtenerse de una de dos maneras:

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

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

Cada fuente requiere configuración adicional.

Generate SAML assertions on-demand

Para generar una afirmación SAML bajo demanda, configure las propiedades del Token como se describió anteriormente. Además, la concesión de SAML 2.0 Bearer Assertion requiere un certificado de Signing con una clave privada.

Source SAML assertions from an IdP

Para obtener afirmaciones SAML de un IdP de terceros, establezca el parámetro SamlSingleSignOnProvider.