Поддерживает ли модель безопасности Java EE ACL?

Модель безопасности Java EE аутентифицирует «Принципала», который может иметь или более «Ролей».

В другом измерении у вас есть услуги и ресурсы, которым нужны настраиваемые «Разрешения» или «Возможности».

В конфигурации вы определяете, какие «Принципалы» или «Роли» имеют какие «Разрешения» или «Возможности».

Другими словами, да, он поддерживает ACL и настолько детализирован, насколько вы хотите, но вам придется привыкнуть к терминологии.

В ответе Vineet есть отличное предложение создать «роли» для каждого идентификатора проекта.Так как люди должны быть назначены проектам в любом случае, можно легко добавить людей в эти группы в это время. В качестве альтернативы синхронизированный сценарий может обновлять членство в группах на основе ролей. Последний подход может быть предпочтительнее, потому что легче проверить безопасность, если эти решения находятся в одном месте, а не разбросаны по всему административному коду.

В качестве альтернативы вы можете использовать «крупнозернистые» роли, например. Designer и использовать базу данных (или логику программы) для ограничения представлений для пользователя, вошедшего в систему

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 и шва:

<!-- richfaces -->
<rich:panel header="Admin panel" rendered="#{rich:isUserInRole('admin')}">
  Very sensitive information
</rich:panel>

<!-- seam -->
<h:commandButton value="edit" rendered="#{isUserInRole['admin']}"/>.

Вот статья, объясняющая, как добавить его в ADF

Модель безопасности Java EE реализует RBAC (управление доступом на основе ролей). Для программиста Java EE это фактически означает, что пользователям могут быть предоставлены разрешения на доступ к ресурсу.Ресурсы могут включать файлы, базы данных или даже код. Следовательно, можно не только ограничить доступ к таким объектам, как файлы и таблицы в базах данных, но также можно ограничить доступ к исполняемому коду.

Теперь разрешения можно сгруппировать в роли, которые в конечном итоге будут связаны с пользователями/субъектами. Это модель безопасности Java EE в двух словах.

Из описания вашей проблемы следует, что вы хотите различать два разных проекта как два разных ресурса и, следовательно, иметь либо два отдельных объекта разрешений, либо две отдельные роли для учета одного и того же. Учитывая, что у вас уже есть роли (более уместно называемые группами пользователей), такие как администратор, дизайнер и т. д., это не может быть легко достигнуто в Java EE. Причина в том, что вы разграничиваете доступ к ресурсам пользователям в роли, исходя из дополнительного свойства ресурса — идентификатора проекта. Технически это относится к области, известной как ABAC (управление доступом на основе атрибутов).

Одним из способов достижения ABAC в Java EE является перенос свойств/атрибутов, предоставленных роли, в имени роли. Поэтому вместо следующего кода:

if(request.isUserInRole("DESIGNERS")){
    access = true;
}else{
    access = false;
}

вы должны сделать что-то вроде следующего. Обратите внимание на символ «:», используемый в качестве разделителя, чтобы отличить имя роли от сопровождающего атрибута.

if(request.isUserInRole("DESIGNERS"+":"+projectId)){
    access = true;
}else{
    access = false;
}

Конечно, есть часть, где ваш модуль входа в систему должен быть изменен (либо в конфигурации, либо в коде), чтобы возвращать роли, содержащие идентификаторы проектов, а не простые имена ролей.Обратите внимание, что все эти предлагаемые изменения должны быть всесторонне рассмотрены на наличие проблем — например, следует запретить символу-разделителю быть частью имени роли, в противном случае вполне возможно выполнить атаки с повышением привилегий.

Если реализация вышеизложенного окажется неудачной,вы можете посмотреть на такие системы, как Shibboleth, которые обеспечивают поддержку ABAC, хотя я никогда не видел, чтобы он использовался в приложении Java EE.