Partilhar via

Linguagem das regras de transformação de afirmações

O recurso de transformação de declarações entre florestas permite que você faça a ponte entre declarações para o Controle de Acesso Dinâmico através dos limites da floresta, definindo políticas de transformação de declarações em relações de confiança entre florestas. O componente principal de todas as políticas são as regras escritas na linguagem de regras de transformação de declarações. Este tópico fornece detalhes sobre essa linguagem e fornece orientação sobre a criação de regras de transformação de declarações.

Os cmdlets do Windows PowerShell para políticas de transformação em relações de confiança entre florestas têm opções para definir políticas simples que são necessárias em cenários comuns. Esses cmdlets convertem a entrada do usuário em políticas e regras no idioma das regras de transformação de declarações e, em seguida, armazenam-nas no Ative Directory no formato prescrito. Para mais informações sobre cmdlets relacionados à transformação de declarações, consulte Cmdlets do AD DS para Controle de Acesso Dinâmico.

Dependendo da configuração de atribuições e dos requisitos colocados na confiança entre florestas nas suas florestas do Active Directory, as suas políticas de transformação de atribuições podem ter de ser mais complexas do que as políticas suportadas pelos cmdlets do Windows PowerShell para Active Directory. Para criar efetivamente tais políticas, é essencial compreender as regras de transformação de declarações, sintaxe da linguagem e semântica. Essa linguagem de regras de transformação de declarações ("o idioma") no Ative Directory é um subconjunto da linguagem usada pelos Serviços de Federação do Ative Directory para fins semelhantes e tem uma sintaxe e semântica muito semelhantes. No entanto, há menos operações permitidas e restrições de sintaxe adicionais são colocadas na versão do Ative Directory do idioma.

Este tópico explica brevemente a sintaxe e a semântica da linguagem de regras de transformação de declarações no Ative Directory e as considerações a serem feitas ao criar políticas. Ele fornece vários conjuntos de regras de exemplo para você começar, e exemplos de sintaxe incorreta e as mensagens que elas geram, para ajudá-lo a decifrar mensagens de erro quando você cria as regras.

Ferramentas para criar políticas de transformação de declarações

Cmdlets do Windows PowerShell para Active Directory: esta é a maneira preferida e recomendada de criar e definir políticas de transformação de reivindicações. Esses cmdlets fornecem opções para políticas simples e verificam regras definidas para políticas mais complexas.

LDAP: As políticas de transformação de declarações podem ser editadas no Active Directory através do Lightweight Directory Access Protocol (LDAP). No entanto, isso não é recomendado porque as políticas têm vários componentes complexos e as ferramentas que você usa podem não validar a política antes de gravá-la no Ative Directory. Isto pode, subsequentemente, exigir um tempo considerável para diagnosticar problemas.

Linguagem das regras de transformação de declarações do Ative Directory

Visão geral da sintaxe

Aqui está uma breve visão geral da sintaxe e semântica da linguagem:

  • O conjunto de regras de transformação de declarações consiste em zero ou mais regras. Cada regra tem duas partes ativas: Selecionar Lista de Condições e Ação da Regra. Se a lista Selecionar condição for avaliada como TRUE, a ação da regra correspondente será executada.

  • Lista de Condições de Seleção tem zero ou mais Condições de Seleção. Todas as condições de seleção devem ser avaliadas como TRUE para que a lista de condições selecionadas seja avaliada como TRUE.

  • Cada Condição de Seleção tem um conjunto de zero ou mais Condições Correspondentes. Todas as Condições de Correspondência devem ser avaliadas como TRUE para que a Condição de Seleção seja avaliada como TRUE. Todas estas condições são avaliadas em relação a um único pedido. Uma declaração que corresponda a uma Condição de Seleção pode ser marcada por um Identificador e referida na Ação de Regra.

  • Cada Condição de Correspondência especifica a condição para corresponder ao Tipo ou Valor ou ValueType de uma declaração usando diferentes Operadores de Condição e Literais de Cadeia de Caracteres.

    • Ao especificar uma Condição Correspondente para um Valor, você também deve especificar uma Condição Correspondente para um ValueType específico e vice-versa. Essas condições devem estar próximas umas das outras na sintaxe.

    • As condições de correspondência de ValueType devem usar apenas literais específicos de ValueType.

  • Uma Ação de Regra pode copiar uma declaração marcada com um Identificador ou emitir uma declaração com base em uma declaração marcada com um Identificador e/ou Literais de Cadeia de Caracteres.

