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 las solicitudes de servicios web. Los siguientes tipos de fuentes de datos son compatibles con 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 Portadora de SAML 2.0 RFC 7522.

• Token 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 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 de autorización redirige el agente de usuario nuevamente 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. Después, el token de acceso se puede usar 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 suelen usar como proveedores de autenticación externos: se usan 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, se puede usar 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 de 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 obsoleta.

Según 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 usa 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 portadora de SAML 2.0

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

Token portador JWT

La concesión de Token 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 de OAuth. La concesión de Token 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).

• Endpoint de token.

Las concesiones individuales de OAuth 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 Section 2.3. Las opciones incluyen:

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

  • Client Secret JWT: El cliente se autentica mediante un JSON Web Token (JWT) firmado con el secreto del cliente (client_secret_jwt). (Consulta Tipos de autenticación de cliente JWT.)

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

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

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

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

  • Bearer: Esquema de autenticación Bearer. Predeterminado.

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

  • Query: 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:

  • User: Los tokens se emiten a usuarios individuales.

  • Client: Los tokens se emiten al sistema cliente.

• Eliminar token al cerrar sesión: Cuando se habilita, 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:

• Assertion:

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

  • Audience: Por defecto, el endpoint de token (como se define en el panel Endpoints) según lo estándar.

  • Subject: Por defecto, el ID de cliente (como se especifica en el panel Credentials) según lo estándar.

• Credentials:

  • Type: Client

    Se requiere Client ID. Se ignora Client Secret y se puede omitir.

• Certificates:

  • Usage: Signing

    Un certificado solo lo utiliza el tipo de autenticación de cliente Private Key JWT. Client Secret JWT utiliza el secreto del cliente como clave.

• Properties:

  • Parameter: JwtClaimSet

  • Parameter: SigningAlgorithm

Token

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

• SAML 2.0 Bearer Assertion.

• JWT Bearer Token.

SAML 2.0 bearer assertion

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

• Audience: 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 lo respetan. En consecuencia, App Builder no requiere que la audiencia sea un URI.

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

JWT bearer token

• Issuer: Reclamo del emisor JWT (https://tools.ietf.org/html/rfc7523#section-3). Por defecto, el identificador de cliente (client_id).

• Subject: Reclamo del asunto JWT (https://tools.ietf.org/html/rfc7523#section-3).

• Si el Propietario del Token es Usuario, usa por defecto 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). Por defecto es el Punto Final de Token.

Puntos Finales

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 de portador JWT

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

Rest

Las siguientes propiedades adicionales se aplican cuando se utiliza el proveedor de seguridad OAuth para autenticar orígenes de datos REST. Se ignoran para puntos finales OAuth y otros tipos de orígenes de datos, incluyendo OData y RDBMS.
Los encabezados de solicitud deben separarse mediante un retorno de carro (aparecen 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 usar 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 incluye el identificador del cliente (client_id), el secreto del cliente (client_secret) y los ámbitos (scope). Además, App Builder añade 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 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 mayúsculas de minúsculas del proveedor de seguridad. Cualquier carácter especial debe estar codificado en URL.

La mayoría de las aplicaciones de terceros necesitará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 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. Ve a IDE > Security Providers.
2. En el panel Security Providers, 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. Vuelve a la página Security. En el panel Security Providers, 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, vuelve a la página Security, expande el menú More del panel Configuration y haz clic en Inspect Request. Port debe estar vacío y Default debe estar marcado.

Usar 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 logra 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 utilizar 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 desde App Builder.

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

• El endpoint debe admitir autenticación de cliente OAuth Basic (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 obtener 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"
}

Estarán disponibles los siguientes tipos de reclamación:

• user_name

• name

• email

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

Aserción portadora SAML 2.0

Cuando se utiliza el flujo de Aserción Portadora SAML 2.0, las aserciones SAML pueden provenir 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 fuente requiere configuración adicional.

Generar aserciones SAML bajo demanda

Para generar una aserción SAML bajo demanda, configura las propiedades de Token como se describió anteriormente. 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 de Token Portador JWT. Ambos utilizan un JWT, pero cada token tiene requisitos diferentes. El proveedor de seguridad OAuth admite la configuración de solo un único token JWT.