Изучаем Java EE 7

··public Book findBookById(Long id) {

····return em.find(Book.class, id);

··}

··public Book createBook(Book book) {

····em.persist(book);

····return book;

··}

··@RolesAllowed("admin")

··public void deleteBook(Book book) {

····em.remove(em.merge(book));

··}

}

Аннотация @RolesAllowed определяет список ролей, которым разрешен доступ к методу. Аннотации @PermitAll и @DenyAll применяются для любой роли. Таким образом, вы можете использовать аннотацию @PermitAll, чтобы отметить EJB, или метод, чтобы он вызывался для любой роли. И наоборот, @DenyAll запрещает любым ролям доступ к методу.

Как вы можете видеть в листинге 8.6, поскольку метод findBookById() аннотирован @PermitAll, он теперь может быть доступен для любой роли, а не только user, employee или admin. С другой стороны, метод findConfidentialBook() не доступен никому (@DenyAll).

Листинг 8.6. Не сохраняющий состояние компонент, который использует аннотации @PermitAll и @DenyAll

@Stateless

@RolesAllowed({"user", "employee", "admin"})

public class ItemEJB {

··@PersistenceContext(unitName = "chapter08PU")

··private EntityManager em;

··@PermitAll

··public Book findBookById(Long id) {

····return em.find(Book.class, id);

··}

··public Book createBook(Book book) {

····em.persist(book);

····return book;

··}

··@ RolesAllowed("admin")

··public void deleteBook(Book book) {

····em.remove(em.merge(book));

··}

··@DenyAll

··public Book findConfidentialBook(Long secureId) {

····return em.find(Book.class, secureId);

··}

}

Аннотация @DeclareRoles немного отличается, поскольку она не управляет доступом. Она позволяет декларировать роли для всего приложения. При развертывании EJB в листинге 8.6 контейнер автоматически объявляет роли user, employee и admin, проверив аннотацию @RolesAllowed. Но вы можете объявить другие роли в домене безопасности для всего приложения (а не только для одного EJB) с помощью аннотации @DeclareRoles. Эта аннотация, которая применяется только на уровне класса, принимает массив ролей и объявляет их в домене безопасности. На самом деле роли безопасности объявляются с использованием одной из этих двух аннотаций или их комбинации. Если применяются обе аннотации, набор ролей объявляется с помощью обеих. Обычно мы объявляем роли для всего приложения, поэтому в данном случае имеет смысл объявить роли в дескрипторе развертывания, нежели с помощью аннотации @DeclareRoles.

При развертывании класса ItemEJB в листинге 8.7 объявляются пять ролей (HR, salesDpt, user, employee и admin). Затем с помощью аннотации @RolesAllowed некоторые из этих ролей получают доступ к определенным методам (как объяснялось ранее).

Листинг 8.7. Определение ролей для компонента, не сохраняющего состояние

@Stateless

@DeclareRoles({"HR", "salesDpt"})

@RolesAllowed({"user", "employee", "admin"})

public class ItemEJB {

··@PersistenceContext(unitName = "chapter08PU")

··private EntityManager em;

··public Book findBookById(Long id) {

····return em.find(Book.class, id);

··}

··public Book createBook(Book book) {

····em.persist(book);

····return book;

··}

··@RolesAllowed("admin")

··public void deleteBook(Book book) {

····em.remove(em.merge(book));

··}

}

Последняя аннотация, @RunAs, может пригодиться, если вам нужно временно назначить новую роль существующему принципалу. Возможно, вам понадобится сделать это, если вы, например, вызываете другой EJB внутри вашего метода, но этот EJB требует иной роли.

Например, ItemEJB в листинге 8.8 разрешает доступ ролям role, employee и admin. Когда одна из этих ролей обращается к методу, метод запускается с временной ролью inventoryDpt (@RunAs("inventoryDpt")). Это означает, что при вызове метода createBook() метод InventoryEJB.addItem() будет вызван с ролью inventoryDpt.

Листинг 8.8. Не сохраняющий состояние компонент, запущенный с другой ролью