Exemplo de regra

Este exemplo mostra uma regra que pode ser usada para traduzir os tipos de reivindicações entre duas florestas, desde que utilizem os mesmos Tipos de Valor de reivindicações e tenham as mesmas interpretações para os valores de reivindicações deste tipo. A regra tem uma condição correspondente e uma instrução de problema que utiliza literais de string e uma referência correspondente de reivindicações.

C1: [TYPE=="EmployeeType"]
                 => ISSUE (TYPE= "EmpType", VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE);
[TYPE=="EmployeeType"] == Select Condition List with one Matching Condition for claims Type.
ISSUE (TYPE= "EmpType", VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE) == Rule Action that issues a claims using string literal and matching claim referred with the Identifier.

Operação de tempo de execução

É importante entender a operação de tempo de execução das transformações de declarações para criar as regras de forma eficaz. A operação de tempo de execução usa três conjuntos de declarações:

  1. Conjunto de declarações de entrada: o conjunto de declarações de entrada que são dadas à operação de transformação de declarações.

  2. Conjunto de declarações de trabalho: declarações intermediárias que são lidas e gravadas durante a transformação de declarações.

  3. Conjunto de declarações de saída: Saída da operação de transformação de declarações.

Aqui está uma breve visão geral da operação de transformação de reivindicações em execução:

  1. As declarações de entrada para transformação são usadas para inicializar o conjunto de declarações em processamento.

    1. Ao processar cada regra, o conjunto de declarações de trabalho é usado para as declarações de entrada.

    2. A Lista de Condições de Seleção numa regra é comparada com todos os conjuntos possíveis de declarações do conjunto de declarações em uso.

    3. Cada conjunto de declarações correspondentes é usado para executar a ação nessa regra.

    4. A execução de uma ação de regra resulta em uma declaração, que é anexada ao conjunto de declarações de saída e ao conjunto de declarações de trabalho. Assim, a saída de uma regra é usada como entrada para regras subsequentes no conjunto de regras.

  2. As regras no conjunto de regras são processadas em ordem sequencial começando com a primeira regra.

  3. Quando todo o conjunto de regras é processado, o conjunto de declarações de saída é processado para remover declarações duplicadas e para outros problemas de segurança. As declarações resultantes são a saída do processo de transformação de declarações.

É possível escrever transformações de declarações complexas com base no comportamento de tempo de execução anterior.

Exemplo: operação em tempo de execução

Este exemplo mostra a operação em tempo de execução de uma transformação de reivindicações que usa duas regras.


     C1:[Type=="EmpType", Value=="FullTime",ValueType=="string"] =>
                Issue(Type=="EmployeeType", Value=="FullTime",ValueType=="string");
     [Type=="EmployeeType"] =>
               Issue(Type=="AccessType", Value=="Privileged", ValueType=="string");
Input claims and Initial Evaluation Context:
  {(Type= "EmpType"),(Value="FullTime"),(ValueType="String")}
{(Type= "Organization"),(Value="Marketing"),(ValueType="String")}
After Processing Rule 1:
 Evaluation Context:
  {(Type= "EmpType"),(Value="FullTime"),(ValueType="String")}
{(Type= "Organization"), (Value="Marketing"),(ValueType="String")}
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
Output Context:
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}

After Processing Rule 2:
Evaluation Context:
  {(Type= "EmpType"),(Value="FullTime"),(ValueType="String")}
{(Type= "Organization"),(Value="Marketing"),(ValueType="String")}
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
  {(Type= "AccessType"),(Value="Privileged"),(ValueType="String")}
Output Context:
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
  {(Type= "AccessType"),(Value="Privileged"),(ValueType="String")}

Final Output:
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
  {(Type= "AccessType"),(Value="Privileged"),(ValueType="String")}

