Saltar al contenido

Proveedor de seguridad OAuth en Jitterbit App Builder

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

  • DESCANSAR

  • OData

  • RDBMS (limitado a los proveedores CData compatibles)

Además, es posible configurar un proveedor de seguridad OAuth como proveedor de autenticación externo. Consulte más información a continuación.

Subvenciones 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 portador JWT RFC 7523.

Código de autorización

La concesión del código de autorización 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 al agente de usuario (navegador) al servidor de autorización. Una vez que el usuario inicia sesión correctamente y aprueba la solicitud de autorización, el servidor redirige al 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 secundario al servidor de autorización, intercambiando el código de autorización por un token de acceso. Este token de acceso puede utilizarse para autorizar solicitudes a servicios web.

OAuth, por sí mismo, proporciona autorización, no autenticación. Por lo tanto, los proveedores de seguridad de OAuth no suelen utilizarse como proveedores de autenticación externos, sino para autorizar solicitudes a un proveedor de datos compatible, como OData o REST. Sin embargo, si el proveedor de seguridad de OAuth publica un extremo que proporciona la identidad del usuario, puede utilizarse como proveedor de autenticación externo. Consulte el * Extremo de información del usuario* para obtener más información.

Credenciales del cliente

La concesión de credenciales de cliente de OAuth 2.0 proporciona autenticación a nivel de cliente, similar a una cuenta de servicio. En este flujo, las credenciales de cliente de OAuth se intercambian por un token de acceso de OAuth. La concesión de credenciales de 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 OAuth 2.0 se define en RFC 6749. Sin embargo, la subvención ha quedado obsoleta desde entonces.

Importante

Las credenciales de contraseña del propietario del recurso NO DEBEN utilizarse.

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. Este intercambia las credenciales por un token de acceso.

App Builder ofrece compatibilidad parcial con la concesión de credenciales de contraseña de propietario de recurso de OAuth 2.0. App Builder no solicita al usuario sus credenciales. En su lugar, se utiliza una sola credencial para autorizar a todos los usuarios. De esta forma, 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 origen de datos a nivel de usuario. En este flujo, las aserciones SAML se intercambian 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 portador JWT

La concesión del token de portador JWT de OAuth 2.0 proporciona autenticación de origen de datos a nivel de usuario. En este flujo, se intercambian tokens web JSON (JWT) por tokens de acceso de OAuth. La concesión del 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 del cliente (client_id) y secreto del cliente (client secret).

  • extremo del token.

Las concesiones OAuth individuales requerirán una configuración adicional como 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: Seleccione una concesión de OAuth compatible.

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

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

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

    • Publicación: Indica que se utilizará el esquema de contraseña del cliente. Las credenciales se proporcionarán como parámetros del 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:

- **Portador:** Esquema de autenticación del portador. Predeterminado.

- **Formulario:** Agrega el token de acceso al cuerpo codificado en la URL del formulario.

- **Consulta:** Agrega un token de acceso a la cadena de consultar.

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 del cliente.

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

Token

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

  • Afirmación de portador SAML 2.0.

  • Token portador JWT.

Aserción de portador SAML 2.0

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

  • Audiencia: La restricción de audiencia de la aserción SAML. Si bien la especificación SAML indica que la audiencia es una URI, muchas implementaciones no la respetan. Por lo tanto, App Builder no requiere que la audiencia sea una URI.

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

Token portador JWT

Extremos

Tipo Subvenciones Descripción
Authorization Endpoint Código de autorización URL del extremo de autorización de OAuth 2.0. RFC 6749
Token Endpoint Todo URL del extremo del token OAuth 2.0. RFC 6749
User Info Endpoint Código de autorización Extremo que proporciona la identidad del usuario. Obligatorio al tratar OAuth como proveedor de autenticación externo. No forma parte del estándar OAuth. El extremo debe devolver una respuesta JSON que incluya la identidad del usuario.

Credenciales

