Partilhar via

Diretrizes de desempenho da ACS

  • Artigo

Aplica-se A

  • Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como serviço de Controlo de Acesso ou ACS)

  • Windows Identity Foundation (WIF)

Resumo

Este tópico descreve as principais diretrizes de desempenho que deve ter em conta quando desenvolver aplicações e serviços que utilizam ACS. Em particular, o tópico fornece orientações sobre tamanhos simbólicos e criptografia e como afeta o desempenho geral.

Descrição Geral

Em geral, os principais atributos do desempenho são o tempo de resposta, a produção e a utilização de recursos. Por exemplo, se a aplicação tiver recursos limitados, como a memória, é provável que algumas informações venham a chegar ao sistema de ficheiros que é muito mais lento do que as operações na memória – o que irá afetar o tempo de resposta global. Aqui está outro exemplo, se a aplicação enviar uma grande quantidade de dados sobre uma rede com largura de banda limitada, resulta em tempos de resposta mais lentos do que os desejados. Uma abordagem para resolver problemas de desempenho é adicionar mais recursos como largura de banda de rede, CPU mais rápido e mais memória. Esta abordagem pode ajudar, embora nem sempre. Outra abordagem é melhorar o código para que utilize menos recursos e troque menos dados. Tendo em conta o contexto das aplicações de conhecimento de reclamações e o que está sob o controlo do desenvolvedor, existem alguns fatores-chave relacionados com a utilização de ACS que afetam o desempenho, nomeadamente, tokens e operações criptográficas relacionadas com os tokens.

Objetivos

  • Defina os aspetos que afetam o desempenho nas aplicações que utilizam ACS.

  • Fornecer diretrizes como melhorar o desempenho de cada um dos aspetos.

Tamanho e encriptação de tokens

O tamanho e encriptação de token são factores-chave sob o controlo do desenvolvedor que afetam o desempenho de aplicações integradas com ACS.

  • Tamanho simbólico. O tamanho do token afeta o desempenho de duas maneiras. Em primeiro lugar, afeta diretamente o desempenho relacionado com a largura de banda da rede em certa medida. Quanto maior for o símbolo, mais largura de banda de rede será necessário, resultando numa resposta mais lenta em geral. Em segundo lugar, quanto maior for o símbolo, mais ciclos de CPU são necessários para verificar a integridade e extrair as reclamações no token. O processamento de token inclui analisar o token e des-serializá-lo em formato binário para que o seu código possa usá-lo, o processamento também inclui várias operações de criptografia, como validação de assinaturas, e desencriptação opcional. Quanto maior for o símbolo, mais ciclos de CPU gastos no seu processamento resultam numa maior utilização dos recursos e numa resposta global mais lenta. O tamanho do token depende de vários fatores: formato simbólico, criptografia aplicada ao token, e as alegações no token. A ACS suporta fichas SAML, SWT e JWT. Geralmente, um símbolo SWT ou JWTJWT é menor do que um símbolo SAML que transporta uma quantidade equivalente de informação. Para mais informações leia os formatos Token Suportados em ACS. No entanto, existe uma ressalva, diferentes formatos simbólicos são otimizados para diferentes protocolos e arquiteturas de aplicações.

    • Os tokens SWT são emitidos sobre os protocolos WS-Federation, WS-Trust e OAuth WRAP ou OAuth 2.0. Isto significa que os tokens SWT podem ser usados em aplicações Web, serviços WCF (SOAP) e serviços WCF (REST). A WIF não suporta o manipulador de fichas SWT.

    • Os tokens SAML são emitidos ao longo de protocolos WS-Trust e WS-Federation. Isto significa que os tokens SAML podem ser usados em aplicações Web e serviços WCF (SOAP). A WIF suporta os tokens SAML 2.0 e SAML 1.1. Leia mais sobre a WIF no seguinte tópico Windows Fundação identidade

    • JWT Tokens são emitidos sobre os protocolos WS-Federation, WS-Trust e OAuth 2.0. Isto significa que os tokens SWT podem ser usados em aplicações Web, serviços WCF (SOAP) e serviços WCF (REST).

    Um dos fatores que mais contribui para o tamanho do símbolo são as alegações contidas no token. Quanto mais afirma que o símbolo carrega o seu tamanho maior. Na maioria dos casos, as alegações que vêm com o símbolo estão sob o controlo do desenvolvedor. As reclamações utilizadas por uma aplicação são adicionadas, removidas ou alteradas pelo Serviço de Token de Segurança (STS), como AD FS ou ACS. A ACS utiliza grupos de regras e regras para adicionar, remover ou alterar reclamações num token. Para mais informações leia os Grupos de Regras e Regras.

  • A encriptação. A encriptação e outras operações criptográficas, tais como a assinatura, validação de assinaturas e desencriptação afetam diretamente o desempenho. As operações de criptografia consomem poder de computação devido aos algoritmos complexos envolvidos. ACS assina todos os tokens emitidos como uma medida de integridade para combater ataques de adulteração. A validação de assinaturas de fichas não é opcional. A encriptação token é necessária se uma aplicação de partido de gestão é um serviço web que não está a usar o SSL para encriptar comunicações. Os serviços baseados no WCF que utilizam o SOAP requerem fichas de prova de posse encriptadas com o protocolo WS-Trust. A encriptação token é necessária para proteger informações sensíveis sobre um canal não encriptado. No entanto, nos casos em que o canal de comunicação é encriptado, como a utilização de encriptação SSL, então a utilização de encriptação simbólica é opcional e pode não ser aplicada a favor de um melhor desempenho.

Consulte também

Conceitos

Diretrizes de Segurança ACS
Diretrizes de Gestão de Certificados e Chaves