Provedor de segurança OAuth no Jitterbit App Builder

O provedor de segurança OAuth habilita o suporte para OAuth 2.0. O provedor de segurança é responsável por autorizar solicitações de serviços web. Os seguintes tipos de fonte de dados suportam OAuth:

• REST

• OData

• RDBMS (limitado aos provedores CData suportados)

Além disso, é possível configurar um provedor de segurança OAuth como um provedor de autenticação externo. Veja abaixo para mais informações.

Concessões OAuth 2.0

O provedor de segurança OAuth suporta as seguintes concessões OAuth 2.0:

• Código de Autorização RFC 6749.

• Credenciais do Cliente RFC 6749.

• Credenciais de Senha do Proprietário do Recurso RFC 6749.

• Aserção Bearer SAML 2.0 RFC 7522.

• Token Bearer JWT RFC 7523.

Código de autorização

A concessão de Código de Autorização OAuth 2.0 fornece autorização delegada em nível de usuário. Esta concessão é definida na RFC 6749.

No fluxo de Código de Autorização, o App Builder redireciona o agente do usuário (navegador) para o servidor de autorização. Uma vez que o usuário tenha feito login com sucesso e aprovado a solicitação de autorização, o servidor de autorização redireciona o agente do usuário de volta para o App Builder. O redirecionamento inclui um código de autorização. O App Builder faz uma solicitação de canal reverso ao servidor de autorização, trocando o código de autorização por um token de acesso. O token de acesso pode então ser usado para autorizar solicitações a serviços web.

Por si só, o OAuth fornece autorização, não autenticação. Portanto, os provedores de segurança OAuth não são tipicamente usados como provedores de autenticação externos: eles são usados para autorizar solicitações a um provedor de dados compatível, como OData ou REST. No entanto, se o provedor de segurança OAuth publicar um endpoint que forneça a identidade do usuário, o provedor de segurança OAuth pode ser usado como um provedor de autenticação externo. Veja o Endpoint de Informações do Usuário para mais detalhes.

Credenciais do cliente

A concessão de Credenciais do Cliente do OAuth 2.0 fornece autenticação em nível de cliente, semelhante a uma conta de serviço. Neste fluxo, as credenciais do cliente OAuth são trocadas por um token de acesso OAuth. A concessão de Credenciais do Cliente é definida na RFC 6749.

Credenciais de senha do proprietário do recurso

A concessão de Credenciais de Senha do Proprietário do Recurso do OAuth 2.0 é definida na RFC 6749. No entanto, a concessão foi descontinuada.

Conforme concebido originalmente, a concessão de Credenciais de Senha do Proprietário do Recurso do OAuth 2.0 fornece autorização em nível de usuário. O usuário fornece seu nome de usuário e senha a um cliente confiável. O cliente confiável troca as credenciais por um token de acesso.

O App Builder oferece suporte parcial para a concessão de Credenciais de Senha do Proprietário do Recurso do OAuth 2.0. O App Builder não solicita ao usuário suas credenciais. Em vez disso, uma única credencial é usada para autorizar todos os usuários. Dessa forma, a concessão é funcionalmente equivalente a uma conta de serviço.

Aserção portadora SAML 2.0

A concessão de Aserção Portadora SAML 2.0 do OAuth 2.0 fornece autenticação em nível de usuário e fonte de dados. Neste fluxo, as asserções SAML são trocadas por tokens de acesso OAuth. A concessão de Aserção Portadora SAML 2.0 do OAuth 2.0 é definida na RFC 7522.

Token portador JWT

A concessão de Token Portador JWT do OAuth 2.0 fornece autenticação em nível de usuário e fonte de dados. Neste fluxo, Tokens Web JSON (JWTs) são trocados por tokens de acesso OAuth. A concessão de Token Portador JWT do OAuth 2.0 é definida na RFC 7523.

Configuração

A configuração varia com base na concessão do OAuth. No mínimo, o OAuth requer:

