Teilen über

Ansprüche Transformation Regeln Sprache

Die Funktion zur strukturübergreifenden Umwandlung von Ansprüchen über Strukturgrenzen hinweg ermöglicht es Ihnen, Ansprüche für die dynamische Zugriffskontrolle über Strukturgrenzen hinweg zu überbrücken, indem Sie Richtlinien zur Umwandlung von Ansprüchen für strukturübergreifende Großunternehmen festlegen. Der Hauptbestandteil aller Richtlinien sind Regeln, die in der Sprache für Regeln zur Umwandlung von Ansprüchen geschrieben sind. In diesem Thema finden Sie Einzelheiten zu dieser Sprache und eine Anleitung zum Erstellen von Regeln für die Umwandlung von Ansprüchen.

Die Windows PowerShell-Cmdlets für Transformationsrichtlinien auf strukturübergreifende Großunternehmen verfügen über Optionen zum Festlegen einfacher Richtlinien, die in gängigen Szenarien erforderlich sind. Diese Cmdlets übersetzen die Benutzereingaben in Richtlinien und Regeln in der Sprache für Regeln zur Umwandlung von Ansprüchen und speichern sie dann im Active Directory im vorgeschriebenen Format. Weitere Informationen zu Cmdlets für die Umwandlung von Ansprüchen finden Sie unter AD DS-Cmdlets für dynamische Zugriffssteuerung.

Je nach Anspruchskonfiguration und den Anforderungen, die an das strukturübergreifende Großunternehmen in Ihren Active Directory-Strukturen gestellt werden, müssen Ihre Richtlinien für die Umwandlung von Ansprüchen möglicherweise komplexer sein als die Richtlinien, die von den Windows PowerShell-Cmdlets für Active Directory unterstützt werden. Um solche Richtlinien effektiv verfassen zu können, ist es wichtig, die Syntax und Semantik der Regeln für die Umwandlung von Ansprüchen zu verstehen. Diese Sprache für Regeln zur Umwandlung von Ansprüchen („die Sprache“) in Active Directory ist eine Untermenge der Sprache, die von Active Directory Federation Services für ähnliche Zwecke verwendet wird, und sie hat eine sehr ähnliche Syntax und Semantik. Es sind jedoch weniger Operationen erlaubt und die Active Directory-Version der Sprache enthält zusätzliche Syntax-Einschränkungen.

In diesem Thema werden kurz die Syntax und die Semantik der Sprache für Regeln zur Umwandlung von Ansprüchen in Active Directory sowie die Überlegungen erläutert, die beim Erstellen von Richtlinien angestellt werden müssen. Es enthält mehrere Sätze von Beispielregeln, um Ihnen den Einstieg zu erleichtern, sowie Beispiele für fehlerhafte Syntax und die daraus resultierenden Meldungen, damit Sie Fehlermeldungen entschlüsseln können, wenn Sie die Regeln verfassen.

Tools für die Erstellung von Richtlinien zur Umwandlung von Ansprüchen

Windows PowerShell Cmdlets für Active Directory: Dies ist der bevorzugte und empfohlene Weg, um Richtlinien zur Umwandlung von Ansprüchen zu erstellen und festzulegen. Diese Cmdlets bieten Weichen für einfache Richtlinien und überprüfen Regeln, die für komplexere Richtlinien festgelegt wurden.

LDAP: Richtlinien zur Umwandlung von Ansprüchen können in Active Directory über das Lightweight Directory Access Protocol (LDAP) bearbeitet werden. Dies ist jedoch nicht empfehlenswert, da die Richtlinien mehrere komplexe Komponenten haben und die von Ihnen verwendeten Tools die Richtlinie möglicherweise nicht validieren, bevor sie in Active Directory geschrieben wird. Die Diagnose von Problemen kann dann sehr viel Zeit in Anspruch nehmen.

Sprache für Regeln zur Umwandlung von Ansprüchen in Active Directory

Syntaxübersicht

