Visão geral da arquitetura de ID Verificada do Microsoft Entra
É importante planejar sua solução de credencial verificável para que, além de emissão e validação de credenciais, você tenha uma visão completa dos impactos de arquitetura e negócios promovidos por ela. Recomendamos revisar a Introdução à ID Verificada do Microsoft Entra e as Perguntas frequentes e, em seguida, concluir o tutorial Introdução.
Essa visão geral da arquitetura apresenta os recursos e componentes do serviço ID Verificada do Microsoft Entra. Para obter informações mais detalhadas sobre emissão e validação, consulte
Como abordar a identidade
Atualmente, a maioria das organizações usa sistemas de identidade centralizados para fornecer credenciais aos funcionários. Elas também usam muitos métodos para atrair clientes, parceiros, fornecedores e partes confiáveis para os limites de confiança da organização. Esses métodos incluem a federação, a criação e o gerenciamento de contas de convidado com sistemas como o Microsoft Entra B2B e a criação de confianças explícitas com partes confiáveis. A maioria das relações de negócios tem um componente digital, portanto, para gerar alguma confiança entre as organizações, é necessário um esforço significativo.
Sistemas de identidade centralizados
Abordagens centralizadas ainda funcionam bem em muitos casos, como quando aplicativos, serviços e dispositivos dependem dos mecanismos de confiança usados em um domínio ou limite de confiança.
Em sistemas de identidade centralizados, o provedor de identidade (IDP) controla o ciclo de vida e o uso de credenciais.
No entanto, há cenários em que o uso de uma arquitetura descentralizada com credenciais verificáveis pode fornecer valor, aumentando cenários importantes, como
integração segura de identidades de funcionários e de outras pessoas, incluindo cenários remotos.
acesso a recursos dentro do limite de confiança organizacional com base em critérios específicos.
acesso a recursos fora do limite de confiança, como recursos de parceiros, com uma credencial portátil emitida pela organização.
Sistemas de identidade descentralizados
Em sistemas de identidade descentralizados, o controle do ciclo de vida e do uso das credenciais é compartilhado entre o emissor, o titular e a parte confiável que consomem a credencial.
Considere o cenário no diagrama em que o Proseware, um site de comércio eletrônico, quer oferecer descontos corporativos aos funcionários da Woodgrove.
Se você não estiver familiarizado com as credenciais verificáveis (VCs), poderá considerar a terminologia delas um pouco confusa. As definições a seguir são tiradas da seção de terminologiaModelo de dados 1.0 das credenciais verificáveis. Depois disso, é possível relacionar essas definições a entidades no diagrama anterior.
"Um emissor é a função que uma entidade desempenha quando faz declarações sobre um ou mais sujeitos, cria uma credencial verificável dessas declarações e transmite essa credencial a um titular."
- No diagrama anterior, a Woodgrove é o emissor de credenciais verificáveis para seus funcionários.
"Um titular é uma função realizada por uma entidade quando possui uma ou mais credenciais verificáveis e gera apresentações delas. Um titular geralmente é, mas nem sempre, um assunto das credenciais verificáveis que ele possui. Os titulares armazenam suas credenciais em repositórios de credenciais."
- No diagrama anterior, a Alice é uma funcionária da Woodgrove. Ela obtive uma credencial verificável do emissor Woodgrove e é a titular dessa credencial.
"Um verificador é uma função realizada por uma entidade para receber uma ou mais credenciais verificáveis, opcionalmente em uma apresentação verificável para processamento. Outras especificações podem se referir a esse conceito, como uma terceira parte confiável."
- No diagrama anterior, a Proseware é um verificador de credenciais emitidas pela Woodgrove.
“Uma credencial é um conjunto de uma ou mais declarações feitas por um emissor. Uma credencial verificável é uma credencial inviolável que tem uma autoria que pode ser verificada criptograficamente. Credenciais verificáveis podem ser usadas para criar apresentações verificáveis, que também podem ser verificadas criptograficamente. As declarações em uma credencial podem abordar diferentes sujeitos."
“Um identificador descentralizado é um identificador portátil baseado em URI, também conhecido como DID, associado a uma entidade. Esses identificadores geralmente são usados em uma credencial verificável e estão associados a sujeitos, emissores e verificadores."
"Um documento identificador descentralizado, também conhecido como um documento DID, é um documento acessível por meio de um registro de dados verificáveis que contém informações relacionadas a um identificador descentralizado específico, como as informações de chave pública e o repositório associado."
No cenário, o emissor e o verificador têm um DID e um documento de DID. O documento de DID contém a chave pública e a lista de domínios Web DNS associados ao DID (também conhecidos como domínios vinculados).
A Woodgrove (emissor) assina os VCs de seus funcionários com sua chave privada; da mesma forma, a Proseware (verificador) assina solicitações para apresentar um VC usando a chave dela, que também está associada ao DID.
Um sistema de confiança é a base para estabelecer a confiança entre sistemas descentralizados. Ele pode ser um razão distribuído ou algo centralizado, como DID Web.
“Um Razão distribuído é um sistema não centralizado para o registro de eventos. Esses sistemas estabelecem confiança suficiente para que os participantes confiem nos dados registrados por outras pessoas para tomar decisões operacionais. Normalmente, eles usam bancos de dados distribuídos em que nós diferentes usam um protocolo de consenso para confirmar a ordem de transações assinadas criptograficamente. A vinculação de transações assinadas digitalmente ao longo do tempo geralmente torna o histórico do razão efetivamente imutável."
Como combinar arquiteturas de identidade centralizadas e descentralizadas
Ao examinar uma solução de credencial verificável, é importante entender como as arquiteturas de identidade descentralizadas podem ser combinadas com arquiteturas de identidade centralizadas para fornecer uma solução que reduz o risco e oferece benefícios operacionais significativos.
O percurso do usuário
Esta visão geral da arquitetura segue o percurso de um candidato a uma vaga e, em seguida, funcionário que se candidata e aceita um emprego em uma organização. Em seguida, ela descreve alterações com relação ao funcionário e à organização em que as credenciais verificáveis podem aumentar os processos centralizados.
Atores nesses casos de uso
Alice, uma pessoa que está se candidatando e aceitando o emprego na Woodgrove, Inc.
Woodgrove, Inc., uma empresa fictícia.
Adatum, o parceiro de verificação de identidade fictício da Woodgrove.
Proseware, a organização parceira fictícia da Woodgrove.
A Woodgrove usa arquiteturas de identidade centralizadas e descentralizadas.
Etapas no percurso do usuário
Alice se candidata, aceita e é integrada a um cargo na Woodgrove, Inc.
Acessar recursos digitais dentro no limite de confiança da Woodgrove.
Acessar recursos digitais fora do limite de confiança da Woodgrove sem estender os limites de confiança da empresa ou dos parceiros.
À medida que a Woodgrove continua a operar seus negócios, ela deve gerenciar identidades continuamente. Os casos de uso nesta orientação descrevem como a Alice pode usar funções de autoatendimento para obter e manter identificadores e como a Woodgrove pode adicionar, modificar e encerrar relações entre empresas com requisitos de confiança variados.
Esses casos de uso demonstram como identidades centralizadas e descentralizadas podem ser combinadas para fornecer uma identidade mais robusta e eficiente, além de estratégia de confiança e ciclo de vida.
Percurso do usuário: integração à Woodgrove
Reconhecimento: a Alice está interessada em trabalhar para a Woodgrove, Inc. e visita o site de carreira da empresa.
Ativação: o site da Woodgrove apresenta a Alice um método para provar sua identidade, solicitando um código QR ou um link profundo para visitar o parceiro de prova de identidade confiável, Adatum.
Solicitar e carregar: Adatum solicita a prova de identidade da Alice. Alice tira uma selfie e uma imagem da carteira de motorista e as envia por upload para a Adatum.
Emissão: depois que a Adatum verificar a identidade de Alice, emite para ela uma VC (credencial verificável) que atesta sua identidade.
Apresentação: a Alice (a titular e o assunto da credencial) pode acessar o portal de carreiras da Woodgrove para concluir o processo de candidatura. Quando a Alice usa a VC para acessar o portal, a Woodgrove assume as funções de verificador e parte confiável e confia no atestado da Adatum.
Distribuindo credenciais iniciais
Alice aceita o emprego na Woodgrove. Como parte do processo de integração, uma conta do Microsoft Entra é criada para Alice usar no limite de confiança da Woodgrove. O gerente deve descobrir como permitir que Alice, que trabalha remotamente, receba informações de conexão inicial de maneira segura. Antigamente, o departamento de TI poderia ter fornecido essas credenciais ao gerente, que as imprimiria e entregaria para Alice. A impressão de credenciais não funciona com funcionários remotos.
As VCs podem adicionar valor a sistemas centralizados aumentando o processo de distribuição de credenciais. Em vez de precisar que o gerente forneça credenciais, Alice pode usar sua VC como prova de identidade para receber um nome de usuário inicial e credenciais para acesso a sistemas centralizados. Alice apresenta a prova de identidade que adicionou à carteira como parte do processo de integração.
No caso de uso da integração, as funções de relação de confiança são distribuídas entre o emissor, o verificador e o titular.
O emissor é responsável por validar as declarações que fazem parte da VC que ele emite. A Adatum valida a identidade de Alice para emitir a VC. Nesse caso, as VCs são emitidas sem a consideração de um verificador ou uma parte confiável.
O titular contém a VC e a apresenta para verificação. Apenas Alice pode apresentar a VC que ela contém.
O verificador aceita as declarações na VC de emissores em que confia e valida a VC usando o recurso de razão descentralizado descrito no modelo de dados de credenciais verificáveis. A Woodgrove confia em declarações da Adatum sobre a identidade de Alice.
Ao combinar arquiteturas de identidade centralizadas e descentralizadas para integração, as informações privilegiadas sobre Alice necessárias para verificação de identidade, como um número de identificação do governo, não precisam ser armazenadas pela Woodgrove, porque a empresa confia que a VC de Alice emitida pelo parceiro de verificação de identidade (Adatum) confirma sua identidade. A duplicação do esforço é minimizada e uma abordagem programática e previsível para tarefas de integração inicial pode ser implementada.
Percurso do usuário: acessando recursos no limite de confiança
Como funcionária, Alice está operando no limite de confiança da Woodgrove. A Woodgrove atua como o provedor de identidade (IDP) e mantém o controle completo da identidade e a configuração dos aplicativos que Alice usa para interagir no limite de confiança da Woodgrove. No caso de recursos no limite de confiança do Microsoft Entra, Alice fornece várias formas de prova de identificação para entrar no limite de confiança da WoodGrove e acessar os recursos que estão no ambiente de tecnologia da empresa. Múltiplas provas são um cenário típico que é bem servido usando uma arquitetura de identidade centralizada.
A Woodgrove gerencia o limite de confiança e, seguindo boas práticas de segurança, fornece o nível de acesso com menos privilégios a Alice com base no trabalho a ser realizado. Para manter uma postura de segurança forte e, potencialmente, por motivos de conformidade, a Woodgrove também deve ser capaz de rastrear as permissões dos funcionários e o acesso aos recursos e de revogar essas permissões após demissões.
Alice usa apenas a credencial que a Woodgrove mantém para acessar os recursos da empresa. Alice não precisa rastrear quando a credencial é usada, pois a Woodgrove está gerenciando a credencial, que é usada apenas com recursos da Woodgrove. A identidade só é válida no limite de confiança da Woodgrove quando o acesso aos recursos da empresa é necessário, portanto, Alice não precisa ter a credencial.
Usando VCs no limite de confiança
Todo funcionário tem necessidades de identidade que mudam sempre, e as VCs pode aumentar os sistemas centralizados para gerenciar essas alterações.
Embora Alice seja uma funcionária da WoodGrove, ela pode precisar obter acesso a recursos com base em requisitos específicos de uma reunião. Por exemplo, quando Alice conclui o treinamento de privacidade, ela pode receber uma nova VC de funcionário com essa declaração, a ser usada para o acesso a recursos restritos.
As VCs podem ser usadas no limite de confiança para a recuperação da conta. Por exemplo, se o funcionário perdeu o telefone e o computador, ele pode recuperar o acesso obtendo um novo VC do serviço de verificação de identidade, que é confiável para a Woodgrove e, em seguida, usar esse VC para obter novas credenciais.
Percurso do usuário: acessando recursos externos
A Woodgrove negocia um desconto de compra de produto com o Proseware. Todos os funcionários da Woodgrove estão qualificados para o desconto. A empresa quer fornecer à Alice uma maneira de acessar o site da Proseware e receber o desconto em produtos comprados. Se a Woodgrove usa uma arquitetura de identidade centralizada, há duas abordagens para fornecer o desconto a Alice:
Alice pode fornecer informações pessoais para criar uma conta na Proseware e, em seguida, a Proseware precisa verificar o emprego de Alice na Woodgrove.
A Woodgrove pode expandir o limite de confiança para incluir a Proseware como um terceiro confiável e Alice pode usar esse limite de confiança estendido para receber o desconto.
Com identificadores descentralizados, a Woodgrove pode fornecer a Alice uma VC (credencial verificável) para uso no acesso ao site da Proseware e a outros recursos externos.
Ao fornecer a VC para Alice, a Woodgrove está atestando que ela é funcionária da empresa. A Woodgrove é um emissor de VC confiável na solução de validação da Proseware. Essa confiança no processo de emissão da Woodgrove permite que a Proseware aceite eletronicamente a VC como prova de que Alice é uma funcionária da Woodgrove e fornece o desconto a ela. Como parte da validação da VC que a Alice apresenta, a Proseware verifica a validade do VC usando o sistema de confiança. Nesta solução:
A Woodgrove permite que Alice forneça uma prova de emprego à Proseware sem que a Woodgrove precise estender o limite de confiança.
A Proseware não precisa expandir o limite de confiança para validar se Alice é uma funcionária da Woodgrove. Ela pode usar a VC que a Woodgrove fornece como alternativa. Como o limite de confiança não é expandido, o gerenciamento da relação de confiança é mais fácil e a Proseware pode encerrar facilmente a relação não aceitando mais as VCs.
Alice não precisa fornecer informações pessoais, como um email, à Proseware. Ela contém a VC em um aplicativo de carteira de um dispositivo pessoal. A única pessoa que pode usar a VC é Alice e ela deve começar a usar a credencial. Cada uso do VC é registrado pelo aplicativo de carteira, de modo que Alice tem um registro de quando e onde o VC é usado.
Ao combinar arquiteturas de identidade centralizadas e descentralizadas para operar dentro e fora dos limites de confiança na Woodgrove, a complexidade e o risco podem ser reduzidos e as relações limitadas são mais fáceis de gerenciar.
Alterações ao longo do tempo
A Woodgrove adiciona novas relações comerciais e encerra as atuais com outras organizações e precisa determinar quando as arquiteturas de identidade centralizada e descentralizada são usadas.
Ao combinar arquiteturas de identidades centralizada e descentralizada, a responsabilidade e o esforço associados à identidade e à comprovação de identidade são distribuídos, reduzindo o risco. O usuário não corre o risco de divulgar suas informações privadas com frequência ou para tantos verificadores desconhecidos. Especificamente:
- Em arquiteturas de identidade centralizadas, o IDP emite credenciais e executa a verificação dessas credenciais emitidas. O IDP processa informações sobre todas as identidades. Ele os armazena em um diretório ou os recupera de um diretório. Opcionalmente, os IDPs podem aceitar tokens de segurança de outros sistemas IDP, como entradas sociais ou parceiros comerciais. Para que um terceiro confiável use identidades no limite de confiança do IDP, elas devem ser configuradas para aceitar os tokens emitidos pelo IDP.
Como os sistemas de identidade descentralizados funcionam
Em arquiteturas de identidade descentralizadas, o emissor, o usuário e o RP (terceiro confiável) têm a função de estabelecer e garantir a troca confiável e contínua das credenciais entre si. As chaves públicas dos DIDs dos atores podem ser resolvidas no sistema de confiança, que permite a validação da assinatura e, portanto, a confiança de qualquer artefato, como uma credencial verificável. As partes confiáveis podem consumir as credenciais verificáveis sem estabelecer relações de confiança com o emissor. Em vez disso, o emissor fornece ao assunto uma credencial para apresentar como prova às partes confiáveis. Todas as mensagens entre atores são assinadas com o DID do ator; DIDs de emissores e verificadores também precisam ter propriedade sobre os domínios DNS que geraram as solicitações.
Por exemplo: quando os titulares da VC precisam acessar um recurso, eles devem apresentá-lo a essa terceira parte confiável. Eles fazem isso usando um aplicativo de carteira para ler a solicitação da RP de apresentação de uma VC. Como parte da leitura da solicitação, o aplicativo de carteira usa o DID do RP para encontrar as chaves públicas do RP usando o sistema de confiança, validando que a solicitação para apresentar o VC não foi adulterada. Para comprovar a propriedade do domínio, a carteira também verifica se o DID está sendo referenciado em um documento de metadados hospedado no domínio DNS do RP.
Fluxo 1: emissão de credenciais verificáveis
Neste fluxo, o titular da credencial interage com o emissor para solicitar uma credencial verificável, conforme ilustrado no diagrama a seguir
O titular inicia o fluxo usando um navegador ou aplicativo nativo para acessar o front-end da Web do emissor. O site do emissor faz com que o usuário colete dados e executa a lógica específica do emissor para determinar se a credencial pode ser emitida, além do conteúdo dela.
O front-end da Web do emissor chama o serviço de ID Verificada do Microsoft Entra para gerar uma solicitação de emissão de VC.
O front-end da Web renderiza um link para a solicitação como um código QR ou um link profundo específico do dispositivo (dependendo do dispositivo).
O titular examina o código QR ou o link profundo da etapa 3 usando um aplicativo de carteira, como o Microsoft Authenticator
A carteira baixa a solicitação do link. A solicitação inclui:
O DID do emissor. O DID do emissor é usado pelo aplicativo de carteira para a resolução no sistema de confiança a fim de encontrar as chaves públicas e os domínios vinculados.
A URL com o manifesto da VC, que especifica os requisitos de contrato para emitir a VC. O requisito do contrato pode incluir id_token, atributos autodeclarados que devem ser fornecidos ou a apresentação de outro VC.
Aparência da VC (URL do arquivo de logotipo, cores etc.).
A carteira valida as solicitações de emissão e processa os requisitos de contrato:
Valida que a mensagem de solicitação de emissão é assinada pelas chaves do emissor encontradas no documento DID resolvido por meio do sistema de confiança. A validação da assinatura garante que a mensagem não tenha sido adulterada.
Valida que o emissor é proprietário do domínio DNS mencionado no documento DID do emissor.
Dependendo dos requisitos do contrato de VC, a carteira pode exigir que o titular colete informações adicionais, por exemplo, solicitando atributos de emissão automática ou navegando por um fluxo de OIDC para obter um id_token.
Envia os artefatos exigidos pelo contrato para o serviço de ID Verificada do Microsoft Entra. O serviço de ID Verificada do Microsoft Entra retorna a VC assinada com a chave DID do emissor e a carteira a armazena com segurança.
Para obter informações detalhadas sobre como criar uma solução de emissão e considerações arquitetônicas, consulte Planejar sua solução de emissão de ID Verificada do Entra.
Fluxo 2: apresentação de credencial verificável
Neste fluxo, um titular interage com uma RP (parte confiável) para apresentar uma VC como parte de seus requisitos de autorização.
O titular inicia o fluxo usando um navegador ou aplicativo nativo para acessar o front-end da Web da terceira parte confiável.
O front-end de Web chama o serviço de ID Verificada do Microsoft Entra para gerar uma solicitação de apresentação de VC.
O front-end da Web renderiza um link para a solicitação como um código QR ou um link profundo específico do dispositivo (dependendo do dispositivo).
O titular examina o código QR ou o link profundo da etapa 3 usando um aplicativo de carteira, como o Microsoft Authenticator
A carteira baixa a solicitação do link. A solicitação inclui:
uma solicitação baseada em padrões para credenciais de um esquema ou tipo de credencial.
o DID do RP, que a carteira consulta no sistema de confiança.
A carteira valida a solicitação de apresentação e encontra VCs armazenadas que atendam à solicitação. Com base nas VCs necessárias, a carteira orienta o assunto a selecionar e consentir com o uso das VCs.
- O sujeito consente em compartilhar a VC com a RP
Em seguida, a carteira envia um conteúdo de resposta de apresentação ao serviço de ID Verificada do Microsoft Entra assinada pela entidade. Ele contém:
As VCs às quais o assunto consentiu.
O DID do sujeito.
O DID da RP como a “audiência” do conteúdo.
O serviço de ID Verificada do Microsoft Entra valida a resposta enviada pela carteira. Em alguns casos, o emissor do VC pode revogar o VC. Para garantir que o VC ainda seja válido, o verificador precisa verificar com o emissor do VC. Isso depende de como o verificador solicitou o VC na etapa 2.
Após a validação, o serviço de ID Verificada do Microsoft Entra chama novamente o RP com o resultado.
Para obter informações detalhadas sobre como criar uma solução de validação e considerações arquitetônicas, consulte Planejar sua solução de verificação de ID Verificada do Entra.
Principais observações
As arquiteturas descentralizadas podem ser usadas para aprimorar as soluções existentes e fornecer novos recursos.
Para atender às aspirações da Decentralized Identity Foundation (DIF) e às Metas de design da W3C, os itens a seguir devem ser considerados ao criar uma solução de credencial verificável:
Não há pontos centrais de estabelecimento de confiança entre os atores do sistema. Isso significa que os limites de confiança não são expandidos por meio da federação porque os atores confiam em VCs específicas.
- O sistema de confiança habilita a descoberta do DID (identificador descentralizado) de qualquer ator.
A solução permite que os verificadores validem VCs (credenciais verificáveis) de qualquer emissor.
A solução não permite que o emissor controle a autorização do assunto ou do verificador (terceira parte confiável).
Os atores operam de maneira desacoplada, cada um sendo capaz de concluir tarefas para suas funções.
Os emissores realizam cada solicitação de VC e não diferenciam as solicitações atendidas.
As entidades obtêm a VC, depois de emitida, e podem apresentá-la a qualquer verificador.
Os verificadores podem validar qualquer VC de qualquer assunto ou emissor.
Próximas etapas
Saiba mais sobre a arquitetura para credenciais verificáveis