В чем разница между аннотациями @RolesAllowed и @DeclareRoles?
Аннотация @RolesAllowed
используется для указания списка ролей, которым действительно разрешен доступ к бизнес-методу. На поведение EJB во время выполнения влияет присутствие этой аннотации, поскольку контейнер EJB активно проверяет, присутствует ли вызывающий объект в разрешенной роли. Кроме того, эта аннотация может быть определена как для TYPE
s, так и для METHOD
s, что позволяет вам определять список ролей, разрешенных как на уровне класса, так и на уровне метода. Вы можете переопределить список ролей, разрешенных для всех методов класса, на уровне отдельного метода.
С другой стороны, аннотация @DeclareRoles
используется просто для объявления списка ролей; это эквивалент элемента security-role-ref
в файле ejb-jar.xml
. Контейнер EJB не требует знания этих ролей для обеспечения проверки контроля доступа к бизнес-методам EJB; вместо этого поставщик / разработчик bean-компонентов может использовать эти роли в isCallerInRole
тестах для обеспечения программной безопасности.
В спецификации EJB 3.1 говорится об аннотации @DeclareRoles
следующее:
17.2.5.3 Объявление ролей безопасности, на которые ссылается код компонента
Поставщик компонента отвечает за использование аннотации DeclareRoles или элементов security-role-ref дескриптора развертывания для объявления всех имен ролей безопасности, используемых в коде корпоративного компонента. Аннотация DeclareRoles указывается в классе компонента, где она служит для объявления ролей, которые могут быть протестированы путем вызова isCallerInRole из методов аннотированного класса. Объявление ролей безопасности позволяет Bean Provider, Application Assembler или Deployer связывать эти имена ролей безопасности, используемые в коде, с ролями безопасности, определенными для собранного приложения. В отсутствие этого шага связывания любое имя роли безопасности, используемое в коде, будет считаться соответствующим роли безопасности с тем же именем.
Вторая часть вашего вопроса гласит:
Я разработал функцию входа в систему для проверки имени пользователя и пароля на соответствие информации в базе данных. Однако я хотел бы спросить, как я могу назначить роль аутентифицированному пользователю для использования с приведенными выше аннотациями.
В этом случае следует отметить общий момент: я предпочитаю не использовать программную безопасность, если этого не требуют ваши варианты использования. В большинстве случаев, если можно достичь требований с помощью декларативной безопасности, предпочтительно использовать ее, поскольку программная безопасность требует, чтобы вы отслеживали isCallerInRole
вызовы методов, а отсутствие такого вызова может привести к нарушению безопасности. В любом случае, в вашем случае вам понадобится ваш контейнер, чтобы сначала распознать группы и участников в базе данных как роли, которые могут использоваться для проверок контроля доступа.
Проще говоря, клиент EJB (приложение Java SE, сервлет или другой EJB) должен сначала аутентифицировать себя с помощью механизмов безопасности контейнера, чтобы установить Principal
вызывающего. Следовательно, успешное использование декларативной или прогамматической безопасности зависит от успешного процесса аутентификации. В вашем случае вам нужно будет настроить контейнер для распознавания групп и пользователей в вашей базе данных и преобразования их в Principal
объекты, которые можно использовать для обеспечения контроля доступа декларативным или программным способом. Большинство контейнеров поддерживают для этой цели одну или несколько разновидностей модулей входа в систему JAAS; Например, Glassfish 3.1 позволяет это использовать с помощью JDBCRealm, а JBoss 6.0 поддерживает это с помощью DatabaseServerLoginModule. Поэтому вам необходимо определить, поддерживает ли ваш контейнер такой модуль входа в систему, и настроить его для использования вашей базы данных.
Обратите внимание, что в некоторых случаях предоставленные контейнером модули входа в систему могут оказаться недостаточными для удовлетворения ваших потребностей. В таком случае вам нужно будет написать свой собственный модуль входа в систему (и, если необходимо, против интерфейсов контейнера).
Кроме того, вам также необходимо сопоставить роли, используемые приложением, с пользователями и группами в области JAAS. Например, если ваша база данных используется областью JAAS:
- содержит пользователей
U1
, U2
, U3
, U4
и U5
, а также
- содержит группы
G1
, G2
и G3
, содержащие соответственно U1
, U2
, U3
,
- и ваш EJB разрешает пользователям с ролями
R1
, R2
и R3
(определенными с помощью аннотации @RolesAllowed
) обращаться к своим методам,
тогда вам нужно будет сопоставить роли принципалам (пользователям и группам) в области JAAS. Сопоставление должно выполняться даже в том случае, если имена ролей совпадают с именами участников; Glassfish упрощает это, поддерживая принципала по умолчанию для сопоставления ролей, что напрямую сопоставляет одноименных участников (пользователей или группы) с ролями. Кроме того, процесс сопоставления зависит от контейнера, и, как вы уже догадались, это сопоставление выполняется в конкретных дескрипторах развертывания контейнера, а не в дескрипторе развертывания EJB (ejb-jar.xml
).
Чтобы ответить на этот вопрос, вам нужно назначить роль каждому создаваемому пользователю. Для простоты вы можете создать одну группу пользователей, к которой могут принадлежать все пользователи. Когда пользователь аутентифицируется в области JAAS, объект Principal будет содержать эту группу. Затем группа в вашей области JAAS может быть сопоставлена с ролью EJB, а имя роли может быть указано в аннотации @RolesAllowed
. Любой пользователь в базе данных, не входящий в эту группу, не сможет получить доступ к аннотированным методам контейнером EJB.
person
Vineet Reynolds
schedule
28.08.2011