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 proveedores de 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 OAuth 2.0¶

El proveedor de seguridad de OAuth admite las siguientes concesiones de OAuth 2.0:

Código de autorización RFC 6749
Credenciales de cliente RFC 6749
Credenciales de contraseña del propietario del recurso RFC 6749
Afirmación de portador SAML 2.0 RFC 7522
Ficha al 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 del Código de autorización, Vinyl redirige el agente de usuario (navegador) al servidor de autorización. Una vez que el usuario ha iniciado sesión exitosamente y ha aprobado la solicitud de autorización, el servidor de autorización redirige al agente de usuario nuevamente a Vinyl. La redirección incluye un código de autorización. Vinyl realiza una solicitud de canal secundario al servidor de autorización, intercambiando el código de autorización por un token de acceso. Luego, el token de acceso se puede utilizar 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 se suelen utilizar 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 se puede utilizar como proveedor de autenticación externo. Consulte el * Extremo de información del usuario* para obtener detalles adicionales.

Credenciales de Cliente¶

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

NO DEBE utilizarse la concesión de credenciales de contraseña del propietario del recurso.

Tal como se concibió originalmente, la concesión de credenciales de contraseña de propietario de recursos 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.

Vinyl proporciona soporte parcial para la concesión de credenciales de contraseña de propietario de recursos OAuth 2.0. Vinyl no solicita al usuario su credencial. En cambio, se utiliza una única credencial para autorizar a todos los usuarios. De esta manera, la subvención equivale funcionalmente a una cuenta de servicio.

Afirmación de Portador de SAML 2.0¶

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

Token al 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 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 de cliente (client_id) y secreto del cliente (client secret)
extremo del token

Las concesiones individuales de OAuth requerirán una configuración adicional como se indica a continuación.

Autenticación¶

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

Tipo de autenticación: OAuth
Concesión de OAuth: seleccione una concesión de OAuth admitida.
Autenticación de cliente OAuth: determina el esquema de autenticación de cliente 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)
- Publicar: 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 solicitud de recursos. Las opciones incluyen:
- Portador - Esquema de autenticación de portador. Por defecto.
- Formulario: agregue el token de acceso al cuerpo del formulario codificado en URL.
- 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, Vinyl elimina el token almacenado cuando el usuario cierra sesión. Valor predeterminado: deshabilitado. Versión: 3.3.34523+.

Simbólico¶

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

Afirmación de portador SAML 2.0
Ficha al portador JWT

Afirmación de Portador de SAML 2.0¶

