ejb Вопросы безопасности, касающиеся ролей и аутентификации

Я был бы очень признателен, если бы кто-нибудь помог мне со следующими вопросами:

  1. В чем разница между аннотациями @RolesAllowed и @DeclareRoles?
  2. Я разработал функцию входа в систему для проверки имени пользователя и пароля на соответствие информации в базе данных. Однако я хотел бы спросить, как я могу назначить роль аутентифицированному пользователю для использования с приведенными выше аннотациями.

person Mr.J4mes    schedule 28.08.2011    source источник


Ответы (2)


В чем разница между аннотациями @RolesAllowed и @DeclareRoles?

Аннотация @RolesAllowed используется для указания списка ролей, которым действительно разрешен доступ к бизнес-методу. На поведение EJB во время выполнения влияет присутствие этой аннотации, поскольку контейнер EJB активно проверяет, присутствует ли вызывающий объект в разрешенной роли. Кроме того, эта аннотация может быть определена как для TYPEs, так и для METHODs, что позволяет вам определять список ролей, разрешенных как на уровне класса, так и на уровне метода. Вы можете переопределить список ролей, разрешенных для всех методов класса, на уровне отдельного метода.

С другой стороны, аннотация @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
comment
Это действительно хороший и исчерпывающий ответ. Одно дополнение; в Java EE 6+ больше нет строгой необходимости [кодировать] для интерфейсов контейнера. Для этого существуют стандартизованные интерфейсы Java EE через JASPIC SPI. - person Arjan Tijms; 28.07.2013

Возможно, мой ответ может быть неправильным и неполным. Но его можно найти в этом справочнике http://openejb.apache.org/3.0/security-annotations.html

DeclareRoles можно использовать только на уровне класса. Вам необходимо обновить @DeclareRoles при обращении к ролям через isCallerInRole (roleName).

Основная идея

  • По умолчанию все методы бизнес-интерфейса доступны, авторизованы или нет.

  • Аннотации относятся к классу компонента, а не к бизнес-интерфейсу.

  • Аннотации безопасности могут применяться ко всему классу и / или отдельным методам.

  • Имена любых используемых ролей безопасности должны быть объявлены через @DeclareRoles.

@RolesAllowed Может использоваться как на уровне класса, так и на уровне методов для ограничения уровня доступа.

один пример Смешивание ограничений на уровне класса и метода Аннотации безопасности могут использоваться одновременно на уровне класса и уровне метода. Эти правила не складываются, поэтому отметка «submitPatch» отменяет значение по умолчанию «committers».

@Stateless
@DeclareRoles({"committer", "contributor"})
@RolesAllowed({"committer"})
public class OpenSourceProjectBean implements Project {

    public String svnCommit(String s) {
        return s;
    }

    public String svnCheckout(String s) {
        return s;
    }

    @RolesAllowed({"contributor"})
    public String submitPatch(String s) {
        return s;
    }
}

РЕДАКТИРОВАТЬ:

Вот фрагмент кода для SQLLoginModule. Вы можете использовать этот модуль как модуль входа в систему. Таким образом, вы можете следовать стандарту JAAS.

В фиксации он будет вызывать это, чтобы добавить участников.

subject.getPrincipals().addAll(allPrincipals);

Также вы можете проверить здесь дополнительную информацию http://openejb.apache.org/3.0/security.html.

В нем перечислены другие варианты, которые вы можете выбрать.

person Clark Bao    schedule 28.08.2011
comment
Спасибо за ответы. У вас есть идеи, как я могу решить свой второй вопрос? знак равно - person Mr.J4mes; 28.08.2011
comment
хммм ... У меня еще один небольшой вопрос. После входа пользователя в систему через веб-сервлет, можно ли будет записать роль этого парня в его cookie сеанса? это было бы что-то похожее на session.setAttribute (role, something here) ?? Я имею в виду, как я могу записать его роль, чтобы он мог иметь доступ к методам без необходимости снова и снова входить в систему. - person Mr.J4mes; 28.08.2011
comment
Можно, но это другой вопрос. Вы можете сохранить его в файле cookie или в сеансе. - person Clark Bao; 28.08.2011