Certificados de assinatura de token do ADFS e da terceira parte confiável

Question

Ainda não entendi as funcionalidades do certificado de assinatura de token da parte confiável com o ADFS 2.0 / 3.0. Depois que a substituição automática de certificado autoassinado ocorre (por padrão), há cenários em que você precisa entregar manualmente o novo certificado de autenticação de token para (geralmente) um provedor de aplicativo de SSO externo para que eles coloquem o novo certificado em seu fim para que o SSO continue funcionando.

No entanto, isso pode acontecer automaticamente. O melhor que eu encontrei explicado aqui:

AD FS e auto assinados por assinatura de sinais | Blog da Kloud

[ADFS] ... can automatically renew self-signed certificates before expiry, and if a relying party trust is configured for automatic federation metadata updates, automatically provide the new public key to the relying party. This automation makes for a resilient, low maintenance federation service in that a key certificate used by the service does not require periodic attention.

A questão é; Como posso saber se uma confiança da terceira parte confiável está configurada para atualizações automáticas de metadados de federação? Isso é simples e simplesmente essa configuração na confiança (graças à pesquisa de imagens do Google):

Em caso afirmativo, como posso garantir que a atualização foi bem-sucedida (além da possível data da última verificação) e a terceira parte confiável obteve automaticamente o novo certificado ou sua chave pública?

    

Answer 1

Existem vários certificados em relações de confiança SAML2 e WS-federation. Vou ignorar aqui o certificado TLS da URL https dos servidores (o ADFS chama o certificado de comunicação).

Cada parte pode ter um certificado de assinatura. As mensagens que a parte envia são assinadas com a chave privada desse certificado. As partes da SAML2 geralmente assinam solicitações e respostas. O WS-Federation passive não assina o pedido (portanto, um RP passivo não possui um). O certificado de assinatura é publicado nos metadados. Durante o rollover, pode haver dois (antigos e novos).

Cada parte pode ter um certificado de criptografia. Quando uma solicitação ou resposta é enviada a uma parte com um certificado de criptografia, a chave pública desse certificado pode ser usada para criptografar a chave de criptografia. Tornar a mensagem ilegível para todos, exceto o alvo. O certificado de criptografia é publicado nos metadados. Na maioria das vezes, apenas um certificado de criptografia é publicado nos metadados. Mas os certificados antigos são aceitos por algum tempo para tornar a rolagem perfeita.

O rollover automático do ADFS é legal. Sugiro que você o deixe assim ou substitua-o por um certificado autoassinado com validade de 10 anos. O ADFS seguirá os metadados publicados por seus parceiros se o ADFS tiver um URL para seus metadados.

Apoiando as partes do WS-Fed, leia os aplicativos Microsoft .NET (também chamados de WIF). Depende da aplicação. Os aplicativos podem publicar seus metadados, o que é bom para o administrador do ADFS, porque eles não precisam digitar muito, menos erros de comunicação etc. Win win para todos. Portanto, todo aplicativo deve publicar seus metadados. Melhor para todos. Mas para as partes confiáveis do WS-Fed passivo não haveria um certificado de assinatura. Pode haver um certificado de criptografia. O .NET tem classes para ler e gerar os metadados “por solicitação” em System.IdentityModel.Metadata. Existem várias amostras dele na Internet. Um exemplo deles está no Thinktecture IdentityServer.

Terceiros de confiança podem ler os metadados do ADFS. Havia sempre uma tarefa agendada disponível. Ele leu os metadados do ADFS e atualizou o arquivo web.config do aplicativo. Eu nunca usei isso porque tinha o efeito colateral de uma reciclagem de pool (mesmo se não houvesse nenhuma mudança) e ele destruiu o diretório com versões antigas do web.config. Se você tiver problemas para codificar um leitor ou gravador, contate-me off-line. Isso pode ser feito para qualquer aplicativo (também para o SharePoint). É uma questão de custos, fazê-lo manualmente (uma vez por ano) ou escrever código para fazê-lo automaticamente.

    

Answer 2

Enquanto as partes em resposta consomem seu serviço do AD FS, você não pode controlar o funcionamento dos aplicativos da parte em resposta. Você precisa trabalhar com eles para reduzir o tempo de inatividade do serviço.

link

    

Answer 3

this can happen automatically.

É mais do que isso, acontece automaticamente! Seus certificados são renovados automaticamente a cada X dias, sendo X o valor da propriedade "CertificateRolloverInterval" (ou talvez "CertificateDuration", eu tenho uma dúvida; execute Get-ADFSProperties para recuperá-los).

how do I know if a relying party trust is configured for automatic federation metadata updates?

Você não pode saber ... Isso não é controlado pelo seu servidor ADFS. É a outra parte que decide se verifica seus metadados regularmente ou não. Bem, obviamente, se você alterar seus certificados e seu SSO quebrar, então saberá que a outra parte não está verificando o seu ADFS ...

A tela de impressão mostra o oposto, ou seja, mostra que você está verificando os metadados da outra parte. Se você enviar esta tela de impressão para seu parceiro, eles sabem que podem alterar seus certificados "com segurança".

Nota final: pela minha experiência, o único aplicativo que possui essa funcionalidade de "atualização automática" é o próprio ADFS. Mesmo o Sharepoint e o Dynamics CRM não o possuem. Então eu acho isso muito inútil.

Para concluir, minha sugestão é desativar a propriedade "AutoCertificateRollover" do ADFS e gerenciar seus certificados por conta própria. A vantagem é que você usa o certificado desejado, com uma data de expiração escolhida (para o ambiente TEST, defina a data de expiração 50 anos depois, muito útil). E escreva em seu calendário um grande lembrete para atualizar suas relações de confiança quando seu certificado estiver prestes a expirar!