Emisor: El emisor de la aserció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 lo respetan. En consecuencia, Vinyl no requiere que la audiencia sea un URI.
Destinatario: el URI del destinatario de la aserción SAML (por ejemplo, http://example.com/service).

Token al Portador JWT¶

Emisor: reclamación del emisor JWT (https://tools.ietf.org/html/rfc7523#section-3). El valor predeterminado es el identificador del cliente (client_id).
Asunto: reclamo de asunto JWT (https://tools.ietf.org/html/rfc7523#section-3).
- Si el Propietario del token es Usuario, el valor predeterminado es la identidad del usuario actual.
- Si el Propietario del token es Cliente, el Asunto es obligatorio.
Audiencia: afirmación de audiencia de JWT (https://tools.ietf.org/html/rfc7523#section-3). El valor predeterminado es Extremo de token.

Extremos¶

Tipo	Subvenciones	Descripción
Punto final de autorización	Código de autorización	URL del extremo de autorización de OAuth 2.0. RFC 6749
Punto final del token	Todo	URL del extremo del token de OAuth 2.0. RFC 6749
Punto final de información de usuario	Código de autorización	Extremo que proporciona la identidad del usuario. Requerido cuando se trata 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.

Cartas Credenciales¶

Tipo	Subvenciones	Descripción
Cliente	Todo	Identificador de cliente OAuth 2.0 (`client_id`) y secreto (`client_secret`). RFC 6749
Propietario del recurso	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
Firma	Aserción de portador SAML 2.0 token de portador JWT	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. La concesión del 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	Ejemplo
BearerSchemeIdentifier	`Bearer`		`Authorization` esquema cuando se utiliza la autenticación de recursos Bearer.
Expira en		`3600`	Caducidad del token de acceso en segundos. Se puede utilizar si el extremo del token no proporciona una caducidad y el servidor de recursos no devuelve un `401 Unauthorized` respuesta cuando el token de acceso ha caducado.
IgnorarTlsErrors	`False`		Indica si Vinyl debe ignorar los errores de TLS al realizar solicitudes de canal secundario al extremo del token. Esto sólo debe usarse para desarrollo y pruebas.
Ámbitos			Lista delimitada por espacios en blanco de alcances de tokens de acceso de OAuth 2.0. RFC 6749
SingleUseAccessToken	`False`		Indica si el token de acceso solo se puede utilizar una vez.
Parámetros del Extremo del token			Parámetros pasados al extremo del token de OAuth. De forma predeterminada, Vinyl generará los parámetros apropiados según el flujo de OAuth. Utilice esta configuración únicamente para APIs de OAuth no conformes 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`). Si la lista de parámetros comienza con un signo comercial (&), 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 se sobrescribirá. Si un parámetro proporcionado no tiene un valor, p. `&grant_type&username=user&password=password`, se eliminará el parámetro generado. De lo contrario, el parámetro proporcionado se agrega 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={{ client_id}}&password={{ client_secret }}`. Esto resulta útil cuando se integra con APIs de externo que no utilizan nombres de parámetros estándar.

Código de Autorización¶

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

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

Afirmación de Portador de SAML 2.0¶

Las siguientes propiedades adicionales se aplican a la concesión de afirmación de portador de SAML 2.0.

Parámetro	Predeterminado	Ejemplo
SamlSingleSignOnProvider			Nombre de un proveedor de seguridad de Vinyl SAML. Este parámetro solo se aplica a la concesión de aserción de portador de SAML 2.0.

Token al Portador JWT¶

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

Parámetro	Predeterminado	Ejemplo
JwtClaimSet	`{ "scope": "{{ alcance }}" }`		Los servidores de autorización pueden requerir reclamos personalizados. Por ejemplo, Google requiere una notificación scope que coincida con el parámetro scope de OAuth. El parámetro JwtClaimSet permite a los administradores proporcionar reclamaciones 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` reclamación. `iss` -JWT `iss` reclamación. `aud` -JWT `aud` reclamación.
Algoritmo de firma	`RS256`		Parámetro del algoritmo JWT tal como se define en RFC 7518. El único algoritmo soportado es `RS256`.

DESCANSAR¶

Las siguientes propiedades adicionales se aplican cuando se utiliza el proveedor de seguridad OAuth para autenticar fuentes de datos REST. Estos se ignoran para los extremos 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 (aparecen en su propia línea).

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

Soporte de Protocolo¶

Actualizar Fichas¶

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

Código de Autorización¶

Solicitud de Autorización¶

Al elaborar una solicitud de autorización, Vinyl incluirá el identificador del cliente (client_id), secreto del cliente (client_secret) y alcances (scope). Además, Vinyl agregará automáticamente los siguientes parámetros estándar:

redirect_uri - El vinilo construye el redirect_uri parámetro de la URL actual. Toma el formato * https://example.com/Vinyl/signin-OAuth, donde *OAuth es el nombre del proveedor de seguridad de 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¶

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/Vinyl/signin-OAuth*

Donde * https://example.com/Vinyl* es la URL absoluta del directorio raíz de la aplicación Vinyl 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 terceros deberán configurarse con el extremo de redirección antes de autorizar cualquier solicitud.

Usar OAuth para Autenticación Externa¶

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

Vinyl 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:

Vinyl debe poder llegar al extremo.
El extremo debe responder a un HTTP GET Solicitud que no incluye un cuerpo de solicitud.
El extremo debe respetar la autenticación del cliente OAuth Básica (como se describe anteriormente).
La respuesta HTTP debe tener un 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, Vinyl realizará una solicitud autenticada del cliente al * Extremo de información del usuario*. Vinyl analizará el cuerpo de la respuesta como JSON y tratará 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"
}

Los siguientes tipos de reclamo 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 reclamo: al tipo de uso de reclamo *Nombre.

Afirmación de Portador de SAML 2.0¶

Cuando se utiliza el flujo de aserción de portador de SAML 2.0, las aserciones de SAML se pueden obtener de dos maneras:

Vinyl genera y firma las afirmaciones SAML a pedido. En cuyo caso, Vinyl actúa como IdP.
[DEPRECATED] Un proveedor de identidad (IdP) externo emite una aserció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.

Genere Aserciones SAML Bajo Demanda¶

Para generar una aserción SAML a pedido, configure las propiedades del Token como se describe anteriormente. Además, la concesión de Aserción de portador de 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 externo, establezca el parámetro SamlSingleSignOnProvider.