Deltaspike and @Stateless Bean

问题:

I want to secure my "Stateless" EJb with the DeltaSpike-API.

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

At method level i have a custom annotation "Support"

@Support
public void doSomething() {}

Therefore i wrote a custom annotation "@Support":

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

My custom Authorizer looks like:

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

In my "beans.xml" file i included:

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

But after i log in my application and call the "doSomething" method per remote call the "Support" annotation is ignored, no matter if I have the role or not.

What I'm doing wrong? Thanx for all suggestions!!!

回答1:

Ejb and CDI are two different concepts. A stateless session bean and a managed CDI bean are managed by different containers. So you cannot use Deltaspike on a stateless session bean. If you want to use deltaspike security, use a named bean instead and use a different remoting strategy.

回答2:

In my case I had to make sure that module (jar) containing service I wanted to secure with the annotation had beans.xml file with deltaspike interceptor in it (previously I was adding the file only to module with the security code itself, which was a problem).

Also I found out that I had to separate business logic service, from the SOAP endpoint declaration itself. This custom EJB @Stateles (or any other) service can be @Inject-ed into the SOAP and security annotations (here @Support) will work on it.

In my opinion separation of endpoint declaration from business code is good design anyway, as we may have multiple interfaces invoking same business logic. (and it's easier to unit test etc.)