2015-09-24 3 views
1

Мы используем WSO2 версии 5.0 SP1. Мы сконфигурировали ReadOnly LDAP, а также использовали функцию права доступа на сервере идентификации. Политика XACML, которую мы определили на WSO2 IS, получает свое право от ролей, назначенных пользователю. Наше наблюдение заключается в том, что WSO2 IS выполняет фактическое совпадение с именем пользователя, то есть его чувствительным к регистру. Если мы передаем имя пользователя в том же случае, что и в списке пользователей WSO2, оно возвращает правильное право. Есть ли какое-либо исправление для WSO2 версии 5.0 SP1? Любое обходное решение также поможет.Является ли wso2 5.0 SP1 чувствительным к регистру?

<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="AdministratorPolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-overrides" Version="1.0"> 
<Target></Target> 
<Rule Effect="Permit" RuleId="Rule1"> 
    <Condition> 
    <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:and"> 
     <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of"> 
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag"> 
       <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Test</AttributeValue> 
      </Apply> 
      <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"></AttributeDesignator> 
     </Apply> 
     <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in"> 
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Internal/Administrator</AttributeValue> 
      <AttributeDesignator AttributeId="http://wso2.org/claims/role" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator> 
     </Apply> 
    </Apply> 
    </Condition> 
</Rule> 
Rule Effect="Deny" RuleId="Rule2"></Rule> 
</Policy>   

Спасибо заранее, Cijoy

+0

Можете ли вы опубликовать политику xacml, которую вы использовали? – DarRay

+0

Итак, проблема возникает, когда движок XACML пытается получить права пользователя правильно? – DarRay

ответ

0

Я думаю, что это поведение происходит из-за того, как вы написали политику XACML.

Вы используете urn:oasis:names:tc:xacml:1.0:function:string-equal для совпадения имени пользователя в вашей политике xaml?

если да, попробуйте urn:oasis:names:tc:xacml:3.0:function:string-equal-ignore-case вместо выше. Это должно решить проблему.


EDIT: С обновленной политики вопрос XACML, вопрос видит быть XACML двигатель не извлекает роли, когда он не получает имя пользователя от subjectin правильного случая.

Это означает, что по умолчанию PIP не возвращает роли, если имя пользователя не в правильном случае.

мышление этого угла, чтобы ответить на ваш первоначальный вопрос

Является WSO2 5,0 SP1 чувствителен к регистру?

Для идентификации пользователей \ ролевых имен, если сервер идентификации наследуется от основного хранилища пользователя, к которому он подключен. Если вы подключаете IS к Active Directory, обычно имена пользователей \ rolenames не чувствительны к регистру. Если вы развертываете IS поверх хранилища пользователей Oracle, обычно имена пользователей \ rolenames обрабатываются с учетом регистра.


Решение

Но более конкретно для вашего сценария, если вы хотите получить (внутренний) список ролей, независимо от случая имени пользователя. Об этом поведении сообщается issue, а Identity Server 5.0.0 содержит эти исправления. Таким образом, вы можете попробовать следующее,

  1. Открыть файл <IS_HOME>/repository/conf/user-mgt.xml.
  2. Добавить GetRoleListOfInternalUserSQL свойство с упомянутым значением по <UserManager>/<Realm>/<Configuration> теге следующим образом,

    <UserManager> 
        <Realm> 
         <Configuration> 
         ... 
         <Property name="GetRoleListOfInternalUserSQL"> 
          SELECT UM_ROLE_NAME FROM UM_HYBRID_USER_ROLE, UM_HYBRID_ROLE WHERE UPPER(UM_USER_NAME)=UPPER (?) AND UM_HYBRID_USER_ROLE.UM_ROLE_ID=UM_HYBRID_ROLE.UM_ID AND UM_HYBRID_USER_ROLE.UM_TENANT_ID=? AND UM_HYBRID_ROLE.UM_TENANT_ID=? AND UM_HYBRID_USER_ROLE.UM_DOMAIN_ID=(SELECT UM_DOMAIN_ID FROM UM_DOMAIN WHERE UM_TENANT_ID=? AND UM_DOMAIN_NAME=?) 
         </Property> 
         </Configuration> 
        ... 
        </Realm> 
    <UserManager> 
    
  3. Перезапустите сервер

Теперь ваша политика должна оценить, как ожидается, для любого случая пользователя

+0

Спасибо за ваш ответ.Наша политика проверяет роли против списка ресурсов и не сравнивает имя пользователя напрямую. Следовательно, когда мы вызываем из инструмента TryIt, а также с несоответствующим субъектом именем субъекта и ресурсом, он терпит неудачу. – Cijoy

+0

Я обновил ответ, исходя из фактов, которые я получил от политики XACML. – DarRay

+0

Большое спасибо DarRay. Это сработало для нас. Теперь права и управление претензиями работают так, как ожидалось. – Cijoy