Certificados e chaves
Atualizado em: 19 de junho de 2015
Aplica-se ao Azure
Microsoft Azure Active Directory Controle de Acesso (também conhecido como serviço de Controle de Acesso ou ACS) oferece duas maneiras diferentes de assinar e criptografar tokens: certificados X.509 com uma chave privada e chaves simétricas de 256 bits. Você pode configurar cada certificado ou chave para assinar tokens de alguns ou todos os aplicativos de terceira parte confiável no namespace e designar os certificados e chaves como primários ou secundários. Para adicionar e configurar certificados e chaves de assinatura, criptografia e descriptografia de token, use o Serviço de Gerenciamento do ACS ou o Portal de Gerenciamento do ACS.
Assinatura de tokens
O ACS assina todos os tokens de segurança que ele emite com um certificado X.509 (com uma chave privada) ou uma chave simétrica de 256 bits. Sua escolha de um tipo de credencial de assinatura (certificado ou chave) depende do formato de token selecionado para seus tokens emitidos pelo ACS. Para obter mais informações, consulte "Assinatura de token" em aplicativos de terceira parte confiável. Ao selecionar o tipo de credencial de assinatura que será criada, considere o seguinte:
Tokens SAML são assinados com certificados X.509. SAML é o formato de token padrão usado pelos aplicativos desenvolvidos no WIF (Windows Identity Foundation). Os tokens SAML podem ser emitidos por meio de vários protocolos, como WS-Federation e WS-Trust.
Tokens SWT são assinados com chaves simétricas de 256 bits. Os tokens SWT podem ser emitidos por meio de vários protocolos, como OAuth WRAP e WS-Federation.
Tokens JWT podem ser assinados por certificados X.509 ou chaves simétricas de 256 bits. Os tokens JWT podem ser emitidos por meio de vários protocolos, como WS-Federation, WS-Trust e OAuth 2.0.
Namespace ou certificados e chaves dedicados
Você pode configurar um certificado de autenticação ou uma chave simétrica para que ele seja usado para todo o namespace Controle de Acesso ou apenas para um aplicativo de terceira parte confiável específico no namespace. A diferença é a seguinte:
Controle de Acesso namespace — Quando um certificado de autenticação ou chave é configurado para todo o namespace Controle de Acesso, o ACS usa o certificado ou a chave para assinar tokens para todos os aplicativos de terceira parte confiável neste namespace que não têm um certificado ou chave específico do aplicativo. Um certificado com escopo de namespace também é usado para assinar metadados do ACS WS-Federation.
Dedicado – Se você configurar um certificado de autenticação ou chave a ser usado para um aplicativo de terceira parte confiável específico, o ACS usará o certificado de autenticação ou a chave apenas para assinar tokens entregues ao aplicativo de terceira parte confiável especificado.
Se você criar ou inserir uma chave simétrica dedicada, o ACS usará a chave dedicada para assinar tokens para o aplicativo. Se a chave dedicada expirar e não for substituída, o ACS usará a chave simétrica para o namespace Controle de Acesso para assinar tokens para o aplicativo.
Observação
- Como prática recomendada de segurança, ao usar chaves simétricas, crie uma chave dedicada para cada aplicativo de terceira parte confiável. Um certificado X.509 pode ser compartilhado com segurança por vários aplicativos em um namespace Controle de Acesso.
- Ao adicionar um aplicativo de terceira parte confiável gerenciado pela Microsoft a um namespace gerenciado, como ao adicionar um aplicativo de terceira parte confiável de um barramento de serviço ao namespace de um barramento de serviço, não use certificados nem chaves específicos do aplicativo (dedicados). Selecione a opção ACS para usar os certificados e as chaves que foram configurados para todos os aplicativos no namespace gerenciado. Para todos os outros aplicativos de terceira parte confiável, use certificados e chaves específicos do aplicativo. Para obter mais informações, consulte Namespaces Gerenciados.
- Quando você configura um aplicativo de terceira parte confiável que usa o certificado X.509 para o namespace Controle de Acesso para assinar tokens JWT, links para o certificado de namespace Controle de Acesso e a chave de namespace Controle de Acesso aparecem na página do aplicativo de terceira parte confiável no Portal de Gerenciamento do ACS. No entanto, o ACS usa apenas o certificado de namespace para assinar tokens para o aplicativo de terceira parte confiável.
Os certificados de assinatura geralmente são usados para assinar tokens dos aplicativos de terceira parte confiável em um namespace. O componente de chave pública de um certificado de autenticação de namespace é publicado nos metadados do ACS WS-Federation, o que permite que aplicativos de terceira parte confiável automatizem sua configuração. As chaves públicas dos certificados atribuídos apenas a um determinado aplicativo de terceira parte confiável não estão presentes nos metadados do ACS WS-Federation e são usadas somente quando o controle independente sobre o certificado de assinatura de um aplicativo de terceira parte confiável é necessário.
Chaves e certificados primários
No ACS, você pode manter vários certificados e chaves, mas usar apenas certificados e chaves designados para assinar tokens. Os certificados e as chaves designados para assinatura são conhecidos como primários.
Para designar um certificado ou uma chave como primária, selecione o item Tornar primária na página do certificado ou da chave. Para designar um certificado diferente como primário, selecione o item Tornar primário na página do outro certificado ou chave. Quando você fizer isso, o ACS rebaixa automaticamente quaisquer certificados primários ou chaves existentes para não primários.
Quando pelo menos um certificado ou uma chave for primário, os certificados e as chaves não primários não serão usados para assinatura até serem promovidos ao status primário pelo administrador, mesmo que o certificado ou a chave primário seja inválido ou tenha expirado. No entanto, se nenhum dos certificados (ou chaves) for primário, o ACS usará o certificado não primário que tem a data de início válida mais antiga.
O componente de chave pública de certificados primários e não primários é publicado no ACS WS-Federation metadados para habilitar a substituição de certificado programático. No entanto, o ACS usa apenas certificados primários e chaves para assinar tokens.
Datas de efetivação e expiração de chaves de assinatura
Quando você adiciona chaves de assinatura simétricas de 256 bits, deve também especificar uma data de efetivação e uma data de expiração. A data de efetivação indica a data em que a chave é ativada. A data de expiração indica a data em que a chave expira e não pode ser usada para assinar tokens.
Tokens de criptografia
No ACS, você pode optar por criptografar qualquer token SAML 1.1 ou SAML 2.0 que o ACS emita para seus aplicativos de terceira parte confiável.
Importante
O ACS não dá suporte à criptografia de tokens SWT ou JWT.
A criptografia de token é necessária para os serviços Web que utilizam tokens de verificação de posse através do protocolo WS-Trust. Se você usar o ACS para gerenciar a autenticação para um aplicativo de terceira parte confiável, todos os tokens emitidos pelo ACS para esse aplicativo de terceira parte confiável deverão ser criptografados. Em todos os outros cenários, a criptografia de token é opcional.
O ACS criptografa tokens SAML usando um certificado X.509 que contém uma chave pública (arquivo.cer). O token do aplicativo de terceira parte confiável descriptografa o token usando uma chave privada para esse certificado X.509. Para obter mais informações, consulte "Criptografia de token" em aplicativos de terceira parte confiável.
Tokens de descriptografia
O ACS pode aceitar tokens criptografados de provedores de identidade WS-Federation, como . O provedor de identidade WS-Federation recebe a chave pública de um certificado X.509 quando importa WS-Federation metadados do ACS e usa essa chave pública para criptografar o token de segurança encaminhado para o ACS. O ACS descriptografa o token usando a chave privada deste certificado X.509. Para obter mais informações, consulte Como configurar o AD FS 2.0 como um provedor de identidade.
Certificados de descriptografia de token primário
Você pode manter vários certificados de descriptografia de token para um aplicativo de terceira parte confiável ou Controle de Acesso namespace. Quando você designa um certificado como primário, o ACS usa esse certificado para descriptografar os tokens de WS-Federation provedores de identidade e usa certificados não primários somente se a tentativa de usar o certificado primário falhar.
Para designar um certificado de descriptografia como primário, selecione o item Tornar primário na página do certificado. Para designar um certificado diferente como primário, selecione o item Tornar primário na página do outro certificado. Quando você fizer isso, o ACS rebaixa automaticamente todos os certificados de descriptografia primária existentes para não primários.
Limitações do ACS para arquivos do certificado X.509
No ACS, os certificados X.509 que contêm apenas uma chave pública (arquivo.cer) podem ser usados ao criar uma identidade de serviço, validar uma assinatura de um provedor de identidade ou criptografar tokens SAML. Arquivos de certificado X.509 que contêm apenas uma chave pública (arquivo.cer) devem ser codificados em DER para serem usados com ACS. No momento, não há suporte para os arquivos de certificado codificado em base64. Carregar um certificado codificado em base64 no ACS resultará em um erro de validação quando o ACS receber um token de entrada que exige esse certificado.
No ACS, os certificados X.509 devem ser autoassinados ou assinados e encadeados diretamente a uma autoridade de certificação pública. O ACS não funcionará com certificados emitidos por uma autoridade de certificação privada.
Observação
Os ceritificates X.509 importados para o ACS não devem estar expirados.
Obtendo um certificado X.509
Há várias maneiras de obter um certificado X.509 para assinatura, criptografia ou descriptografia de tokens. O método usado depende de suas necessidades e das ferramentas disponíveis em sua organização.
Autoridade de certificação comercial — você pode comprar um certificado X.509 de uma autoridade de certificação comercial.
Gerar um certificado de Self-Signed – você pode gerar seu próprio certificado autoassinado a ser usado com o ACS. Se você estiver executando um sistema operacional baseado em Windows, poderá usar MakeCert.exe, uma ferramenta incluída no Microsoft Windows Software Development Kit (https://go.microsoft.com/fwlink/?LinkID=214104) para gerar um certificado autoassinado.
Por exemplo, o comando a seguir gera um certificado autoassinado em seu armazenamento de certificado pessoal,
MakeCert.exe -r -pe -n "CN=<service_namespace_name>.accesscontrol.windows.net" -sky exchange -ss my -len 2048 –e <1 year from today>
onde <service_namespace_name> é o nome do namespace Controle de Acesso.
Em seguida, você pode exportar a chave privada do seu repositório pessoal como um arquivo .pfx e usar o Portal de Gerenciamento do ACS para carregá-la no ACS.
Exportando um certificado autoassinado
Estas instruções explicam como exportar uma certificação autoassinada de um computador que executa Windows 8, Windows Server 2012 ou .
Para exportar o certificado autoassinado
Inicie MMC.exe e adicione o snap-in certificados ao console do MMC.
Clique duas vezes em Certificados - Usuário Atual, Pessoal e Certificados.
Clique com o botão direito do mouse em um certificado, clique em Todas as Tarefas e emExportar.
Na página Bem-vindo ao Assistente para Exportação de Certificados, clique em Avançar.
Na página Exportar Chave Privada, selecione Sim, exportar a chave privada e clique em Avançar.
Na página Formato do Arquivo de Exportação, clique em Troca de Informações Pessoais - PKCS #12 (.PFX).
Nos campos Senha, insira uma senha, confirme-a e clique em Avançar.
No campo Nome do arquivo, insira um caminho e um nome de arquivo com a extensão .pfx e clique em Avançar.
Clique em Concluir.
Datas válidas de certificados e chaves
O ACS avalia as datas de início e término (e data/hora) de certificados e chaves em UTC (Tempo Universal Coordenado). Como resultado, o ACS pode considerar chaves e certificados inválidos mesmo quando são válidos no horário local do computador local ou em outro fuso horário.
Para garantir que o certificado ou a chave fiquem válidos imediatamente, ajuste as datas com a hora UTC. Caso contrário, o ACS pode não emitir um token porque a chave ou o certificado ainda não é válido.
Consulte Também
Conceitos
Componentes do ACS 2.0
Aplicativos de terceira parte confiável
Diretrizes para gerenciamento de chaves e certificados