Como funciona a autenticação de token do ArcGIS Server?

Resposta

Nota: Este artigo faz referência somente a versões 9.x a 10.2.x do ArcGIS. Versões mais novas e suportadas do ArcGIS Enterprise habilitam HTTPS por padrão.

O ArcGIS Server suporta dois métodos de autenticação - camada da web (incluindo autenticação integrada do Windows, PKI e HTTP Basic/Digest) e autenticação da camada GIS (também conhecida como autenticação de token). Um método deve ser escolhido, os métodos não podem ser combinados.
Para maior segurança, a autenticação em série da web é recomendada. A camada GIS pode ser usada em ambientes menos seguros se a arquitetura ditar um balanceador de carga em vez de um adaptador da web ou em situações onde o servidor da web não tem meios de se integrar ao armazenamento do usuário que o ArcGIS Server está usando (como contas embutidas do ArcGIS Server).

Este artigo explica como funciona a autenticação de token e como deve ser configurada.

Quando o ArcGIS Server é configurado para usar autenticação de camada GIS, os aplicativos cliente pedem ao usuário seu nome de usuário e senha. Esses aplicativos cliente então enviam o nome de usuário/senha ao ArcGIS Server e recebem um token em troca. Esse token pode então ser usado em solicitações subsequentes para que o nome de usuário/senha não precise ser enviado.

Se o ArcGIS Server não estiver configurado corretamente, há riscos de segurança no uso de tokens. A seguir está uma discussão sobre esses riscos e o que deve ser feito a respeito deles.

Risco 1. Vazamento do nome de usuário/senhas

Todos os clientes e APIs da Esri enviam nomes de usuários e senhas por https (criptografados) se estiverem habilitados. Se não estiver habilitado, os nomes de usuário/senhas podem ser enviados como texto não criptografado pela rede. Para evitar isso, é altamente recomendado que https seja habilitado no ArcGIS Server ao usar a autenticação de camada GIS. Não é habilitado por padrão.

Risco 2: Reproduzir ataques

Um ataque comum é farejar o tráfego da rede e adquirir informações como tokens para reutilização em um ataque malicioso. Um invasor que adquiriu um token do ArcGIS Server de um usuário poderia fingir ser esse usuário por um período de tempo.

Há maneiras de atenuar esse tipo de ataque. O mais forte é exigir https para todas as comunicações, o que criptografa tudo o que é enviado de e para o ArcGIS Server.

Também existem maneiras de mitigar isso através das configurações de token do ArcGIS Server. O ArcGIS Server emite tokens de curto e longo prazo. Os tokens de longo prazo devem ser vinculados a um endereço IP ou um referenciador. Quando um token está vinculado a um IP, apenas tokens provenientes desse endereço IP são aceitos. Isso significa que um token reproduzido de outra máquina é rejeitado. Quando um token é vinculado a um referenciador, isso significa que, a menos que um cabeçalho http específico denominado referenciador seja definido, o token é rejeitado. Os aplicativos cliente decidem se devem usar referenciadores ou endereços IP. Usar o referenciador pode diminuir a segurança da implementação, portanto, não é recomendado.

Os tokens de curto prazo não precisam ser vinculados a um endereço IP ou referenciador, pois o períodono qual o token é válido costuma ser muito curto, o que torna mais difícil reproduzi-lo. O período de tempo máximo para tokens de curto prazo pode ser configurado de forma que possa ser reduzido para apenas um minuto.

Risco 3: Práticas de Desenvolvimento

Os tokens podem ser adquiridos através de HTTP GET ou HTTP POST. Usar um POST é sempre mais seguro. As solicitações GET podem deixar nomes de usuário/senhas no histórico do equipamento de rede e no histórico do navegador. Produtos e APIs da Esri usam POST ao adquirir tokens. No entanto, para a conveniência das pessoas que escrevem scripts, os tokens podem ser adquiridos por solicitações GET. A Esri não recomenda a obtenção de tokens por solicitações GET em ambientes seguros.