Provedor de segurança OAuth no Jitterbit App Builder

Introdução

O provedor de segurança OAuth habilita suporte para OAuth 2.0. O provedor de segurança é responsável por autorizar solicitações de serviço 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 informações adicionais.

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.

• Asserção Portadora SAML 2.0 RFC 7522.

• Token Portador JWT RFC 7523.

Código de autorização

A concessão Código de Autorização OAuth 2.0 fornece autorização delegada em nível de usuário. Esta concessão é definida em 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. Depois que o usuário faz login com sucesso e aprova 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 por canal de retorno 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ó, OAuth fornece autorização, não autenticação. Portanto, provedores de segurança OAuth não são normalmente usados como provedores de autenticação externos: 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 publica um endpoint que fornece 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 detalhes adicionais.

Credenciais do cliente

A concessão Credenciais do Cliente 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 Credenciais do Cliente é definida em RFC 6749.

Credenciais de senha do proprietário do recurso

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

Conforme originalmente concebido, a concessão Credenciais de Senha do Proprietário do Recurso 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 fornece suporte parcial para a concessão Credenciais de Senha do Proprietário do Recurso 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. Desta forma, a concessão é funcionalmente equivalente a uma conta de serviço.

Asserção portadora SAML 2.0

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

Token portador JWT

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

Configuração

A configuração varia conforme a concessão OAuth. No mínimo, OAuth requer:

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

• Endpoint de token.

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

Autenticação

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

• Tipo de Autenticação: OAuth

• Concessão OAuth: Selecione uma concessão OAuth compatível.

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

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

  • Client Secret JWT: O cliente é autenticado usando um JSON Web Token (JWT) assinado com o segredo do cliente (client_secret_jwt). (Consulte Tipos de autenticação de cliente JWT.)

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

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

  • Private Key JWT: O cliente é autenticado usando um JSON Web Token (JWT) assinado com uma chave privada (private_key_jwt). (Consulte Tipos de autenticação de cliente JWT.)

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

  • Form: Anexar token de acesso ao corpo codificado em URL de formulário.

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

  • User: Os tokens são emitidos para usuários individuais.

  • Client: Os 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.

Tipos de autenticação de cliente JWT

Os tipos de autenticação de cliente JWT suportam as seguintes opções de configuração:

• Assertion:

  • Issuer: Sem padrão. Geralmente usa um identificador de aplicação ou a ID do cliente. Consulte a documentação do servidor de autorização.

  • Audience: Usa como padrão o endpoint de token (conforme definido no painel Endpoints) de acordo com o padrão.

  • Subject: Usa como padrão a ID do cliente (conforme especificado no painel Credentials) de acordo com o padrão.

• Credentials:

  • Type: Client

    Client ID é obrigatório. Client Secret é ignorado e pode ser omitido.

• Certificates:

  • Usage: Signing

    Um certificado é usado apenas pelo tipo de autenticação de cliente Private Key JWT. O Client Secret JWT usa o segredo do cliente como chave.

• Properties:

  • Parameter: JwtClaimSet

  • Parameter: SigningAlgorithm

Token

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

• SAML 2.0 Bearer Assertion.

• JWT Bearer Token.

Asserção SAML 2.0 bearer

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

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

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

Token JWT bearer

• Issuer: Reivindicação de emissor JWT (https://tools.ietf.org/html/rfc7523#section-3). Usa como padrão o identificador do cliente (client_id).

• Subject: Reivindicação de assunto JWT (https://tools.ietf.org/html/rfc7523#section-3).

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

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

• Público: Declaração de público JWT (https://tools.ietf.org/html/rfc7523#section-3). Usa como padrão o Endpoint de Token.

Endpoints

Credenciais

Certificados

Propriedades

O provedor de segurança OAuth oferece suporte aos seguintes parâmetros adicionais:

Código de autorização

As seguintes propriedades adicionais se aplicam à concessão de Código de Autorização.

Asserção de portador SAML 2.0

As seguintes propriedades adicionais se aplicam à concessão de Asserção de Portador SAML 2.0.

Token de portador JWT

As seguintes propriedades adicionais se aplicam à concessão de Token de Portador JWT.

Rest

As propriedades adicionais a seguir 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 protocolos

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 esquema do provedor de segurança OAuth.

• state: O parâmetro state é uma carga útil criptografada e opaca. Inclui um token de Falsificação de Solicitação Entre Sites (CSRF) conforme RFC 6749.

Endpoint de redirecionamento

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

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

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

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

Proxy reverso

Desde o App Builder 4.59, o URI de redirecionamento OAuth omite o número da porta quando a porta padrão é usada. Isso garante compatibilidade com provedores OAuth quando o App Builder é hospedado atrás de um proxy reverso.

Para contornar esse problema com o App Builder 4.58 ou anterior, configure um provedor de segurança Reescrever URL para remover a porta explícita do URI de redirecionamento:

1. Navegue até IDE > Provedores de Segurança.
2. No painel Configuração, expanda o menu Mais e clique em Importar Provedor.

3. Cole a seguinte configuração, substituindo example.com pelo nome do host do App Builder:

   {
     "name": "URL Rewrite",
     "type": "rewrite_url",
     "settings": {
       "MatchUrl": "https://example.com:443",
       "RewriteUrl": "https://example.com"
     }
   }
   

4. Clique no botão Importar e depois clique em Prosseguir para confirmar.

5. Retorne à página Provedores de Segurança. No painel Configuração, expanda o menu Mais e clique em Pipeline de Solicitação.
6. Localize o provedor Reescrever URL importado. Defina sua Prioridade (por exemplo, 10) e marque a opção Habilitado.

Para verificar a correção, retorne à página Provedores de Segurança, expanda o menu Mais e clique em Inspecionar Solicitação. A Porta deve estar vazia e Padrão deve estar marcado.

Usando OAuth para autenticação externa

Conforme observado acima, OAuth é um protocolo de autorização, não um protocolo de autenticação. Porém, 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 refere-se a tal endpoint como o User Info Endpoint.

O App Builder pode ser configurado para consultar o User Info Endpoint e recuperar a identidade do usuário. Isso permite que um provedor de segurança OAuth seja usado para autenticação externa. Note, porém, 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 honrar a autenticação de cliente OAuth Basic (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 por cliente ao User Info Endpoint. O App Builder analisará o corpo da resposta como JSON, tratando as propriedades de nível superior como claims.

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 claim estarão disponíveis:

• user_name

• name

• email

Além de especificar o User Info Endpoint, o desenvolvedor deve mapear o claim que identifica o usuário – neste caso, o claim user_name – para o tipo de uso de claim Name.

Asserção de portador SAML 2.0

Ao usar o fluxo de Asserção de Portador SAML 2.0, as asserções SAML podem ser originadas de uma de duas maneiras:

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

2. (Descontinuado) um provedor de identidade (IdP) de terceiros emite uma asserção SAML durante o processo de logon único (SSO) SAML. consulte o tipo de provedor SAML para mais informações.

Cada origem requer configuração adicional.

Gerar asserções SAML sob demanda

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

Originar asserções SAML de um IdP

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

Limitações

• Tipos de autenticação de cliente JWT não podem ser usados com a concessão JWT Bearer Token. Ambos usam um JWT, mas cada token tem requisitos diferentes. O provedor de segurança OAuth suporta a configuração de apenas um único token JWT.