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.

Importante

La concesión de credenciales de contraseña del propietario del recurso NO DEBE 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. 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

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`	Todos	URL de extremo del token OAuth 2.0. RFC 6749
`User Info Endpoint`	Código de autorización	Extremo que proporciona la identidad del usuario. Obligatorio cuando se trata a OAuth como un 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
`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.
`Signing`	Token portador JWT	La concesión del token 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.`TABLEROWEND`
`ExpiresIn`		Vencimiento del token de acceso en segundos. Se puede utilizar si el extremo del token no proporciona un vencimiento y el servidor de recursos no devuelve un `401 Unauthorized`respuesta cuando el token de acceso ha expirado.
`IgnoreTlsErrors`	`False`	Indica si App Builder debe ignorar los errores de 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 que se pasan al extremo del token 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 admitidas. Los parámetros deben especificarse en formato codificado de URL del formulario (`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, se sobrescribirá el parámetro generado. Si un parámetro proporcionado no tiene un valor, p. ej. `&grant_type&username=user&password=password`, se eliminará el parámetro generado. De lo contrario, el parámetro suministrado se agregará 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, p. ej. `username={{ id_cliente }}&password={{secreto_cliente }}`. Esto es útil cuando se integra con APIs de externo que no utilizan 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	Valor predeterminado
`BackchannelAuthorization`	`False`	Indica si se puede obtener un código de autorización a través de 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 an App Builder proveedor de seguridad SAML. 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	Valor predeterminado
`JwtClaimSet`	`{ "scope": "{{ alcance }}" }`	Los servidores de autorización pueden requerir reclamos personalizados. Por ejemplo, Google requiere un `scope` reclamación que coincide con OAuth `scope` parámetro. El `JwtClaimSet` el parámetro permite a los administradores proporcionar notificaciones adicionales. El valor toma la forma de una modelo JSON. Los siguientes valores pueden sustituirse 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` reclamar. `iss`- JWT `iss` reclamar. `aud`- JWT `aud` reclamar.
`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, incluidos 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 agregan a las solicitudes de extremo REST. Los encabezados deben tener el formato 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 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:

App Builder genera y firma las afirmaciones SAML a pedido. En cuyo caso, App Builder actúa como IdP.
(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.