2013-06-22 3 views
1

Я читаю документацию shiro и так и не нашел признаков того, что shiro поддерживает концепцию групп пользователей на уровне API.ли apache siro поддерживает концепцию групп пользователей?

Я бы ожидал, что Subject.java будет иметь такие методы, как getUserGroups, но это не так. Например, если я пишу какое-либо приложение, которое предназначено для работы с многочисленными системами аутентификации, когда пользователь создает какой-либо объект, я хотел бы сделать его видимым для всех пользователей в группах создателя объекта и сделать это в агентическом агенте проверки подлинности , используя некоторый API-интерфейс фасада, например, Shiro Subject.

Но похоже, что я не могу это сделать, используя shiro api, это правильно?

Как вы поддерживаете концепцию групп пользователей в многоадресных приложениях?

Должен ли я написать расширение UserGroupAwareSubject?

+0

ответ достаточно? Если это так, вы должны его наградить. –

ответ

2

Shiro по состоянию на 1.2 не имеет концепции группы в своем API - он имеет понятие Ролей и Разрешений.

Это не проблема, если у вас есть только роли или вы можете использовать имена своих групп, как то, что Сиро называет Ролями (т. Е. Realm.hasRole (roleIdentifier, authzInfo) использует имя вашей группы в качестве «roleIdentifier»).

Если в вашем приложении есть понятия «Роль и группа», вы, вероятно, не сможете легко использовать subject.hasRole для проверки обоих. Если вам нравится это как функция, откройте feature request.

Два варианта для этого, хотя, если вы хотите, чтобы сделать его работу:

  1. Есть один Realm где realm.hasRole вызывает проверку в отношении ваших ролей и другого Realm где realm.hasRole вызывает проверку в отношении ваших групп.
  2. Используйте один Realm для выполнения как и просто префикс строки, которые вы используете для групповых проверок с узнаваемым маркером, например:

    subject.hasRole("group:myGroupName"); 
    

    Тогда ваша сфера может проверить, если есть этот префикс, и если да, то выполните групповую проверку, а если нет, выполните проверку роли.

Эти варианты в сторону, что многие люди делают в этом случае игнорировать роль и проверки группы целиком и вместо того, чтобы полагаться на (более мощные) проверки прав в коде:

subject.isPermitted("document:1234:read"); 

Тогда ваш Realm может проверьте как Subject , так и любую из назначенных ей групп или ролей, чтобы узнать, подразумевают ли они это разрешение. Если это так, то вам вообще не нужны никакие проверки группы или роли, потому что ваш код зависит от разрешений вместо концепции (потенциально изменчивых и многочисленных) групп/ролей.

Есть некоторые веские причины why permissions are probably better than Role or Group checks, но если вы чувствуете себя иначе и все равно хотели бы Группы, представленные в API Subject, пожалуйста, откройте запрос функции.

С уважением,

Les

+1

Благодарим вас за подробный ответ – user2512334

+0

Можно ли дать ограничения на разрешения, например. ограничить «чтение» для конкретного пользователя, если разрешена роль пользователя? – serkan