Declarações são afirmações (por exemplo, nome, identidade, chave, grupo, privilégio ou capacidade) feitas sobre os usuários — e entendidas pelos parceiros em uma federação no AD FS (Serviço de Federação do Active Directory) — usadas para fins de autorização em um aplicativo.
Os agentes do Serviço de Federação do AD FS confiam entre muitas entidades diferentes. Ele foi desenvolvido para permitir a troca confiável de declarações contendo valores arbitrários. O destinatário (por exemplo, um parceiro de recurso) depois usa essas declarações para tomar decisões de autorização.
Há três maneiras pelas quais as declarações fluem pelo Serviço de Federação:
-
Do repositório de conta para o Serviço de Federação de conta para o parceiro de recurso
-
Do parceiro de conta para o Serviço de Federação de recurso para o aplicativo do recurso.
-
Do repositório de conta para o Serviço de Federação para o aplicativo de recurso
O Serviço de Federação pode ser configurado para atuar em todos os três tipos de funções. Assim, um único Serviço de Federação pode facilitar todos os três fluxos de comunicação.
Há três tipos de declarações com suporte no Serviço de Federação: declarações de identidade, declarações de grupo e declarações personalizadas. A tabela a seguir descreve cada um desses tipos de declarações com mais detalhes.
| Tipo de declaração | Descrição |
|---|---|
|
Identidade |
UPN, email e nome comum no AD FS são referenciados como tipos de declaração de identidade:
|
|
Grupo |
Indica a participação em um grupo ou função. Os administradores definem declarações individuais com o tipo de grupo “Declarações de grupo”. Por exemplo, você pode definir o seguinte conjunto de declarações de grupo: [Desenvolvedor, Testador, Gerente de Programa]. Cada declaração de grupo é uma unidade separada de administração para o preenchimento e o mapeamento de declaração. Útil para pensar no valor de uma declaração de grupo como Booleano, indicando participação. |
|
Personalizado |
Indica uma declaração que contém informações personalizadas sobre um usuário, por exemplo, um número de identificação de funcionário. |
Se houver mais de um desses três tipos de declaração presentes em um token, as declarações de identidade serão priorizadas na seguinte ordem:
-
UPN
-
Email
-
Nome comum
Pelo menos um desses tipos de declaração de identidade deverá estar presente para que um token seja emitido.
Mapeamento de declarações
O AD FS usa o protocolo WS-F PRP (Perfil do Solicitador Passivo de WS-Federation), que contém declarações em tokens de segurança emitidos pelo Serviço de Federação. As declarações são preenchidas inicialmente dos repositórios de conta, tanto dos Serviços de Domínio Active Directory (AD DS) quanto do Active Directory Lightweight Directory Services (AD LDS).
O Serviço de Federação poderá mapear declarações quando o destino ou a origem delas for um parceiro de federação. Mapeamento de declaração é o ato de mapear, remover ou filtrar, ou transmitir declarações de entrada para declarações de saída. O mapeamento de declaração pode ser diferente para cada parceiro de federação. É importante definir o preenchimento e o mapeamento dessas declarações para a configuração da federação. Os mapeamentos de declaração usam comparações de cadeia de caracteres que diferenciam maiúsculas de minúsculas. A seguinte ilustração mostra o processo de mapeamento de declaração.
Conjuntos de declarações da organização
Todas as declarações recebidas são mapeadas para as declarações da organização. As declarações da organização são declarações no formato intermediário ou normalizado dentro de um namespace da organização. Todas as ações internas do Serviço de Federação são realizadas no conjunto de declarações da organização. As declarações da organização são consumidas por aplicativos de recurso.
Com essas declarações, não é necessário administrar individualmente os mapeamentos entre duas organizações que precisam se comunicar. Cada organização define um único mapeamento com destino ou origem nas declarações da organização. Isso reduz a complexidade administrativa do AD FS. Por exemplo, se a federação tem
x parceiros de conta
y aplicativos de recurso
a federação tem x + y mapeamentos de declaração.
Isso é reduzido de prováveis mapeamentos de declaração x × y. Como exemplo concreto, se um Serviço de Federação tem:
3 parceiros de conta
7 aplicativos de recurso
A federação precisa de apenas 10 mapeamentos de declaração, comparados aos 21 possíveis mapeamentos de declaração, quando ocorre um mapeamento diretamente das declarações de entrada para as declarações de saída.
Os tipos de declaração de email sempre são mapeados para os tipos de declaração de email. Como parte desse mapeamento, no Serviço de Federação da conta, o sufixo do domínio pode ser mapeado para um valor constante. O mapeamento do sufixo do domínio para um valor constante impede que uma organização de parceiro forneça acidentalmente informações sobre sua estrutura de floresta interna a outra organização. No Serviço de Federação do recurso, o sufixo do domínio pode ser filtrado em uma lista de valores constantes.
O exemplo a seguir descreve uma federação AD FS entre duas organizações: Tailspin Toys e Adventure Works. Neste exemplo, Tailspin Toys é o parceiro de conta e Adventure Works é o parceiro de recurso.
-
A Tailspin Toys, atuando como um Serviço de Federação da conta, mapeia a declaração de email da organização para a declaração de email de saída da Adventure Works. Como parte desse mapeamento, todos os sufixos de email são mapeados para tailspintoys.com. Determinada a declaração de email da organização (email=jsmith@sales.tailspintoys.com), a declaração de email de saída é (email=jsmith@tailspintoys.com).
-
A Adventure Works, atuando como um Serviço de Federação do recurso, mapeia a declaração de email de entrada da Tailspin Toys para a declaração de email da organização. Como parte desse mapeamento, a lista de sufixos é filtrada em tailspintoys.com. Portanto, uma declaração de email de entrada da Tailspin Toys (email=jsmith@tailspintoys.com) é aceita, mas uma declaração de email de entrada da Tailspin Toys (email=jsmith@adventure-works.com) é recusada.
UPN
Os tipos de declaração de UPN sempre mapeiam para tipos de declaração de UPN. Eles estão sujeitos a mapeamentos e filtragem de sufixo da mesma forma que as declarações de email. Entretanto, como o AD DS permite UPNs sem o símbolo @, o Serviço de Federação da conta anexará o símbolo @ seguido pelo sufixo, se houver um mapeamento de sufixo UPN definido. Caso contrário, se qualquer sufixo for transmitido, o Serviço de Federação transmite o UPN no estado atual, sem o símbolo @. No caso do recurso, se qualquer sufixo UPN for permitido, o UPN sem o símbolo @ será aceito. Caso contrário, se um sufixo UPN específico for permitido, o UPN sem o símbolo @ será recusado.
Nome comum
Os tipos de declaração de nome comum sempre são mapeados para tipos de declaração de nome comum. Eles não estão sujeitos a nenhuma outra regra.
Personalizado
Os tipos de declaração personalizada sempre são mapeados para outros tipos de declaração personalizada. Por exemplo, dados um conjunto de declarações de entrada (UPN, Personalizada=[Matrícula_do_Funcionário, ID_do_Pagador_da_Taxa]) e um conjunto de declarações da organização (UPN, Personalizada=[Funcionário, SSN]), você pode criar mapeamentos de Matrícula_do_Funcionário para Funcionário e de ID_do_Pagador_da_Taxa para SSN.
Grupo
Os tipos de declaração de grupo sempre são mapeados para outros tipos de declaração de grupo. Por exemplo, dados um conjunto de declarações de entrada (UPN, Grupo=[Um, Dois, Três]) e um conjunto de declarações da organização (UPN, Grupo=[X,Y,Z]), você pode criar mapeamentos de Um para Y, Dois para X e Três para Z.
Mapeamento de grupo para UPN
Além dos mapeamentos padrão descritos nas seções anteriores, você também pode usar um mapeamento de declaração especial de grupo para UPN. O mapeamento de declaração de grupo para UPN somente tem o suporte do Serviço de Federação do recurso quando as declarações são recebidas de um parceiro de conta. Nesse caso, os tipos de declaração de UPN não são mapeadas para tipos de declaração de UPN. Em vez disso, você fornece uma lista ordenada de mapeamentos de declaração de grupo para UPN.
Por exemplo, a lista de grupo para UPN pode ser:
-
Dev para developers@internal.tailspintoys.com
-
Test para testers@internal.tailspintoys.com
-
PM para progmgrs@internal.tailspintoys.com
Dado um conjunto de declarações de entrada (Nome comum=John Smith, Grupo=[Dev]), o conjunto de declarações da organização contém (Nome comum=John Smith, UPN=developers@internal.tailspintoys.com). Lembre-se de que a lista é ordenada. Portanto, um conjunto de declarações (Nome comum=John Smith, Grupo=[Dev,PM]) resulta em (Nome comum=John Smith, UPN=developers@internal.tailspintoys.com). Além disso, se a declaração de entrada tiver um UPN, ele será substituído. Essa regra de mapeamento particular oferece suporte especificamente às contas do recurso baseadas em grupo que acessam recursos herdados. A ordem dos mapeamentos de grupo para UPN é determinada na diretiva de confiança do Serviço de Federação.
Auditando declarações
Algumas declarações de grupo e personalizadas podem ser designadas como auditáveis. Quando a auditoria está habilitada, ela permite que o nome da declaração seja exposto no log de eventos de segurança, mas o valor da declaração é omitido. Um exemplo de declaração auditável é o Número da Previdência Social. O Número da Previdência Social do nome da declaração é exposto, mas o valor numérico real armazenado na declaração não é exposto. O valor da declaração não é auditado quando ela é produzida ou mapeada.
 | Observação |
|
Os tipos de declaração de identidade sempre são auditáveis. |