Политика XACML. Применить функцию string-subset, дающую неожиданный результат
Я использую балану скачанную с git. Я работаю над правилом политики, которое должно разрешать только если строковый пакет политики является подмножеством соответствующих атрибутов в запросе. Например. Запрос содержит атрибуты "letter=a, letter=b"и policy использует строковое подмножество для сравнения набора буквенных атрибутов из запроса со строковым пакетом. Я пробовал оба порядка подмножества (подмножество строкового мешка против подмножества строкового мешка), но они оба возвращаются с "Permit"когда мой тест-запрос должен быть получен"Deny".
Пример политики
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="policy1"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides" Version="1.0">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
myguid0123456789
</AttributeValue>
<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true" />
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule Effect="Deny" RuleId="securityLevel">
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-greater-than">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-one-and-only">
<AttributeDesignator AttributeId="securityLevel" Category="tags" DataType="http://www.w3.org/2001/XMLSchema#integer" MustBePresent="true" />
</Apply>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">
9000
</AttributeValue>
</Apply>
</Condition>
<AdviceExpressions>
<AdviceExpression AdviceId="channel-security-too-low" AppliesTo="Deny">
<AttributeAssignmentExpression AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:text">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
Message security is over 9000! It's not good cap'n, I cannae make it go any faster!
</AttributeValue>
</AttributeAssignmentExpression>
</AdviceExpression>
</AdviceExpressions>
</Rule>
<Rule Effect="Permit" RuleId="caveats">
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-subset">
<AttributeDesignator AttributeId="caveats" Category="tags" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true" />
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
A
</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
B
</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
C
</AttributeValue>
</Apply>
</Apply>
</Condition>
<AdviceExpressions>
<AdviceExpression AdviceId="data-caveat-not-on-channel" AppliesTo="Deny">
<AttributeAssignmentExpression AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:text">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
caveat advice fail
</AttributeValue>
</AttributeAssignmentExpression>
</AdviceExpression>
</AdviceExpressions>
</Rule>
<Rule RuleId="permit-rule" Effect="Permit" />
</Policy>
И я передаю этот запрос на тестирование:
Запрос
<Request xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" CombinedDecision="false" ReturnPolicyIdList="true">
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" IncludeInResult="true">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
send
</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" IncludeInResult="true">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
99991699
</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="true">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
myguid0123456789
</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="tags">
<Attribute AttributeId="securityLevel" IncludeInResult="true">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#integer">
8000
</AttributeValue>
</Attribute>
<Attribute AttributeId="caveats" IncludeInResult="true">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
A
</AttributeValue>
</Attribute>
<Attribute AttributeId="caveats" IncludeInResult="true">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
B
</AttributeValue>
</Attribute>
</Attributes>
</Request>
Итак, мое мышление (потому что я не уверен, что могу сказать, что это отрицание) таково, что
- оно неявно связывает отрицательное совпадение условия с отрицанием эффекта.
Если это правда, моя интуиция состоит в том, что соответствующее подмножество, которое в порядке, должно сказать "Разрешить", но затем, если оно не соответствует условию, оно вместо этого скажет "Запретить".
Поскольку нет целевого оператора, моя интуиция заключается в том, что он "должен" попытаться оценить это условие для всех запросов, поэтому несоответствие условию не должно приводить к пропуску правила.
В любом случае, глядя на образец, я хочу сказать, что "моя политика принимает A,B, но у вас есть A,B,C, поэтому я должен отказать вам". К сожалению, это не то, что он делает, и я не уверен, почему. Пожалуйста помоги. x_x
1 ответ
У вас есть несколько вопросов в вашей политике и запросе.
Прежде всего, в XML и XACML <element>value</element> это не то же самое, что
<element>
value
</element>
Если вы отправляете свои запросы как таковые и ваши политики хранятся как таковые, то значения, которые вы проверяете, ' A ', ' B ' и так далее. Это будет проблемой.
Во-вторых, вы используете алгоритм объединения запрета-переопределения с вашей политикой P. P содержит 3 правила R1, R2 и R3. R1 является правилом отказа. Если это применимо, то deny возвращается и R2 и R3 рассматриваться не будут. Если R1 не применяется, то PDP переходит к R2 и R3. Если R2 применяется, то возможное решение - Разрешить, НО PDP все еще должен проверить R3 в случае, если он возвращает Отказ.
Вы получите Deny, если securityLevel > 9000.
Вы получите Разрешение, если securityLevel <= 9000 и предостережения содержат не более A, B, C.
Наконец, R3 всегда предоставляет вам доступ. Поэтому независимо от того, что вы делаете во втором правиле, третье предоставит вам доступ. Другими словами, R2 не служит никакой цели вообще.
Я проверил вашу политику на сервере политики Axiomatics и увидел такое поведение в симуляторе. Тебе должно быть то же самое с Баланой.
Также вы должны проверить уровень безопасности в цели, а не в состоянии, которое является чрезмерным.
оно неявно связывает отрицательное совпадение условия с отрицанием эффекта.
В XACML нет ничего неявного. Противоположность разрешения не применима.
Поскольку нет целевого оператора, моя интуиция заключается в том, что он "должен" попытаться оценить это условие для всех запросов, поэтому несоответствие условию не должно приводить к пропуску правила.
Если в правиле нет цели, то она переходит прямо к условию, которое оно рассматривает. Это не пропускает правило. Но в вашем случае он возвращает NotApplicable.
Если вы хотите достичь того, что вы ищете, используйте сначала алгоритм комбинирования и измените R3 с Разрешить на Запретить.
Загляните в этот блог XACML для получения дополнительной информации.