Как написать политику XACML с использованием настраиваемых атрибутов

Что вы подразумеваете под пользовательским атрибутом? Что вы хотите выразить на «простом старом английском»?

В XACML вы можете использовать любые атрибуты, такие как роль, гражданство, допуск, классификация ресурсов, время суток... Конечно, доступность атрибута зависит от типа защищаемого приложения. Как вы используете реализацию Fedora? Это для контроля доступа в ОС Fedora Linux?

Если вы хотите сравнить атрибут со значением, например. гражданство == канадское, тогда используйте <Target/>. Если вы хотите сравнить 2 атрибута вместе, например. зазор > классификация, затем используйте <Condition>.

Я не уверен, что вы на самом деле ищете, но я думаю, вам нужно сделать некоторый контроль доступа на основе атрибутов.

В XACML есть компонент под названием PIP (Policy Information Point), где вы можете получать атрибуты из внешних источников и проверять авторизацию.

Это может помочь вам: Знакомство с PIP (пункт информации о политике).

Если вам нужно создать политики XACML более простым способом, выполните следующие действия: Редактор политик XACML на сервере идентификации WSO2.

Я должен признать, что я новичок в XACML и его реализации в Fedora, но я понимаю, что вы должны иметь возможность запрашивать любое значение, которое появляется при проверке объекта пользователя. URL-адрес установки Fedora Commons по умолчанию должен быть «localhost:8080/fedora/user» и дает следующий объект на моем сервере после входа в систему ранее созданного пользователя LDAP с именем «Joe User»:

<user id="Joe User">
  <attribute name="uid">
    <value>userj</value>
  </attribute>
  <attribute name="mail">
    <value>[email protected]</value>
  </attribute>
  <attribute name="sn">
    <value>User</value>
  </attribute>
  <attribute name="ou">
    <value>DPT</value>
  </attribute>
  <attribute name="cn">
    <value>Joe User</value>
  </attribute>
  <attribute name="description">
    <value>sample user</value>
  </attribute>
  <attribute name="role"/>
  <attribute name="fedoraRole"/>
  <attribute name="objectClass">
    <value>organizationalPerson</value>
    <value>person</value>
    <value>inetOrgPerson</value>
    <value>top</value>
  </attribute>
  <attribute name="displayName">
    <value>Joe User (LDAP)</value>
  </attribute>
</user>

После того, как значение было введено в пользовательский объект через какой-либо модуль аутентификации JAAS (как в приведенном выше случае с использованием модуля LDAP) или даже через переменную среды, вы сможете запросить его. В приведенном ниже примере политики я настроил Fedora для предоставления доступа к вызовам API-M, аналогичного FedoraAdmin, если для пользователя установлено значение OU «DPT»:

<?xml version="1.0" encoding="UTF-8"?>
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        PolicyId="permit-apim-to-ldap-ou"
        RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
>
  <!-- test policy to approve API-M operations if a specific LDAP OU exists -->
  <!-- make sure access to API-M in premitted from the current client IP address first (check "deny-apim-if-not-in-list.xml" or "deny-apim-if-not-localhost.xml" ) -->
  <Description>note that other policies may provide exceptions to this broad policy. This policy assumes api-m users have to be authenticated</Description>
  <Target>
    <Subjects>
      <Subject> 
        <!-- specific OU - need to get this working with a range of values -->
        <SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">DPT</AttributeValue>
          <SubjectAttributeDesignator AttributeId="ou" MustBePresent="false" DataType="http://www.w3.org/2001/XMLSchema#string"/>
        </SubjectMatch>
      </Subject>
    </Subjects>
    <Resources>
      <AnyResource/>
    </Resources>    
    <Actions>
        <AnyAction/>
    </Actions>
  </Target>
  <Rule RuleId="1" Effect="Permit"/>
</Policy>

Пользовательские атрибуты можно даже добавить в файл пользователя Fedora XML (а не в файл пользователя Tomcat) вместо использования LDAP. Вероятно, есть лучший способ сделать это, но, как я уже говорил, я новичок в XACML и не полностью его понимаю. Это правило работает на моем тестовом сервере localhost на основе других действующих правил. Ваш пробег может отличаться.

Кроме того, как указано в образце файла политики, убедитесь, что клиенту, с которого вы тестируете, может быть разрешен доступ к API-M, а затем запрещен доступ к API-M, прежде чем устанавливать подобное правило, поскольку отладка политик XACML в Fedora кажется чрезвычайно сложной. сложно с небольшим количеством данных, записываемых в файл журнала даже в режиме отладки (вы увидите, что операция прошла или не прошла, но никогда не увидите имя правила, которое привело к результату «пройдено/не пройдено»).