Semântica de regras especiais

A sintaxe especial para as regras é a seguinte:

  1. Conjunto de regras vazio == Sem afirmações de saída

  2. Lista de Condição de Seleção Vazia == Cada Reivindicação satisfaz a Lista de Condição de Seleção

    Exemplo: Lista de Condição de Seleção Vazia

    A seguinte regra corresponde a cada reclamação no conjunto de dados.

    => Issue (Type = "UserType", Value = "External", ValueType = "string")

  3. Lista de Correspondência de Seleção Vazia == Cada declaração corresponde à Lista de Condição de Seleção

    Exemplo: Condições de correspondência vazias

    A seguinte regra corresponde a cada reclamação no conjunto de dados. Esta é a regra básica "Permitir-tudo" se usada sozinha.

    C1:[] => Issule (claim = C1);

Considerações de segurança

Declarações que entram em uma floresta

As declarações apresentadas pelos principais que estão a entrar numa floresta precisam ser inspecionadas minuciosamente para garantir que permitamos ou emitamos apenas as declarações corretas. Declarações impróprias podem comprometer a segurança florestal, e isso deve ser uma das principais considerações ao criar políticas de transformação para reivindicações que entram em uma floresta.

O Ative Directory tem os seguintes recursos para evitar a configuração incorreta de declarações que entram em uma floresta:

  • Se um trust de floresta não tiver uma política de transformação de reivindicações definida para as reivindicações que entram numa floresta, por motivos de segurança, o Active Directory elimina todas as reivindicações principais que entrarem na floresta.

  • Se a execução do conjunto de regras em declarações que entram em uma floresta resultar em declarações que não estão definidas na floresta, as declarações indefinidas serão descartadas das declarações de saída.

Reclamações que abandonam uma floresta

As reivindicações que saem de uma floresta apresentam uma preocupação de segurança menor para a floresta do que as reivindicações que entram na floresta. As reivindicações podem sair da floresta as-is mesmo quando não há uma política de transformação de reivindicações correspondente em vigor. Também é possível emitir reivindicações que não são definidas na floresta como parte da transformação de reivindicações que saem da floresta. Isso é para configurar facilmente relações de confiança entre florestas com declarações. Um administrador pode determinar se as declarações que entram na floresta precisam ser transformadas e configurar a política apropriada. Por exemplo, um administrador pode definir uma política se houver necessidade de ocultar uma declaração para impedir a divulgação de informações.

Erros de sintaxe em regras de transformação de declarações

Se uma determinada política de transformação de declarações tiver um conjunto de regras sintaticamente incorreta ou se houver outros problemas de sintaxe ou armazenamento, a política será considerada inválida. Isso é tratado de forma diferente das condições padrão mencionadas anteriormente.

O Ative Directory não consegue determinar a intenção nesse caso e entra em um modo à prova de falhas, onde nenhuma declaração de saída é gerada nessa confiança+direção de travessia. A intervenção do administrador é necessária para corrigir o problema. Isso pode acontecer se o LDAP for usado para editar a política de transformação de declarações. Os cmdlets do Windows PowerShell para Ative Directory têm validação para evitar a escrita de uma política com problemas de sintaxe.

Outras considerações linguísticas

  1. Existem várias palavras-chave ou caracteres que são especiais nesta língua (referidos como terminais). Estes são apresentados na tabela Terminais de idioma mais adiante neste tópico. As mensagens de erro usam as tags para esses terminais para desambiguação.

  2. Os terminais às vezes podem ser usados como literais de cadeia de caracteres. No entanto, tal uso pode entrar em conflito com a definição da língua ou ter consequências não intencionais. Este tipo de uso não é recomendado.

  3. A ação de regra não pode executar conversões de tipo em Valores de declaração, e um conjunto de regras que contenha essa ação de regra é considerado inválido. Isso causaria um erro de tempo de execução e nenhuma declaração de saída é produzida.

  4. Se uma ação de regra se referir a um Identificador que não foi usado na lista de condições de seleção da regra, isso será um uso inválido. Isso causaria um erro de sintaxe.

    Exemplo: Referência de identificador incorreta A regra a seguir ilustra um Identificador incorreto usado na ação da regra.

    C1:[] => Issue (claim = C2);