Tipo Subvenciones Descripción
Client Todos Identificador de cliente OAuth 2.0 (client_id) y secreto (client_secret). [RFC 6749(https://tools.ietf.org/html/rfc6749#section-2.2)
Resource Owner Credenciales de contraseña del propietario del recurso Nombre de usuario del propietario del recurso OAuth 2.0(username) y contraseña](password). RFC 6749

Certificados

Tipo Subvenciones Descripción
Signing Aserción de portador SAML 2.0 La concesión de aserción de portador SAML 2.0 requiere un certificado X.509 con clave privada en un contenedor PKCS#12 (.pfx) protegido con contraseña.
Token de portador JWT La concesión del token de portador JWT requiere una clave privada RSA PKCS#1 codificada con PEM (RSA PRIVATE KEY).

Propiedades

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

Parámetro Predeterminado
BearerSchemeIdentifier Bearer Authorization esquema al utilizar el Bearer autenticación de recursos.
ExpiresIn Caducidad del token de acceso en segundos. Se puede usar si el extremo del token no proporciona una fecha de caducidad y el servidor de recursos no devuelve una. 401 Unauthorized respuesta cuando el token de acceso ha expirado.
IgnoreTlsErrors False Indica si App Builder debe ignorar los errores TLS al realizar solicitudes de canal de retorno al extremo del token. Esto solo debe usarse para desarrollo y pruebas.
Scopes Lista delimitada por espacios en blanco de ámbitos de tokens de acceso de OAuth 2.0. RFC 6749
SingleUseAccessToken False Indica si el token de acceso solo se puede utilizar una vez.
Token Endpoint Parameters Parámetros transferidos al extremo del token de OAuth. De forma predeterminada, App Builder generará los parámetros adecuados según el flujo de OAuth. Utilice esta configuración solo para APIs de OAuth no compatibles o no compatibles. Los parámetros deben especificarse en [formato codificado de URL del formulario(https://www.w3.org/TR/html/sec-forms.html#urlencoded-form-data)(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, este se sobrescribirá. Si un parámetro proporcionado no tiene valor, p. ej. &grant_type&username=user&password=password el parámetro generado se eliminará. De lo contrario, el parámetro proporcionado se añadirá a los parámetros generados. La lista de parámetros admite la interpolación de cadenas. Las expresiones pueden hacer referencia a parámetros dinámicos, por ejemplo, .username={{ id_cliente }}&password={{secreto_del_cliente }}. Esto es útil al integrarse con APIs de externo que no usan nombres de parámetros estándar.
RefreshRequiresScopes False Indica si los ámbitos](scope) debe incluirse en el cuerpo de la solicitud enviada al extremo del token al actualizar el token de acceso.

Código de autorización

Las siguientes propiedades adicionales se aplican a la concesión del código de autorización.

Parámetro Predeterminado
BackchannelAuthorization False Indica si se puede obtener un código de autorización mediante una solicitud de canal secundario (de servidor a servidor). Esta es una extensión no estándar de la concesión del 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.

Parámetro
SamlSingleSignOnProvider Nombre de un proveedor de seguridad SAML de App Builder. Este parámetro solo se aplica 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 del token de portador JWT.

Parámetro Predeterminado
JwtClaimSet { "scope": "{{ alcance }}" } Los servidores de autorización pueden requerir notificaciones personalizadas. Por ejemplo, Google requiere una scope Reclamación que coincide con OAuth scope parámetro. El JwtClaimSet Este parámetro permite a los administradores proporcionar notificaciones adicionales. El valor se presenta como una modelo JSON. Se pueden sustituir los siguientes valores en la modelo:
  • client_id- OAuth
  • client_id parámetro.
  • client_secret- OAuth client_secret parámetro.
  • scope- OAuth scope parámetro.
  • sub- JWT sub reclamación.
  • iss- JWT iss reclamación.
  • aud- JWT aud reclamación.
SigningAlgorithm RS256 Parámetro del algoritmo JWT tal como se define en RFC 7518. El único algoritmo compatible es RS256.

Descansar

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

Parámetro Predeterminado Ejemplo
RequestHeaders X-Custom-Header: Value X-Another-Header: Value Encabezados HTTP personalizados que se añaden a las solicitudes de extremo REST. Los encabezados deben tener el formato RFC 7230 No se admite el plegado de líneas.

Compatibilidad con protocolos

Tokens de actualización

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

Código de autorización

Solicitud de autorización

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

  • redirect_uri: App Builder construye el redirect_uri Parámetro de la URL actual. Tiene la forma https://example.com/AppBuilder/signin-OAuth, donde OAuth es el nombre del proveedor de seguridad OAuth.

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

Extremo de redirección

Según se define en RFC 6749, la concesión del código de autorización expone un Extremo de redirección. Este extremo recibe respuestas de autorización en la dirección:

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

Dónde https://example.com/AppBuilder es la URL absoluta al directorio raíz de la aplicación App Builder y OAuth es el nombre codificado en URL y que distingue entre mayúsculas y minúsculas del proveedor de seguridad.

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

Uso de OAuth para la autenticación externa

Como se mencionó anteriormente, OAuth es un protocolo de autorización, no de autenticación. Sin embargo, algunas implementaciones de proveedores amplían el protocolo OAuth para incluir la autenticación. Normalmente, esto se logra mediante la publicación de un extremo que identifica al usuario. App Builder se refiere a dicho extremo como * Extremo de información del usuario*.

App Builder puede configurarse para consultar el * Extremo de información del usuario* y recuperar la identidad del usuario. Esto permite utilizar un proveedor de seguridad OAuth para la autenticación externa. Sin embargo, tenga en cuenta que el extremo debe cumplir los siguientes requisitos:

  • El extremo debe ser accesible para App Builder.

  • El extremo debe responder a un HTTP GET solicitud que no incluye un cuerpo de solicitud.

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

  • La respuesta HTTP debe tener una 200 Código de estado.

  • 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.

Tras obtener el token de acceso, App Builder realizará una solicitud autenticada por el cliente al * Extremo de información del usuario*. App Builder analizará el cuerpo de la respuesta como JSON y tratará las propiedades de nivel superior como notificaciones.

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 reclamaciones estarán disponibles:

  • user_name
  • name
  • email

Además de especificar el * Extremo de información del usuario, el desarrollador debe asignar el reclamo que identifica al usuario; en este caso, el user_name Reclamación: tipo de uso de la reclamación *Nombre.

Aserción de portador SAML 2.0

Al utilizar el flujo de aserción de portador SAML 2.0, las aserciones SAML se pueden obtener de una de dos maneras:

  1. App Builder genera y firma las aserciones SAML bajo demanda. En ese caso, App Builder actúa como proveedor de identidad (IdP).

  2. (Obsoleto) Un proveedor de identidad (IdP) de externo emite una afirmación SAML durante el proceso de inicio de sesión único (SSO) SAML. Consulte Tipo de proveedor SAML para más información.

Cada fuente requiere configuración adicional.

Generar afirmaciones SAML a pedido

Para generar una aserción SAML bajo demanda, configure las propiedades Token como se describe anteriormente. Además, la concesión de aserción de portador SAML 2.0 requiere un certificado de firma con una clave privada.

Obtener afirmaciones SAML de un IdP

Para obtener afirmaciones SAML de un IdP de externo, configure el parámetro SamlSingleSignOnProvider.