Модель безопасности Java EE аутентифицирует «принципала», который может иметь одну или несколько «ролей».
В другом измерении у вас есть службы и ресурсы, для которых требуются настраиваемые «Разрешения» или «Возможности».
В конфигурации вы определяете, какие «Принципы» или «Роли» имеют какие «Разрешения» или «Возможности».
Другими словами, да, он поддерживает ACL и настолько мелкозернистый, насколько вы хотите, но вам придется привыкнуть к терминологии.
В ответе Vineet есть отличное предложение создать «роли» для каждого идентификатора проекта. Так как люди должны быть назначены на проекты в любом случае, просто добавить людей в эти группы в это время. В качестве альтернативы синхронизированный сценарий может обновлять членство в группах на основе ролей. Последний подход может быть предпочтительным, поскольку легче проверить безопасность, если эти решения находятся в одном месте, а не разбросаны по всему коду администрирования.
В качестве альтернативы вы можете использовать «грубые» роли, например, разработчик и использование базы данных (или программной логики) для ограничения представлений пользователя, вошедшего в систему
SELECT p.* FROM projects p, assignments a WHERE p.id = a.projectId AND a.finishdate < NOW();
или
@Stateless class SomeThing {
@Resource SessionContext ctx;
@RolesAllowed("DESIGNER")
public void doSomething(Project project) {
String userName = ctx.getCallerPrincipal.getName();
if (project.getTeamMembers().contains(userName) {
// do stuff
}
}
}
Обратите внимание, что грубый контроль доступа здесь был сделан с аннотацией вместо кода. Это может значительно усложнить тестирование шаблона и сэкономить много времени.
Существуют аналогичные функции для рендеринга веб-страниц, на которых можно отображать части экрана на основе текущего пользователя, обычно используя тег.
Кроме того, поскольку безопасность представляет собой столь широкую проблему, я думаю, что лучше использовать предоставленные функции для достижения контекста, чем передавать батарею логических флагов, таких как isAdmin , поскольку это быстро становится очень беспорядочный. Это увеличивает сцепление, и это еще одна вещь, делающая классы сложнее для модульного тестирования.
Во многих реализациях JSF есть теги, которые могут помочь отрисовывать необязательные вещи. Вот примеры для richfaces и seam:
<!-- richfaces -->
<rich:panel header="Admin panel" rendered="#{rich:isUserInRole('admin')}">
Very sensitive information
</rich:panel>
<!-- seam -->
<h:commandButton value="edit" rendered="#{isUserInRole['admin']}"/>.
Вот статья , объясняющая, как добавить ее в ADF