Exemplo de regras de transformação

  • Permitir todas as declarações de um determinado tipo

    Tipo exato

    C1:[type=="XYZ"] => Issue (claim = C1);

    Usando o Regex

    C1: [type =~ "XYZ*"] => Issue (claim = C1);

  • Não permitir um determinado tipo de reivindicação Tipo exato

    C1:[type != "XYZ"] => Issue (claim=C1);

    Usando o Regex

    C1:[Type !~ "XYZ?"] => Issue (claim=C1);

Exemplos de erros do analisador de regras

As regras de transformação de declarações são analisadas por um analisador personalizado para verificar se há erros de sintaxe. Esse analisador é executado por cmdlets relacionados do Windows PowerShell antes de armazenar regras no Ative Directory. Quaisquer erros na análise das regras, incluindo erros de sintaxe, são impressos no console. Os controladores de domínio também executam o analisador antes de usar as regras para transformar declarações e registram erros no log de eventos (adicionar números de log de eventos).

Esta seção ilustra alguns exemplos de regras escritas com sintaxe incorreta e os erros de sintaxe correspondentes gerados pelo analisador.

  1. Example:

    c1;[]=>Issue(claim=c1);

    Este exemplo tem um ponto-e-vírgula usado incorretamente no lugar de dois pontos. Mensagem de erro:POLICY0002: Não foi possível analisar dados de política.Número da linha: 1, Número da coluna: 2, Símbolo de erro: ;. Linha: «c1; []=>Questão(reivindicação=c1);».Erro do analisador: 'POLICY0030: Erro de sintaxe, inesperado ';', esperando um dos seguintes: ':' .'

  2. Example:

    c1:[]=>Issue(claim=c2);

    Neste exemplo, a marca Identifier na instrução de emissão de cópia é indefinida. Mensagem de erro: POLICY0011: Nenhuma condição na regra de declaração corresponde à marca de condição especificada na CopyIssuanceStatement: 'c2'.

  3. Example:

    c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)

    "bool" não é um Terminal no idioma e não é um ValueType válido. Terminais válidos estão listados na seguinte mensagem de erro. Mensagem de erro:POLICY0002: Não foi possível analisar dados de política. Número da linha: 1, Número da coluna: 39, Símbolo de erro: "bool". Linha: 'c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1);'. Erro do analisador: 'POLICY0030: Erro de sintaxe, 'STRING' inesperado, esperando um dos seguintes: 'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'IDENTIFIER'

  4. Example:

    c1:[type=="x1", value==1, valuetype=="boolean"]=>Issue(claim=c1);

    O numeral 1 neste exemplo não é um token válido no idioma, e tal uso não é permitido em uma condição correspondente. Ele tem que ser colocado entre aspas duplas para torná-lo uma cadeia de caracteres. Mensagem de erro:POLICY0002: Não foi possível analisar dados de política.Número da linha: 1, Número da coluna: 23, Símbolo de erro: 1. Linha: 'c1:[type=="x1", value==1, valuetype=="bool"]=>Issue(claim=c1);'.Erro do analisador: 'POLICY0029: Entrada inesperada.

  5. Example:

    c1:[type == "x1", value == "1", valuetype == "boolean"] =>

     Issue(type = c1.type, value="0", valuetype == "boolean");

    Este exemplo usou um sinal de igual duplo (==) em vez de um único sinal de igual (=). Mensagem de erro:POLICY0002: Não foi possível analisar os dados de política.Número da linha: 1, Número da coluna: 91, Token de erro: ==. Linha: 'c1:[type=="x1", value=="1",valuetype=="booleano"]=>Issue(type=c1.type, value="0", valuetype=="booleano");'.Erro do analisador: 'POLICY0030: Erro de sintaxe, inesperado '==', esperando um dos seguintes: '='

  6. Example:

    c1:[type=="x1", value=="boolean", valuetype=="string"] =>

      Issue(type=c1.type, value=c1.value, valuetype = "string");

    Este exemplo é sintaticamente e semanticamente correto. No entanto, usar "booleano" como um valor de string é propenso a causar confusão e deve ser evitado. Como mencionado anteriormente, o uso de terminais linguísticos como valores de sinistros deve ser evitado sempre que possível.