Hier finden Sie einen kurzen Überblick über die Syntax und Semantik der Sprache:

  • Der Regelsatz zur Umwandlung von Ansprüchen besteht aus null oder mehr Regeln. Jede Regel verfügt über zwei aktive Teile: Liste der Auswahlbedingungen und Regelaktion. Wenn die Liste der Auswahlbedingungen auf TRUE ausgewertet wird, wird die entsprechende Regelaktion ausgeführt.

  • Liste der Auswahlbedingungen hat null oder mehr Auswahlbedingungen. Alle Auswahlbedingungen müssen auf TRUE ausgewertet werden, damit die Liste der Auswahlbedingungen auf TRUE ausgewertet werden kann.

  • Jede Auswahlbedingung hat einen Satz von null oder mehr Übereinstimmende Bedingungen. Alle Übereinstimmenden Bedingungen müssen auf TRUE ausgewertet werden, damit die Auswahlbedingungen auf TRUE ausgewertet werden kann. Alle diese Bedingungen werden mit einem einzelnen Anspruch bewertet. Ein Anspruch, der einer Auswahlbedingung entspricht, kann durch einen Bezeichnergekennzeichnet und einer Regelaktion zugeschrieben werden.

  • Jede Übereinstimmende Bedingung gibt die Bedingung an, die mit dem Typ oder Wert oder ValueType eines Anspruchs übereinstimmt, indem verschiedene Bedingungsoperatoren und Zeichenfolgenliterale verwendet werden.

    • Wenn Sie eine Übereinstimmende Bedingung für einen Wert angeben, müssen Sie auch eine Übereinstimmende Bedingung für einen bestimmten ValueType angeben und umgekehrt. Diese Bedingungen müssen in der Syntax nebeneinander stehen.

    • Übereinstimmende ValueType-Bedingungen dürfen nur bestimmte ValueType-Literale verwenden.

  • Eine Regelaktion kann einen Anspruch kopieren, der mit einem Bezeichner gekennzeichnet ist, oder einen Anspruch auf der Grundlage eines Anspruchs ausgeben, der mit einem Bezeichner gekennzeichnet und/oder mit Zeichenfolgenliteralen versehen ist.

Beispiel einer Regel

Dieses Beispiel zeigt eine Regel, die verwendet werden kann, um die Schadenart zwischen zwei Strukturen zu übersetzen, vorausgesetzt, sie verwenden dieselben ValueType-Ansprüche und haben dieselben Interpretationen für die Werte dieser Art einzufordern. Die Regel verfügt über eine übereinstimmende Bedingung und eine Issue-Anweisung, die Zeichenfolgenliterale und einen übereinstimmenden Anspruchsverweis verwendet.

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.

Laufzeitvorgang

Es ist wichtig, die Funktionsweise von Anspruchsumwandlungen zur Laufzeit zu verstehen, um die Regeln effektiv erstellen zu können. Der Laufzeitvorgang verwendet drei Sätze von Ansprüchen:

  1. Eingabeanspruchssatz: Der Eingabesatz von Ansprüchen, die dem Vorgang zur Umwandlung von Ansprüchen zugewiesen werden.

  2. Arbeitsanspruchssatz: Zwischenansprüche, die während der Umwandlung von Ansprüchen gelesen und in diese geschrieben werden.

  3. Ausgabeanspruchssatz: Ausgabe des Vorgangs zur Umwandlung von Ansprüchen.