• Identificador do cliente (client_id) e segredo do cliente (client secret).

• Endpoint do token.

Concessões individuais de OAuth exigirão configuração adicional, conforme indicado abaixo.

Autenticação

As propriedades de autenticação determinam a concessão de OAuth e os esquemas de autenticação.

• Tipo de Autenticação: OAuth

• Concessão de OAuth: Selecione uma concessão de OAuth suportada.

• Autenticação do Cliente OAuth: Determina o esquema de autenticação do cliente OAuth 2.0 RFC 6749 Seção 2.3. As opções incluem:

  • Nenhum: Indica que o cliente não deve ser autenticado. (none.)

  • Básico: Indica que o esquema de Senha do Cliente será usado. As credenciais serão fornecidas usando autenticação HTTP Básica. (client_secret_basic.)

  • Post: Indica que o esquema de Senha do Cliente será usado. As credenciais serão fornecidas como parâmetros de formulário no corpo da solicitação. (client_secret_post.)

• Autenticação de Recurso OAuth: Determina o esquema de autenticação da solicitação de recurso. As opções incluem:

  • Bearer: Esquema de autenticação Bearer. Padrão.

  • Formulário: Anexa o token de acesso ao corpo codificado em URL do formulário.

  • Consulta: Anexa o token de acesso à string de consulta.

• Proprietário do Token: Determina se os tokens são emitidos para usuários individuais ou para o sistema cliente. As opções incluem:

  • Usuário: Tokens são emitidos para usuários individuais.

  • Cliente: Tokens são emitidos para o sistema cliente.

• Excluir Token ao Sair: Quando ativado, o App Builder exclui o token armazenado quando o usuário faz logout. Padrão: Desativado.

Token

As seguintes concessões geram tokens que são trocados por tokens de acesso OAuth:

• Aserção Bearer SAML 2.0.

• Token Bearer JWT.

Aserção bearer SAML 2.0

• Emissor: O emissor da asserção SAML.

• Público: A restrição de público da asserção SAML. Embora a especificação SAML indique que o público é uma URI, muitas implementações não respeitam isso. Consequentemente, o App Builder não exige que o público seja uma URI.

