Deltaspike и @Stateless Bean

Я хочу защитить свой EJb без гражданства с помощью DeltaSpike-API.

@Stateless
@Remote(UserServiceRemote.class)
public class UserService implements UserServiceRemote

На уровне метода у меня есть пользовательская аннотация «Поддержка».

@Support
public void doSomething() {}

Поэтому я написал пользовательскую аннотацию «@Support»:

@Retention(value = RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD })
@Documented
@SecurityBindingType
public @interface Support {

Мой пользовательский авторизатор выглядит так:

@Secures
@Support
public boolean doAdminCheck(Identity identity, IdentityManager identityManager, RelationshipManager relationshipManager)
            throws Exception {      
    return hasRole(relationshipManager, identity.getAccount(), getRole(identityManager, "Support"));
}

В мой файл "beans.xml" я включил:

<interceptors>
    <class>org.apache.deltaspike.security.impl.extension.SecurityInterceptor</class>
</interceptors>

Но после того, как я войду в свое приложение и вызову метод «doSomething» для каждого удаленного вызова, аннотация «Поддержка» игнорируется, независимо от того, есть ли у меня роль или нет.

Что я делаю неправильно? Спасибо за все предложения!!!


java security deltaspike ejb-3.1
person user1651904    schedule 06.11.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Ejb и CDI - это две разные концепции. Компонент сеанса без сохранения состояния и управляемый компонент CDI управляются разными контейнерами. Таким образом, вы не можете использовать Deltaspike в сессионном компоненте без сохранения состояния. Если вы хотите использовать безопасность deltaspike, используйте вместо этого именованный компонент и другую стратегию удаленного взаимодействия.

person Jan Galinski    schedule 07.11.2014

arrow_upward
0
arrow_downward

В моем случае мне нужно было убедиться, что модуль (jar), содержащий службу, которую я хотел защитить с помощью аннотации, имел файл beans.xml с перехватчиком deltaspike (ранее я добавлял файл только в модуль с самим кодом безопасности, который был проблема).

Также я обнаружил, что мне пришлось отделить службу бизнес-логики от самой декларации конечной точки SOAP. Эта пользовательская служба EJB @Stateles (или любая другая) может быть @Inject-ed в SOAP, и аннотации безопасности (здесь @Support) будут работать с ней.

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

person mszalinski    schedule 07.09.2015