Proveedor de Seguridad: OAuth¶

El proveedor de seguridad de OAuth permite 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 admiten 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 a continuación para obtener información adicional.

Subvenciones de OAuth 2.0¶

El proveedor de seguridad OAuth admite las siguientes concesiones 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 una autorización delegada a nivel de usuario. Esta concesión se define en RFC 6749.

En el flujo del Código de Autorización, App Builder redirecciona al agente de usuario (navegador) al servidor de autorización. Una vez que el usuario ha iniciado sesión correctamente y ha aprobado la solicitud de autorización, el servidor de autorización redirige al agente de usuario de nuevo 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. El token de acceso puede utilizarse para autorizar solicitudes a servicios web.

En sí mismo, OAuth proporciona autorización, no autenticación. Por lo tanto, los proveedores de seguridad de OAuth no suelen utilizarse 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 de OAuth publica un extremo que proporciona la identidad del usuario, el proveedor de seguridad de OAuth puede utilizarse como proveedor de autenticación externo. Consulte el * Extremo de información del usuario* para obtener más detalles.

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.

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 de propietario de recurso OAuth 2.0. App Builder no se solicita al usuario su credencial, sino que 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, las aserciones SAML se intercambian por tokens de acceso de 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 de token de portador JWT de OAuth 2.0 proporciona autenticación de fuente de datos a nivel de usuario. En este flujo, los tokens web JSON (JWT) se intercambian por tokens de acceso de 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 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 ser autenticado. (none.)

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

  • Publicación: 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:

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

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

  • Consulta: Agrega el 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.

Ficha¶

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

• Aserció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. Aunque la especificación SAML indica que la audiencia es una URI, muchas implementaciones no respetan esto. En consecuencia, 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¶

• Emisor: Reclamo del emisor de JWT (https://tools.ietf.org/html/rfc7523#section-3). El valor predeterminado es el identificador del cliente (client_id).

• Asunto: Reclamo de sujeto de JWT (https://tools.ietf.org/html/rfc7523#section-3).

  • Si el Propietario del token es Usuario, se toma como valor predeterminado la identidad del usuario actual.

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

• Audiencia: Reclamo de audiencia de JWT (https://tools.ietf.org/html/rfc7523#section-3). El valor predeterminado es el Extremo del token.

Extremos¶

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

Token Portador JWT¶

Las siguientes propiedades adicionales se aplican a la concesión del token de portador JWT.

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, incluidos OData y RDBMS.
Los encabezados de solicitud deben estar separados por un retorno de carro (aparecen en su propia línea).

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 usar el token de actualización para adquirir un nuevo token de acceso después de recibir un 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 agregará 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 opaca y cifrada. Incluye un token de falsificación de solicitud entre sitios (CSRF) según RFC 6749.

Extremo de Redirección¶

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

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

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

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 Autenticación Externa¶

Como se indicó 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. Por lo general, esto se hace publicando un extremo que identifica al usuario. App Builder se refiere a un extremo llamado * Extremo de información del usuario*.

App Builder se puede configurar para consultar el * Extremo de información del usuario* para 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.

Después de adquirir el token de acceso, App Builder realizará una solicitud autenticada del 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 reclamos.

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"
}

Estarán disponibles los siguientes tipos de reclamaciones:

• 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 reclamo–al tipo de uso de reclamo *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 afirmaciones SAML a pedido. En cuyo caso, App Builder actúa como IdP.

2. (En desuso) 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 obtener más información.

Cada fuente requiere una configuración adicional.

Generar Afirmaciones SAML a Pedido¶

Para generar una aserción SAML a pedido, configure las propiedades Token como se describe anteriormente. Además, la concesión de aserción de portador SAML 2.0 requiere un certificado 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.