Hier finden Sie einen kurzen Überblick über die Umwandlung von Ansprüchen zur Laufzeit:

  1. Eingabeansprüche für die Umwandlung von Ansprüchen werden zur Initialisierung des Arbeitsanspruchssatzes verwendet.

    1. Bei der Verarbeitung jeder Regel wird das Arbeitsanspruchssatz für die Eingabeansprüche verwendet.

    2. Die Liste der Auswahlbedingungen in einer Regel wird mit allen möglichen Anspruchsgruppen aus dem Arbeitsanspruchssatz abgeglichen.

    3. Jeder Satz von übereinstimmenden Ansprüchen wird verwendet, um die Aktion in dieser Regel auszuführen.

    4. Die Ausführung einer Regelaktion führt zu einem Anspruch, der an den Satz der Ausgabeansprüche und den Satz der Arbeitsansprüche angehängt wird. So wird die Ausgabe einer Regel als Eingabe für nachfolgende Regeln im Regelsatz verwendet.

  2. Die Regeln im Regelsatz werden nacheinander abgearbeitet, beginnend mit der ersten Regel.

  3. Wenn der gesamte Regelsatz verarbeitet wurde, wird der ausgegebene Anspruchssatz verarbeitet, um doppelte Ansprüche und andere Sicherheitsfragen zu entfernen. Die daraus resultierenden Ansprüche sind das Ergebnis des Umwandlungsprozesses von Ansprüchen.

Es ist möglich, komplexe Umwandlungen von Ansprüchen auf der Grundlage des bisherigen Laufzeitverhaltens zu schreiben.

Beispiel: Laufzeitvorgang

Dieses Beispiel zeigt den Laufzeitvorgang einer Umwandlung von Ansprüchen, die zwei Regeln verwendet.


     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")}

Semantik von Sonderregeln

Es folgt eine spezielle Syntax für Regeln:

  1. Leerer Regelsatz == Keine Ausgabeansprüche

  2. Leere Liste der Auswahlbedingungen == Jeder Anspruch entspricht der Liste der Auswahlbedingungen

    Beispiel: Leere Liste der Auswahlbedingungen

    Die folgende Regel entspricht jedem Anspruch im Arbeitssatz.

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

  3. Leere Liste der Übereinstimmenden Bedingungen == Jeder Anspruch entspricht der Liste der Auswahlbedingungen

    Beispiel: Leerstehende Übereinstimmende Bedingungen

    Die folgende Regel entspricht jedem Anspruch im Arbeitssatz. Dies ist die Grundregel „Alle zulassen“, wenn sie allein verwendet wird.

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

Sicherheitshinweise

Ansprüche, die in eine Gesamtstruktur eingehen

Die von den Auftraggebern eingereichten Anträge, die in eine Gesamtstruktur eingehen, müssen gründlich geprüft werden, um sicherzustellen, dass wir nur die richtigen Anträge zulassen oder ausstellen. Ungeeignete Claims können die Sicherheit der Gesamtstruktur gefährden. Dies sollte bei der Erstellung von Richtlinien zur Umwandlung von Ansprüchen, die in eine Gesamtstruktur eingehen, unbedingt berücksichtigt werden.

Active Directory verfügt über die folgenden Funktionen, um eine Fehlkonfiguration von Ansprüchen zu verhindern, die in eine Gesamtstruktur eingehen:

  • Wenn für eine Gesamtstruktur eines Großunternehmens keine Richtlinie zur Umwandlung von Ansprüchen festgelegt ist, die in eine Gesamtstruktur eingehen, lässt Active Directory aus Sicherheitsgründen alle Hauptansprüche fallen, die in die Gesamtstruktur eingehen.

  • Wenn die Ausführung des Regelsatzes für Ansprüche, die in eine Gesamtstruktur eingehen, zu Ansprüchen führt, die nicht in der Gesamtstruktur definiert sind, werden die undefinierten Ansprüche aus den ausgegebenen Ansprüchen entfernt.

Ansprüche, die eine Gesamtstruktur verlassen

Ansprüche, die eine Gesamtstruktur verlassen, stellen ein geringeres Sicherheitsrisiko für die Gesamtstruktur dar als die Ansprüche, die in die Gesamtstruktur eingehen. Ansprüche dürfen die Gesamtstruktur unverändert verlassen, auch wenn es keine entsprechende Richtlinie zur Umwandlung von Ansprüchen gibt. Es ist auch möglich, im Rahmen der Umwandlung von Ansprüchen, die die Gesamtstruktur verlassen, Ansprüche zu vergeben, die nicht in der Gesamtstruktur definiert sind. Damit können Sie ganz einfach strukturübergreifende Großunternehmen mit Ansprüchen einrichten. Ein Administrator kann ermitteln, ob Ansprüche, die in die Gesamtstruktur eingehen, umgewandelt werden müssen, und die entsprechende Richtlinie einrichten. Ein Administrator könnte beispielsweise eine Richtlinie festlegen, wenn ein Anspruch ausgeblendet werden muss, um die Offenlegung von Informationen zu verhindern.

