Pular para o conteúdo principal

Questão de Segurança da Informação — Segurança física e lógica — FGV 2023

Segurança da InformaçãoSegurança física e lógica
Código
fg072432
Banca
FGV
Órgão
TJ-RN
Ano
2023
Nível
Superior
Cargo
Analista Judiciário - Tecnologia de Informação – Análise de Sistemas
O analista Kléber desenvolveu o web service JusRest, que é protegido por autenticação OAuth2 através do client JusClient, registrado no servidor Keycloak do TJRN. Sendo o JusRest um web service, o administrador do Keycloak desabilitou os fluxos de autenticação OAuth2 para o JusClient. Dessa forma, para consumir o JusRest, o usuário deve fornecer um token já emitido. Para simplificar a integração com o Keycloak, Kléber utilizou no JusRest um adaptador de client do Keycloak. A fim de refletir a configuração do JusClient, Kléber ativou no adaptador a opção que desabilita a tentativa de autenticação do usuário, esperando que seja fornecido um token preexistente.Logo, Kléber ativou no adaptador Keycloak do JusRest a opção:
  1. Abearer-only;
  2. Bexpose-token;
  3. Cenable-basic-auth;
  4. Dverify-token-audience;
  5. Edisable-trust-manager.
Revelar gabarito e comentário

GabaritoA — bearer-only;

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Keycloak Client Adapter - Bearer-only

Gabarito: letra A. A opção bearer-only no adaptador do Keycloak configura o cliente para não iniciar o fluxo de autenticação, assumindo que um token já foi emitido e deve ser fornecido nas requisições. Isso reflete exatamente o cenário descrito: o administrador desabilitou os fluxos OAuth2 para o JusClient, e Kléber precisa que o web service aceite tokens preexistentes sem tentar autenticar o usuário novamente.

Keycloak Client Adapter
  • 1Bearer-only (✅)
    • Nunca inicia login
    • Só aceita tokens preexistentes
  • 2Outras opções
    • expose-token (❌)
      • Expõe token no cabeçalho
      • Continua permitindo login
    • enable-basic-auth (❌)
      • Autenticação básica (usuário/senha)
    • verify-token-audience (❌)
      • Verifica audience do token
      • Não desabilita login
    • disable-trust-manager (❌)
      • Desativa verificação SSL/TLS
LEVEL · soulevel.com.br

Análise das alternativas

Alternativa A — ✅ Correta ⟵ GABARITO

Keycloak Documentation: "Bearer-only access type is used for services that never initiate a login, but only accept bearer tokens."

A opção bearer-only desabilita a tentativa de autenticação do usuário, esperando que um token já tenha sido emitido. É exatamente o que o administrador configurou e o que Kléber ativou no adaptador.

Alternativa B — ❌ Incorreta

expose-token não desabilita a autenticação; ela expõe o token no cabeçalho das requisições para que o cliente possa inspecioná-lo, mas continua permitindo o fluxo de login.

Alternativa C — ❌ Incorreta

enable-basic-auth habilita autenticação básica HTTP (usuário/senha), o que contraria a necessidade de um token preexistente sem interação do usuário.

Alternativa D — ❌ Incorreta

verify-token-audience ativa a verificação do público-alvo (audience) do token, mas não desabilita a tentativa de autenticação. Ainda assim, o cliente poderia solicitar login.

Alternativa E — ❌ Incorreta

disable-trust-manager desativa a verificação de certificados SSL/TLS, não tem relação com a autenticação via token.

PEGA ESSA DICA!

No Keycloak, lembre-se: bearer-only = serviço que só aceita tokens; confidential/public clientes que iniciam login. Para APIs REST que recebem tokens de terceiros, sempre use bearer-only.

Gabarito: letra A.

Link permanente: /questoes/fg072432