вопросы безопасности ejb относительно ролей и аутентификации

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

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

2 ответов

каковы различия между аннотациями @RolesAllowed и @DeclareRoles?

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

на @DeclareRoles аннотация, с другой стороны, просто используется для объявления списка ролей; это эквивалент security-role-ref в элементе . Контейнер EJB не требует знания этих ролей для обеспечения проверки контроля доступа к бизнес-методам EJB; вместо этого поставщик/разработчик bean может использовать эти роли в isCallerInRole тесты для обеспечения программной безопасности.

в спецификации EJB 3.1 говорится следующее о @DeclareRoles аннотация:

17.2.5.3 объявление ролей безопасности, на которые ссылается компонент Код

поставщик компонентов отвечает за использование аннотации DeclareRoles или элементы security-role-ref дескриптора развертывания для объявить все имена ролей безопасности, используемые в корпоративном коде компонента. Аннотация DeclareRoles указывается в классе bean, где она служит для объявления ролей, которые могут быть протестированы путем вызова isCallerInRole из методов аннотированного класса. Объявление безопасности ролей позволяет поставщику фасоли, ассемблер приложения, или разработчик, чтобы связать эти имена ролей безопасности, используемые в коде, с ролями безопасности определено для собранного приложения. При отсутствии этой связи шаг любой имя роли безопасности, используемое в коде, будет соответствуют одноименной роли безопасности.

вторая часть вашего вопроса:

я разработал функцию входа в систему, чтобы проверить имя пользователя и пароль против информации в базе данных. Однако я хотел бы спросить, как я могу назначить роль аутентифицированному пользователю для использования с вышеуказанными аннотациями.

в этом случае следует отметить, что мой предпочтительный подход-не использовать progammatic security, если ваши варианты использования не требуют этого. В большинстве случаев, если можно достичь требований с декларативной безопасностью, предпочтительнее использовать его, поскольку progammatic security требует, чтобы вы отслеживали 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. Сопоставление должно выполняться даже в том случае, если имена ролей совпадают с именами principal имена; Glassfish упрощает это, поддерживая Принципал по умолчанию для сопоставления ролей который напрямую сопоставляет одноименные участники (пользователи или группы) с ролями. Кроме того, процесс сопоставления специфичен для контейнера, и, как вы могли догадаться, это сопоставление выполняется в дескрипторах развертывания конкретного контейнера, а не в дескрипторе развертывания EJB (ejb-jar.xml).

чтобы завершить ответ, вам нужно назначить роль каждому созданному пользователю. Во имя для простоты можно создать одну группу пользователей, к которой могут принадлежать все пользователи. Когда пользователь аутентифицирует себя в области JAAS, основной объект будет содержать эту группу. Затем группа в вашей области JAAS может быть сопоставлена с ролью EJB, а имя роли может быть указано в @RolesAllowed Примечание. Любой пользователь в базе данных, который не входит в эту группу, не сможет получить доступ к аннотированным методам с помощью контейнера EJB.

21

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

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

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

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

  • аннотации идут в классе bean, а не в бизнес-интерфейсе

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

  • имена всех используемых ролей безопасности должны быть объявлены через @ 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;
    }
}

EDIT:

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

в commit он вызовет это, чтобы добавить принципалы.

subject.getPrincipals().addAll(allPrincipals);

Также вы можете проверить здесь для больше деталей http://openejb.apache.org/3.0/security.html.

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

2