Syntaxfehler in Regeln zur Umwandlung von Ansprüchen

Wenn eine bestimmte Richtlinie für die Umwandlung von Ansprüchen einen Regelsatz enthält, der syntaktisch falsch ist, oder wenn es andere Syntax- oder Speicherprobleme gibt, wird die Richtlinie als ungültig betrachtet. Dies wird anders behandelt als die bereits erwähnten Standardbedingungen.

Active Directory ist in diesem Fall nicht in der Lage, die Absicht zu bestimmen und wechselt in einen Fail-Safe-Modus, in dem keine Ausgabeansprüche bei der Traversierung für dieses Großunternehmen+Leitung generiert werden. Ein Eingriff des Administrators ist erforderlich, um das Problem zu beheben. Dies kann passieren, wenn LDAP zur Bearbeitung der Richtlinie zur Umwandlung von Ansprüchen verwendet wird. Windows PowerShell-Cmdlets für Active Directory verfügen über eine Validierung, um das Schreiben einer Richtlinie mit Syntaxproblemen zu verhindern.

Erwägungen zu anderen Sprachen

  1. Es gibt einige Schlüsselwörter oder Zeichen, die in dieser Sprache besonders sind (als Terminals bezeichnet). Diese werden in der Tabelle Sprachterminals weiter unten in diesem Thema vorgestellt. Die Fehlermeldungen verwenden die Tags für diese Terminals zur Unterscheidung.

  2. Terminals können manchmal als Zeichenfolgenliterale verwendet werden. Eine solche Verwendung kann jedoch mit der Sprachdefinition in Konflikt stehen oder unbeabsichtigte Folgen haben. Diese Art der Verwendung wird nicht empfohlen.

  3. Die Regelaktion kann keine Typkonvertierungen bei einfordern von Werten durchführen und ein Regelsatz, der eine solche Regelaktion enthält, wird als ungültig betrachtet. Dies würde zu einem Laufzeitfehler führen, und es werden keine Ausgabeansprüche erstellt.

  4. Wenn eine Regelaktion auf einen Bezeichner verweist, der im Abschnitt der Regel „Liste Auswahlbedingung“ nicht verwendet wurde, ist dies eine ungültige Verwendung. Dies würde einen Syntaxfehler verursachen.

    Beispiel: Falscher Bezeichnerverweis Die folgende Regel veranschaulicht einen falschen Bezeichner, der in der Regelaktion verwendet wird.

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

Regeln für die Umwandlung von Ansprüchen

  • Alle Ansprüche eines bestimmten Typs zulassen

    Exakter Typ

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

    Verwendung von Regex

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

  • Eine bestimmte Anspruchsart nicht zulassen Exakter Typ

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

    Verwendung von Regex

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

Beispiele für Fehler im Regelparser

Die Regeln zur Umwandlung von Ansprüchen werden von einem benutzerdefinierten Parser geparst, um auf Syntaxfehler zu prüfen. Dieser Parser wird von den entsprechenden Windows PowerShell-Cmdlets ausgeführt, bevor die Regeln in Active Directory gespeichert werden. Alle Fehler beim Parsen der Regeln, einschließlich Syntaxfehler, werden auf der Konsole ausgegeben. Domänencontroller führen auch den Parser aus, bevor sie die Regeln zur Umwandlung von Ansprüchen verwenden, und sie protokollieren Fehler im Ereignisprotokoll (fügt Ereignisprotokollnummern hinzu).