• Destinatário: O URI do destinatário da asserção SAML (por exemplo, http://example.com/service).

Token portador JWT

• Emissor: Reivindicação do emissor JWT (https://tools.ietf.org/html/rfc7523#section-3). O padrão é o identificador do cliente (client_id).

• Sujeito: Reivindicação do sujeito JWT (https://tools.ietf.org/html/rfc7523#section-3).

  • Se o Proprietário do Token for Usuário, o padrão é a identidade do usuário atual.

  • Se o Proprietário do Token for Cliente, o Sujeito é obrigatório.

• Público: Reivindicação do público JWT (https://tools.ietf.org/html/rfc7523#section-3). O padrão é o Endpoint do Token.

Endpoints

Credenciais

Certificados

Propriedades

O provedor de segurança OAuth suporta os seguintes parâmetros adicionais:

Código de autorização

As seguintes propriedades adicionais se aplicam ao fluxo de Código de Autorização.

Aserção portadora SAML 2.0

As seguintes propriedades adicionais se aplicam ao fluxo de Aserção Portadora SAML 2.0.

Token portador JWT

As seguintes propriedades adicionais se aplicam ao fluxo de Token Portador JWT.

Rest

As seguintes propriedades adicionais se aplicam quando o provedor de segurança OAuth é usado para autenticar fontes de dados REST. Estas são ignoradas para endpoints OAuth e outros tipos de fontes de dados, incluindo OData e RDBMS.
Os cabeçalhos de solicitação devem ser separados por um retorno de carro (aparecer em sua própria linha).

Suporte a protocolo

Tokens de atualização

Se a solicitação de token de acesso incluir um token de atualização, o App Builder tentará automaticamente usar o token de atualização para adquirir um novo token de acesso após receber uma resposta 401 Unauthorized.

Código de autorização

Solicitação de autorização

Ao construir uma solicitação de autorização, o App Builder incluirá o identificador do cliente (client_id), o segredo do cliente (client_secret) e os escopos (scope). Além disso, o App Builder anexará automaticamente os seguintes parâmetros padrão:

• redirect_uri: O App Builder constrói o parâmetro redirect_uri a partir da URL atual. Ele assume a forma https://example.com/Vinyl/signin-OAuth, onde OAuth é o nome do provedor de segurança OAuth.

• state: O parâmetro de estado é uma carga útil opaca e criptografada. Ele inclui um token de Cross-Site Request Forgery (CSRF) conforme RFC 6749.

Redirection endpoint

Conforme definido no RFC 6749, o fluxo de autorização com Código de Autorização expõe um Endpoint de Redirecionamento. Este endpoint escuta as respostas de autorização no endereço:

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

Onde https://example.com/Vinyl é a URL absoluta do diretório raiz da aplicação App Builder e OAuth é o nome do provedor de segurança, sensível a maiúsculas e minúsculas, codificado em URL.

A maioria das aplicações de terceiros precisará ser configurada com o endpoint de redirecionamento antes de autorizar qualquer solicitação.

Using OAuth for external authentication

Como mencionado acima, OAuth é um protocolo de autorização, não um protocolo de autenticação. No entanto, algumas implementações de fornecedores estendem o protocolo OAuth para incluir autenticação. Normalmente, isso é feito publicando um endpoint que identifica o usuário. O App Builder se refere a tal endpoint como User Info Endpoint.

O App Builder pode ser configurado para consultar o User Info Endpoint para recuperar a identidade do usuário. Isso permite que um provedor de segurança OAuth seja usado para autenticação externa. No entanto, observe que o endpoint deve atender aos seguintes requisitos:

• O endpoint deve ser acessível pelo App Builder.

• O endpoint deve responder a uma solicitação HTTP GET que não inclua um corpo de solicitação.

• O endpoint deve respeitar a autenticação de cliente Basic do OAuth (conforme descrito acima).

• A resposta HTTP deve ter um código de status 200.

• A resposta HTTP deve incluir um corpo com um Content-Type de application/json.

• O documento JSON deve incluir uma propriedade de nível superior que identifique o usuário.

Após adquirir o token de acesso, o App Builder fará uma solicitação autenticada pelo cliente ao User Info Endpoint. O App Builder analisará o corpo da resposta como JSON, tratando as propriedades de nível superior como declarações.

Por exemplo, dada a seguinte resposta de amostra:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "user_name": "arthur.dent",
    "name": "Arthur Dent",
    "email": "arthurdent@example.com"
}

Os seguintes tipos de declarações estarão disponíveis:

• user_name

• name

• email

Além de especificar o Endpoint de Informações do Usuário, o desenvolvedor deve mapear a reivindicação que identifica o usuário – neste caso, a reivindicação user_name – para o tipo de uso da reivindicação Nome.

SAML 2.0 bearer assertion

Ao usar o fluxo de Bearer Assertion do SAML 2.0, as afirmações SAML podem ser obtidas de duas maneiras:

1. O App Builder gera e assina as afirmações SAML sob demanda. Nesse caso, o App Builder atua como o IdP.

2. (Obsoleto) um provedor de identidade de terceiros (IdP) emite uma afirmação SAML durante o processo de single sign-on (SSO) do SAML. Veja o tipo de provedor SAML para mais informações.

Cada fonte requer configuração adicional.

Generate SAML assertions on-demand

Para gerar uma afirmação SAML sob demanda, configure as propriedades do Token conforme descrito acima. Além disso, a concessão de Bearer Assertion do SAML 2.0 requer um certificado de Assinatura com uma chave privada.

Source SAML assertions from an IdP

Para obter afirmações SAML de um IdP de terceiros, defina o parâmetro SamlSingleSignOnProvider.