Terminais linguísticos

A tabela a seguir lista o conjunto completo de cadeias de caracteres de terminal e os terminais de idioma associados que são usados no idioma de regras de transformação de declarações. Essas definições usam cadeias de caracteres UTF-16 que não diferenciam maiúsculas de minúsculas.

String Terminal
=> IMPLY
";" SEMICOLON
":" COLON
"," COMMA
"." DOT
"[" O_SQ_BRACKET
"]" C_SQ_BRACKET
"(" O_BRACKET
")" C_BRACKET
"==" EQ
"!=" NEQ
"=~" REGEXP_MATCH
"!~" REGEXP_NOT_MATCH
"=" ASSIGN
"&&" AND
"issue" ISSUE
"type" TYPE
"value" VALUE
"valuetype" VALUE_TYPE
"claim" CLAIM
"[_A-Za-z][_A-Za-z0-9]*" IDENTIFIER
"\"[^\"\n]*\"" STRING
"uint64" UINT64_TYPE
"int64" INT64_TYPE
"string" STRING_TYPE
"boolean" BOOLEAN_TYPE

Sintaxe da linguagem

A linguagem das regras de transformação de declarações a seguir é especificada no formulário ABNF. Esta definição utiliza os terminais especificados na tabela anterior, além das produções da ABNF aqui definidas. As regras devem ser codificadas em UTF-16 e as comparações de cadeia de caracteres devem ser tratadas como insensíveis a maiúsculas e minúsculas.

Rule_set        = ;/*Empty*/
             / Rules
Rules         = Rule
             / Rule Rules
Rule          = Rule_body
Rule_body       = (Conditions IMPLY Rule_action SEMICOLON)
Conditions       = ;/*Empty*/
             / Sel_condition_list
Sel_condition_list   = Sel_condition
             / (Sel_condition_list AND Sel_condition)
Sel_condition     = Sel_condition_body
             / (IDENTIFIER COLON Sel_condition_body)
Sel_condition_body   = O_SQ_BRACKET Opt_cond_list C_SQ_BRACKET
Opt_cond_list     = /*Empty*/
             / Cond_list
Cond_list       = Cond
             / (Cond_list COMMA Cond)
Cond          = Value_cond
             / Type_cond
Type_cond       = TYPE Cond_oper Literal_expr
Value_cond       = (Val_cond COMMA Val_type_cond)
             /(Val_type_cond COMMA Val_cond)
Val_cond        = VALUE Cond_oper Literal_expr
Val_type_cond     = VALUE_TYPE Cond_oper Value_type_literal
claim_prop       = TYPE
             / VALUE
Cond_oper       = EQ
             / NEQ
             / REGEXP_MATCH
             / REGEXP_NOT_MATCH
Literal_expr      = Literal
             / Value_type_literal

Expr          = Literal
             / Value_type_expr
             / (IDENTIFIER DOT claim_prop)
Value_type_expr    = Value_type_literal
             /(IDENTIFIER DOT VALUE_TYPE)
Value_type_literal   = INT64_TYPE
             / UINT64_TYPE
             / STRING_TYPE
             / BOOLEAN_TYPE
Literal        = STRING
Rule_action      = ISSUE O_BRACKET Issue_params C_BRACKET
Issue_params      = claim_copy
             / claim_new
claim_copy       = CLAIM ASSIGN IDENTIFIER
claim_new       = claim_prop_assign_list
claim_prop_assign_list = (claim_value_assign COMMA claim_type_assign)
             /(claim_type_assign COMMA claim_value_assign)
claim_value_assign   = (claim_val_assign COMMA claim_val_type_assign)
             /(claim_val_type_assign COMMA claim_val_assign)
claim_val_assign    = VALUE ASSIGN Expr
claim_val_type_assign = VALUE_TYPE ASSIGN Value_type_expr
Claim_type_assign   = TYPE ASSIGN Expr
  • Last updated on