In diesem Abschnitt finden Sie einige Beispiele für Regeln, die mit falscher Syntax geschrieben wurden, und die entsprechenden Syntaxfehler, die vom Parser erzeugt werden.

  1. Beispiel:

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

    Dieses Beispiel enthält ein falsches Semikolon anstelle eines Doppelpunkts. Fehlermeldung:POLICY0002: Richtliniendaten konnten nicht geparst werden.Zeilennummer: 1, Spaltennummer: 2, Fehlertoken: ;. Zeile: 'c1; []=>Issue(claim=c1);'.Parserfehler: 'POLICY0030: Syntaxfehler, unerwartet ';', erwartet eine der folgenden: ':' .'

  2. Beispiel:

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

    In diesem Beispiel ist das Tag „Bezeichner“ in der Anweisung zur Ausgabe von Kopien nicht definiert. Fehlermeldung: POLICY0011: Keine Bedingungen in der Anspruchsregel entsprechen dem Bedingungstag, das im CopyIssuanceStatement angegeben ist: 'c2'.

  3. Beispiel:

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

    "bool" ist kein Terminal in der Sprache und kein gültiger ValueType. Gültige Terminals werden in der folgenden Fehlermeldung aufgeführt. Fehlermeldung:POLICY0002: Richtliniendaten konnten nicht geparst werden. Zeilennummer: 1, Spaltennummer: 39, Fehlertoken: "bool". Zeile: 'c1:[type=="x1", value=="1",valuetype=="bool"]=>Issue(claim=c1);'. Parserfehler: 'POLICY0030: Syntaxfehler, unerwartet 'STRING', erwartet eine der folgenden: 'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'IDENTIFIER'

  4. Beispiel:

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

    Die Zahl 1 in diesem Beispiel ist kein gültiges Token in der Sprache, und eine solche Verwendung ist in einer übereinstimmenden Bedingung nicht zulässig. Es muss in doppelte Anführungszeichen eingeschlossen werden, um es zu einer Zeichenfolge zu machen. Fehlermeldung:POLICY0002: Richtliniendaten konnten nicht geparst werden.Zeilennummer: 1, Spaltennummer: 23, Fehlertoken: 1. Zeile: 'c1:[type=="x1", value==1, valuetype=="bool"]=>Issue(claim=c1);'.Parserfehler: 'POLICY0029: Unerwartete Eingabe.

  5. Beispiel:

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

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

    In diesem Beispiel wurde ein doppeltes Gleichheitszeichen (==) anstelle eines einzelnen Gleichheitszeichens (=) verwendet. Fehlermeldung:POLICY0002: Richtliniendaten konnten nicht geparst werden.Zeilennummer: 1, Spaltennummer: 91, Fehlertoken: ==. Zeile: 'c1:[type=="x1", value=="1",valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype=="boolean");'.Parserfehler: 'POLICY0030: Syntaxfehler, unerwartet '==', erwartet eine der folgenden: '='

  6. Beispiel:

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

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

    Dieses Beispiel ist syntaktisch und semantisch richtig. Die Verwendung von "boolean" als Zeichenfolgenwert führt jedoch zu Verwirrung und sollte vermieden werden. Wie bereits erwähnt, sollte die Verwendung von Sprachterminals als Werte für Ansprüche möglichst vermieden werden.

Sprachterminals

In der folgenden Tabelle finden Sie den vollständigen Satz von Terminalstrings und die zugehörigen Sprachterminals, die in der Sprache der Regel zur Umwandlung von Ansprüchen verwendet werden. Diese Definitionen verwenden UTF-16-Zeichenfolgen, die Groß- und Kleinschreibung nicht berücksichtigen.

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" PROBLEM
"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

Sprachsyntax

Die folgende Sprache für Regeln zur Umwandlung von Ansprüchen ist im ABNF-Format angegeben. Diese Definition verwendet zusätzlich zu den hier definierten ABNF-Produktionen die Terminals, die in der vorherigen Tabelle angegeben sind. Die Regeln müssen in UTF-16 kodiert sein und die String-Vergleiche müssen ohne Berücksichtigung der Groß- und Kleinschreibung behandelt werden.

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