Provedor de Segurança - OAuth

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ço web. Os seguintes tipos de fonte de dados oferecem suporte a OAuth:

• DESCANSAR

• OData O

• RDBMS (limitado a 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 obter informações adicionais.

Concessões OAuth 2.0

O provedor de segurança OAuth oferece suporte às 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 de portadora SAML 2.0 RFC 7522.

• Token portador JWT RFC 7523.

Código de Autorização

A concessão do 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 do Código de Autorização, App Builder redireciona o agente do usuário (navegador) para o servidor de autorização. Depois que o usuário tiver 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 App Builder. O redirecionamento inclui um código de autorização. App Builder faz uma solicitação de back-channel 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 normalmente usados como provedores de autenticação externa: 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 poderá ser usado como um provedor de autenticação externa. Veja o User Info Endpoint para obter detalhes adicionais.

Credenciais do Cliente

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

Credenciais de Senha do Proprietário do Recurso

A concessão de credenciais de senha do proprietário do recurso OAuth 2.0 é definida em RFC 6749. No entanto, a bolsa foi desde então obsoleta.

Conforme concebido originalmente, a concessão de 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.

App Builder fornece suporte parcial para a concessão de credenciais de senha do proprietário do recurso OAuth 2.0. App Builder não solicita ao usuário sua credencial. 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.

Asserção de Portadora SAML 2.0

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

Token Portador JWT

A concessão do OAuth 2.0 JWT Bearer Token fornece autenticação de fonte de dados em nível de usuário. Neste fluxo, JSON Web Tokens (JWTs) são trocados por tokens de acesso OAuth. A concessão do OAuth 2.0 JWT Bearer Token é definida em 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 do OAuth 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 suportada.

• Autenticação de cliente OAuth: Determina o esquema de autenticação de 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 Client Password será usado. As credenciais serão fornecidas usando autenticação HTTP Basic. (client_secret_basic.)

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

• OAuth Resource Authentication: Determina o esquema de autenticação de solicitação de recurso. As opções incluem:

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

  • Formulário: Anexar token de acesso ao corpo codificado por URL do formulário.

  • Consulta: Acrescenta token de acesso à sequência de consultar.

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

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

  • Cliente: Os tokens são emitidos para o sistema cliente.

• Token Delete On Sign Out: Quando habilitado, App Builder exclui o token armazenado quando o usuário faz logout. Padrão: Desativado.

Ficha

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

• Asserção de portadora SAML 2.0.

• Token portador do JWT.

Asserção de Portadora SAML 2.0

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

• Audiência: A restrição de audiência da asserção SAML. Embora a especificação SAML indique que a audiência é um URI, muitas implementações não respeitam isso. Consequentemente, App Builder não exige que o público seja um 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).

• Assunto: Reivindicação de assunto 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 Assunto é obrigatório.

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

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 à concessão do Código de Autorização.

Asserção de Portadora SAML 2.0

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

Token Portador JWT

As seguintes propriedades adicionais se aplicam à concessão do JWT Bearer Token.

Descansar

As seguintes propriedades adicionais se aplicam quando o provedor de segurança OAuth é usado para autenticar fontes de dados REST. Elas 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 de Protocolo

Tokens de Atualização

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

Código de Autorização

Solicitação de Autorização

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

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

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

Endpoint de Redirecionamento

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

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

Onde https://example.com/AppBuilder é o URL absoluto para o App Builder diretório raiz do aplicativo e OAuth é o nome codificado em URL e com distinção entre maiúsculas e minúsculas do provedor de segurança.

A maioria dos aplicativos de externo precisará ser configurada com o endpoint de redirecionamento antes de autorizar qualquer solicitação.

Usando OAuth para Autenticação Externa

Conforme observado 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. App Builder refere-se a um endpoint como * Endpoint de informações do usuário*.

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. Observe, no entanto, que o endpoint deve atender aos seguintes requisitos:

• O endpoint deve ser alcançável por App Builder.

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

• O endpoint deve honrar a autenticação de cliente OAuth Básica (conforme descrito acima).

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

• 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, App Builder fará uma solicitação autenticada do cliente ao User Info Endpoint. App Builder analisará o corpo da resposta como JSON, tratando propriedades de nível superior como declarações.

Por exemplo, dada a seguinte resposta de exemplo:

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

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

Os seguintes tipos de reivindicação estarão disponíveis:

• user_name

• name

• email

Além de especificar o User Info Endpoint, o desenvolvedor deve mapear a reivindicação que identifica o usuário – neste caso, o user_name reivindicação–para o tipo de uso de reivindicação Nome.

Asserção de Portadora SAML 2.0

Ao usar o fluxo de asserção do portador do SAML 2.0, as asserções do SAML podem ser obtidas de duas maneiras:

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

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

Cada fonte requer configuração adicional.

Gere Asserções SAML Sob Demanda

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

Asserções SAML de Origem de um IdP

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