Por que Adicionar Autenticação a um Plano de Teste?
Artigos anteriores cobriram passo a passo para construir um Plano de Teste Apache JMeter para aplicar carga a um serviço de mapa ArcGIS Enterprise como SampleWorldCities. Estes foram ótimos para usar como introdução para construir um Plano de Teste para testar dinamicamente um serviço, no entanto, todos assumiram que o endpoint remoto era acessível anonimamente/publicamente. Isso é frequentemente não o caso, pois muitas implantações terão alguma forma de autenticação em vigor. Embora um artigo não seja suficiente para cobrir todos os cenários de autenticação do ArcGIS Enterprise, ele discutirá um comum:<\/P>
- A composição de um Plano de Teste para um serviço seguro que requer um token de um membro incorporado do portal ou membro do domínio<\/LI><\/UL>
Nota: Embora este Plano de Teste seja para uso contra um serviço que requer autenticação do usuário pelo portal, ele não cobre um cenário semelhante, mas tecnicamente diferente, de utilizar Single Sign On (Integrated Windows Authentication) para fazer login automaticamente como o membro que está executando o software de teste.<\/STRONG><\/FONT><\/P>Começando<\/H1>Para simplificar, este Artigo será construído diretamente a partir do Plano de Teste usado em Executando um Teste de Carga Apache JMeter no modo linha de comando (Iniciante/Intermediário)<\/A> chamado sampleworldcities3.zip<\/A>. <\/P>
<\/span><\/P>Este Plano de Teste aplicou carga dinamicamente a um serviço ArcGIS Enterprise publicamente acessível chamado SampleWorldCities em quatro escalas diferentes do mapa, cada uma das quais era uma Requisição HTTP colocada em seu próprio Controlador de Transação. Muitos dos componentes do teste (por exemplo, Pasta do Projeto, Nome do Servidor Web, Nome do Serviço) foram convenientemente colocados em variáveis para facilitar o compartilhamento e portabilidade. <\/P>
Estendendo o Plano de Teste para Adicionar Suporte à Autenticação<\/H1>A autenticação será feita adicionando três partes ao Plano de Teste: mais Variáveis Definidas pelo Usuário, Requisições de Autenticação para Obter um Token e o Suporte ao Token nos Cabeçalhos da Requisição do Mapa.<\/P>Variáveis Definidas pelo Usuário<\/H2>Adicione Variáveis Definidas pelo Usuário adicionais:<\/P>Clique no Plano de Teste (por exemplo, sampleworldcities4)Por padrão, isso deve estar selecionado quando um novo Plano de Teste é aberto<\/LI><\/UL><\/LI>Na parte inferior da seção Variáveis Definidas pelo Usuário, clique em AdicionarPara Nome digite: UsernamePara Valor digite: username<\/STRONG>Digite um nome de usuário de um membro dentro do portal que foi autorizado a consumir o serviço de mapa SampleWorldCities<\/LI>Se o usuário for membro do domínio, digite domain\username<\/LI><\/UL><\/LI><\/UL><\/LI>Para Nome digite: PasswordPara Valor digite: <\/SPAN>password<\/STRONG>Digite a senha associada ao nome de usuário acima<\/LI><\/UL><\/LI><\/UL><\/LI>Para Nome digite: TokenExpirationMinutesPara Valor digite: 240Isto gerará tokens com expiração em 4 horas<\/LI>Isto pode ser ajustado conforme necessário, mas um teste típico não excede essa duração<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>
Nota: Uma vez que o Plano de Teste é salvo, Apache JMeter armazena o nome de usuário e senha em texto simples dentro do arquivo JMX<\/STRONG>
Renomeie o valor da Variável Definida pelo Usuário ProjectFolder
- Renomeie o conteúdo do Valor de: C:\JMeter Tests\sampleworldcities3
- Para: C:\JMeter Tests\sampleworldcities4
- Se o Plano de Teste estiver em outro local, ajuste conforme necessário<\/LI>
Renomeie os valores das Variáveis Definidas pelo Usuário WebServerName, PortalInstanceName e ServerInstanceName
- Renomeie os conteúdos dos Valores conforme necessário
Requisições de Autenticação para Obter um Token
Quando você se autentica em um Site ArcGIS Enterprise a partir de um navegador web com uma aplicação JavaScript típica usando credenciais incorporadas ou membros do domínio, há vários itens enviados entre cliente e servidor no processo. Estes itens aparecem em várias requisições e respostas HTTP. Embora esse tráfego seja composto por muitas requisições, a maioria delas são chamadas para conteúdo estático que são necessários apenas para apresentação (dentro do navegador). As peças centrais da autenticação, capturadas ao fazer login no endpoint REST de uma implantação, são provenientes de três requisições:<\/P>
- OAuthState<\/LI>
- AccessToken<\/LI>
- Token<\/LI>
No Plano de Teste, essas três requisições HTTP serão colocadas em um Controlador de Transação que compõe a lógica da autenticação. Além disso, Extratores por Expressão Regular serão usados para cada requisição para extrair informações específicas das respostas do servidor. Por fim, tudo isso será colocado em outro contêiner lógico chamado Controlador Executar Apenas Uma Vez. Este se torna o primeiro item no teste. Como o nome indica, tudo agrupado neste controlador é executado apenas uma vez durante a vida útil da thread do teste.<\/SPAN>
Nota: O Controlador Executar Apenas Uma Vez é usado porque neste caso não se deseja autenticar e criar um novo token a cada iteração de cada thread do teste (isso geraria muita sobrecarga). Mas, como a autenticação não é renovada durante a execução, a duração do teste precisa ser menor que a expiração do token (4 horas conforme definido acima). <\/SPAN>
Esta abordagem é apenas um tipo de design de teste; podem existir variações diferentes que simulam propositalmente uma carga maior pela geração do token. Por exemplo, o nome de usuário e senha definidos poderiam opcionalmente vir de um arquivo CSV para simular diferentes credenciais sendo usadas.<\/SPAN>
A despeito do design leve da geração do token deste Plano de Teste, um teste que aumenta os passos muito rapidamente ou aumenta a pressão em grandes incrementos ainda pode exercer uma carga considerável já que cada nova thread solicitará um token. Neste caso, recomenda-se começar pequeno e aumentar a carga por etapas pequenas até encontrar um valor que funcione para seu sistema e fluxo.<\/SPAN>
Analisando a lógica da autenticação neste exemplo do Plano de Teste há variáveis mas não muitas personalizações. Portanto, são mostradas capturas de tela ao invés da listagem textual detalhada dos passos para construir cada Requisição HTTP e Extrator por Expressão Regular. O Plano completo pode ser baixado ao final deste Artigo.<\/SPAN>
Requisição HTTP OAuthState<\/SPAN>
Responsável por gerar uma resposta OAuthState (concessão implícita) do servidor.<\/SPAN>
< \/ span >< \/ SPAN >< \/ P >< H3 id = "toc-hId-1291397602" >< SPAN >Extrator por Expressão Regular OAuthState < \/ SPAN >< \/ H3 >< P >< SPAN >Usado para capturar o estado em uma variável chamada: oauthState < \/ SPAN >< \/ P >< P >< SPAN >< span class = "lia-inline-image-display-wrapper lia-image-align-inline" image-alt = "oauthstate_regularexpressionextractor.png" style = "width: 999px;" >
<\/span><\/SPAN><\/P>AccessToken HTTP Request<\/SPAN><\/H3>Responsável por passar as credenciais e as variáveis oauth_state. Se válidas, estas irão gerar uma resposta AccessToken do servidor<\/SPAN><\/P>
<\/span><\/SPAN><\/P>AccessToken <\/SPAN>Regular Expression Extractor<\/SPAN><\/H3>Usado para capturar o item em uma variável chamada: accessToken<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Token HTTP Request<\/SPAN><\/H3>Responsável por gerar um token do servidor.<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Token <\/SPAN>Regular Expression Extractor<\/SPAN><\/H3>Usado para capturar o item em uma variável chamada: token<\/SPAN><\/P>Esta variável é passada como um cabeçalho HTTP para autenticar cada requisição contra o serviço protegido.<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Token <\/SPAN>Response Assertion<\/SPAN><\/H3>Adicionado à requisição de geração do token para verificar uma string específica na resposta. Se a string "expires" não for encontrada, então um token foi gerado e toda a transação é marcada como falha (tendo uma requisição falhada).<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Token Support in the Map Request Headers<\/SPAN><\/H2>Com a variável token populada a partir da lógica de Autenticação, os cabeçalhos HTTP para cada requisição de mapa protegida podem ser expandidos para incluí-la sob o nome Cookie com o valor: agstoken=${token}<\/SPAN><\/P>
<\/span><\/SPAN><\/P>Nota: O HTTP Cookie Manager não é usado neste exemplo de Plano de Teste<\/STRONG>
Do ponto de vista técnico, o token poderia ter sido passado na requisição como um par chave-valor, mas para maior segurança, ele é passado como um cabeçalho HTTP.
Validando o Plano de Teste<\H1 >Assegure que a Visualização da Árvore de Resultados está habilitada e Inicie o teste (ex.: a seta verde) para validar as respostas.As marcas verdes para todas as partes da Autenticação indicam que um token válido foi obtido das credenciais fornecidas<\LI >A imagem das chamadas do mapa exportado indica que uma requisição foi emitida com sucesso para o serviço protegido <\LI ><\UL ><\LI ><\UL >
<\ / span ><\ / P >< P >< SPAN >Para baixar o Plano de Teste Apache JMeter usado neste Artigo veja: <\ / SPAN >< A href = "https:\/ \/community.esri.com \/ccqpr47374 \/attachments \/ccqpr47374 \/implementing-arcgis-blog \/247.6 \/1 \/sampleworldcities4.zip " target = "_self " >sampleworldcities4.zip<\ / A > <\ / P >< P > <\ / P >< P >< A href = "https:\/ \/jmeter.apache.org \/index.html " target = "_blank " rel = "noopener nofollow noreferrer " >Apache JMeter<\ / A >< SPAN > lançado sob a <\ / SPAN >< A href = "https:\/ \/apache.org \/ " target = "_blank " rel = "noopener nofollow noreferrer " >Apache<\ / A >< SPAN > <\ / SPAN >< A href = "https:\/ \/www.apache.org \/licenses \/ " target = "_blank " rel = "noopener nofollow noreferrer " >Licença 2.0.<\ / A >< SPAN > Apache, Apache JMeter, JMeter, a pena Apache e o logo Apache JMeter são marcas registradas da Apache Software Foundation.<\ / SPAN ><\ / P >< P > <\ / P >
