it-swarm.com.de

Wie bekomme ich die Annotation @RolesAllowed für meine Webanwendung?

Ich mache eine Webanwendung mit Backbone.js, Bootstrap, NetBeans IDE 8.0, Java EE 7, JDK 8, WildFly-Server 8.1.0, JBoss RESTEasy (resteasy-jaxrs-3.0.8), JBoss 2.2.22 , JBoss EJB 3.

Ich bin (relativ) neu in der Webentwicklung und als solche habe ich gerade erst angefangen, viele grundlegende Konzepte und Technologien zu verstehen. Ich versuche, ein Berechtigungssystem mit Benutzern und Rollen in eine Webanwendung einzubauen, aber ich kann die Annotation @RolesAllowed scheinbar nicht in meinem RESTful-Webdienst verwenden. Ich arbeite bereits seit einigen Tagen an diesem Problem.

Ich habe eine RESTful-Ressource (Java Enterprise/Session Bean?) Namens UserResource.Java. Hier habe ich eine Methode create, um einen neuen Benutzer für die Anwendung zu erstellen:

import Java.net.URI;
import Java.security.Principal;
import Java.util.List;
import javax.annotation.security.PermitAll;
import javax.annotation.security.RolesAllowed;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ws.rs.*;
import javax.ws.rs.core.*;
import org.jboss.ejb3.annotation.SecurityDomain;

@Stateless
@SecurityDomain("other")
@Path("/user")
public class UserResource {
    @EJB(name = "UserServiceImp")
    UserService userService;

    @Context
    private UriInfo uriInfo;

    @RolesAllowed({"admin"})
    @Path("create")
    @POST
    public Response create(CreateRequest request) {        
        try {
            System.out.println("Start of create method");
            User user = userService.createUser(request);
            return getCreateResponse(user);
        }
        catch (Exception e){
            return Response.status(401).entity("Failed to create user").build();
        }
    }
}

Diese create -Methode funktioniert, wenn ich die Annotation @PermitAll verwende. Sie schlägt jedoch fehl, wenn ich die Annotation @RolesAllowed verwende.

Ich habe diese Backbone-Ansicht CreateUserView, die einem Endbenutzer (mit Administratorrechten) ein Formular (in HTML) zum Erstellen neuer Benutzer für die Anwendung zur Verfügung stellt. Wenn Sie auf die Schaltfläche "Senden" klicken, werden JSON-Daten an die URL "rest/user/create" gesendet, um einen neuen Benutzer zu erstellen. Bevor die create -Methode in UserResource.Java ausgeführt wird, prüft mein SecurityInterceptor.Java (der javax.ws.rs.container.ContainerRequestFilter implementiert), ob der Benutzer die erforderliche Berechtigungen. Ich habe dies gründlich geprüft und der Security Interceptor funktioniert einwandfrei. Nachdem also der Security Interceptor einen eindeutigen Zugriff gewährt hat, geht in UserResource.Java etwas schief. (Als Randbemerkung, nicht sicher, ob dies wichtig ist, aber ich glaube, der Security Interceptor basiert auf diesem Blogpost über RESTEasy-Sicherheit . Ich arbeitete gerade mit einem anderen Mann an der Anwendung, er implementierte ihn zunächst, also habe ich ihn umgesetzt Ich bin mir nicht sicher .. aber es sieht fast identisch aus. Jedenfalls ist der Kerl vor ein paar Wochen zu einem anderen Projekt gewechselt.)

Die Fehlermeldung, die ich bekomme (Ausgabe vom Server), lautet wie folgt:

16:45:25,775 ERROR [org.jboss.as.ejb3.invocation] (default task-60) JBAS014134: EJB Invocation failed on component UserResource for method public javax.ws.rs.core.Response org.profit.pgb.rest.resource.UserResource.create(org.profit.pgb.rest.api.CreateRequest): javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public javax.ws.rs.core.Response org.profit.pgb.rest.resource.UserResource.create(org.profit.pgb.rest.api.CreateRequest) of bean: UserResource is not allowed
    at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.Java:135) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.Java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.Java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.Java:59) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.Java:50)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.Java:55) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.Java:64)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.invocation.InterceptorContext.run(InterceptorContext.Java:326)
    at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.Java:448)
    at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.Java:61)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.invocation.InterceptorContext.run(InterceptorContext.Java:326)
    at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.Java:80)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.Java:61)
    at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.Java:185)
    at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.Java:182)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.Java:61)
    at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.Java:73)
    at org.profit.pgb.rest.resource.UserResource$$$view45.create(Unknown Source) [classes:]
    at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_11]
    at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:62) [rt.jar:1.8.0_11]
    at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:43) [rt.jar:1.8.0_11]
    at Java.lang.reflect.Method.invoke(Method.Java:483) [rt.jar:1.8.0_11]
    at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.Java:401) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
    at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.Java:99) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
    at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.Java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
    at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.Java:65) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
    at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.Java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
    at org.profit.pgb.rest.resource.UserResource$Proxy$_$$_Weld$EnterpriseProxy$.create(Unknown Source) [classes:]
    at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_11]
    at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:62) [rt.jar:1.8.0_11]
    at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:43) [rt.jar:1.8.0_11]
    at Java.lang.reflect.Method.invoke(Method.Java:483) [rt.jar:1.8.0_11]
    at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.Java:137) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.Java:296) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.Java:250) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.Java:237) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.Java:356) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.Java:179) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.Java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.Java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.Java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
    at javax.servlet.http.HttpServlet.service(HttpServlet.Java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
    at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.Java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.Java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.Java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.Java:78)
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.Java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.Java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.Java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.Java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.Java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.Java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.Java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.Java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.Java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.Java:61)
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.Java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.Java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.Java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.Java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.Connectors.executeRootHandler(Connectors.Java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.Java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at Java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.Java:1142) [rt.jar:1.8.0_11]
    at Java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.Java:617) [rt.jar:1.8.0_11]
    at Java.lang.Thread.run(Thread.Java:745) [rt.jar:1.8.0_11]

16:45:25,957 ERROR [io.undertow.request] (default task-60) UT005023: Exception handling request to /pgb/rest/user/create: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public javax.ws.rs.core.Response org.profit.pgb.rest.resource.UserResource.create(org.profit.pgb.rest.api.CreateRequest) of bean: UserResource is not allowed
    at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.Java:76) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.Java:212) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.Java:149) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.Java:372) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.Java:179) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.Java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.Java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.Java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
    at javax.servlet.http.HttpServlet.service(HttpServlet.Java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
    at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.Java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.Java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.Java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.Java:78)
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.Java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.Java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.Java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.Java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.Java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.Java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.Java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.Java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.Java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.Java:61)
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.Java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.Java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.Java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.Java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.Java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.Connectors.executeRootHandler(Connectors.Java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.Java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
    at Java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.Java:1142) [rt.jar:1.8.0_11]
    at Java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.Java:617) [rt.jar:1.8.0_11]
    at Java.lang.Thread.run(Thread.Java:745) [rt.jar:1.8.0_11]
Caused by: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public javax.ws.rs.core.Response org.profit.pgb.rest.resource.UserResource.create(org.profit.pgb.rest.api.CreateRequest) of bean: UserResource is not allowed
    at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.Java:135) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.Java:95) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.Java:64) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.Java:309)
    at ... etc. (not fully shown due to SO's character limit on questions..)

Ich habe gesehen, wie andere Leute ähnliche Fragen stellten, von denen einige bis heute unbeantwortet blieben (z. B. jax-rs-Dienst RolesAllowed Annotation, die eine Ausnahme auslöst ) und andere, deren Lösungen entweder für mich nicht geeignet sind oder möglicherweise nicht zutreffen die Lösung korrekt (zB RESTEasy Unterstützung für JAX-RS @RolesAllowed ).

Ich habe Folgendes gefunden: https://developer.jboss.org/thread/177728?start=0&tstart=0 (betitelt: "@RolesAllowed, @DenyAll erfordert das Vorhandensein von org.jboss.ejb3.annotation.SecurityDomain ? "), In hat die Lösung ausprobiert, aber ich kann sie nicht für mein Projekt verwenden. Ich bin nicht sicher, ob die Lösung für meine Situation nicht geeignet ist oder ob ich sie einfach falsch mache.

Ich habe folgendes gefunden: https://developer.jboss.org/message/720815 (mit dem Titel: "ist dies ein Fehler beim Verarbeiten von org.jboss.ejb3.annotation.SecurityDomain?"), Aber ich verstehe nicht, wo mein jboss-ejb-client.properties sein soll. Ich denke, sie haben ihr Projekt ganz anders gestaltet als ich. Also kein Glück damit.

Ich habe einen Leitfaden zur EJB3-Sicherheit gefunden , wie dort vorgeschlagen, habe ich den folgenden Code in meine standalone.xml -Datei eingegeben:

<security-domain name="other" cache-type="default">
    <authentication>
        <login-module code="Remoting" flag="optional">
            <module-option name="password-stacking" value="useFirstPass"/>
        </login-module>
        <login-module code="RealmDirect" flag="required">
            <module-option name="password-stacking" value="useFirstPass"/>
        </login-module>
    </authentication>
</security-domain>

Aber das löste überhaupt nichts. Ich bin mir nicht sicher, ob es etwas getan hat.

Schließlich fand ich diese SO - Frage: RESTEasy-Unterstützung für JAX-RS @RolesAllowed (die auf die RESTEasy-Dokumentation verweist). Obwohl ich diese Frage auch einige Absätze erwähnt habe, die eine Lösung enthalten, die für mich nicht funktioniert, wurde der Fehler in einen anderen Fehler umgewandelt. Wie dort vorgeschlagen, fügte ich meiner web.xml -Datei einen <context-param> -Block hinzu:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://Java.Sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://Java.Sun.com/xml/ns/javaee http://Java.Sun.com/xml/ns/javaee/web-app_2_5.xsd">
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>PGB</web-resource-name>
            <url-pattern>/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>

        <user-data-constraint>
            <!-- use of SSL is required when CONFIDENTIAL is specified -->
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

    <context-param>
      <param-name>resteasy.role.based.security</param-name>
      <param-value>true</param-value>
   </context-param>
</web-app>

Was ergibt den folgenden Fehler, wenn ich versuche, einen neuen Benutzer zu erstellen (hier aufgrund von Zeichenbeschränkungen von SO - Fragen nicht vollständig gebucht):

16:58:45,992 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-61) failed to execute: javax.ws.rs.ForbiddenException: HTTP 403 Forbidden
    at org.jboss.resteasy.plugins.interceptors.RoleBasedSecurityFilter.filter(RoleBasedSecurityFilter.Java:45) [resteasy-jaxrs-3.0.8.Final.jar:]
    at ... etc.

Dieser Fehler ist auch nicht sehr hilfreich, in der Tat finde ich sogar weniger Informationen, wenn ich nach diesem Fehler suche, als wenn ich nach dem vorherigen Fehler suche. Ich bin mir also nicht sicher, ob dies ein Schritt in die richtige Richtung ist. Was ist besser vom Server zurückgekehrt zu sein? Ein Status 500 (Interner Serverfehler) oder ein Status 403 (Verboten)? Wenn ich nach dem Anwenden dieser "Lösung" die Anmerkung in @PermitAll ändere, funktioniert das Erstellen eines neuen Benutzers genauso wie zuvor, sodass die Situation nicht wirklich verschlimmert wurde.Ich kann jedoch den Quellcode von RoleBasedSecurityFilter finden, der zeigt, dass er die ForbiddenException auslöst. Es zeigt, dass eine bestimmte isUserInRole -Methode true zurückgeben muss, dies aber in meiner Anwendung nicht. Ich kann es nicht wahr machen. Ich wundere mich, Ist es möglich, RoleBasedSecurityFilter.Java von RESTEasy zu deaktivieren? .

Ich habe auch die folgende SO - Frage gefunden: @RolesAllowed kann nicht mit Jersey aufgelöst werden , was von Abhijit Sarkar beantwortet wird, und er verweist auf einen IBM-Artikel . Vielleicht liegt die Lösung für mein Problem darin, aber ich habe es noch nicht gefunden. Jedenfalls wird dort vorgeschlagen, entweder einen security-role -Block zu meiner web.xml -Datei hinzuzufügen oder hinzuzufügen Eine @DeclareRoles -Anmerkung zu meiner UserResource.Java -Datei sollte das Problem lösen. Die Warnung "HTTP 403 Forbidden" bleibt jedoch erhalten, nachdem ich dies getan habe. Das ist sehr frustrierend.

Mein security-role -Block (in web.xml) sieht folgendermaßen aus:.

<security-role id="role_admin"> <description>This is role 1 (admin)</description> <role-name>admin</role-name> </security-role>

<security-constraint>
    <web-resource-collection>
        <web-resource-name>PGB</web-resource-name>
        <url-pattern>/rest/user/create</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint id="AuthConstraint_createUser">
        <description> Only admin can create a new user</description>
        <role-name>admin</role-name>
    </auth-constraint>
    <user-data-constraint>
        <!-- use of SSL is required when CONFIDENTIAL is specified -->
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

login-config-Element (mit FORM-Authentifizierung ) hinzugefügt. Meine Login-HTML-Seite wurde in das erforderliche Format geändert. Ich habe einige der Schritte in diesem Artikel erläutert: Migration einer Java EE-App von GlassFish auf WildFly , aber ich denke, ich habe immer noch etwas falsch gemacht, weil ich immer auf der Anmeldefehlerseite komme, wenn ich versuche, mich mit gültigen Benutzeranmeldeinformationen anzumelden .

Sehen Sie hier das security-domain-Element, das ich meiner WildFly-Konfiguration hinzugefügt habe:.

<security-domain name="app" cache-type="default"> <authentication> <login-module code="Database" flag="required"> <module-option name="dsJndiName" value="Java:jboss/datasources/mySQL_pool_rel"/> <module-option name="principalsQuery" value="select hashed_password from user where email_address=?"/> <module-option name="rolesQuery" value="select role_name, 'Roles' from role r inner join user u on r.role_type = u.role_type where u.email_address = ?"/> <module-option name="hashAlgorithm" value="SHA-256"/> <module-option name="hashEncoding" value="BASE64"/> <module-option name="unauthenticatedIdentity" value="guest"/> </login-module> <login-module code="RoleMapping" flag="required"> <module-option name="rolesProperties" value="file:${jboss.server.config.dir}/app.properties"/> <module-option name="replaceRole" value="false"/> </login-module> </authentication> </security-domain>

Ich würde gerne wissen, wie man rollenbasierte Sicherheit für meine Webanwendung implementiert. Daher akzeptiere ich auch andere Ansätze für rollenbasierte Sicherheit, sofern dies funktioniert. Vorschläge sind willkommen.

Ich habe auch meine Frage auf developer.jboss.org gestellt, aber ich habe dort auch noch keine Antwort erhalten.

Ich habe eine Problemumgehung für mein Problem als Antwort auf diese Frage bereitgestellt, aber es ist keine echte Lösung (wie in dieser Antwort erläutert). Ich bin immer noch daran interessiert, dies richtig zu machen.

I provided one workaround solution to my problem as an answer to this question, but it is not a real solution (as explained in that answer). I am still interested in doing this the right way.

15
PJvG

Hatte gerade das gleiche Problem. 

Es ist die Annotation @Stateless. Die Klasse kennzeichnet Ihre Klasse als EJB und der Container versucht, die EJB-Sicherheit durchzusetzen.

Ich entdeckte dies durch das Schreiben von Filtern und meines eigenen SecurityContext, nur um herauszufinden, dass meine SecurityContext nie referenziert wurde. 

Das Entfernen von @Stateless führte dazu, dass getUserPrincipal() für die SecurityContext aufgerufen wurde.

8
tptptp

Aufgrund des Fehlers "403" scheint es mir, dass Ihre Rollenabfrage fehlerhaft ist. Möglicherweise weist Ihr Anmeldemodul Ihrem Benutzer keine Admin-Rolle zu. Sie könnten beispielsweise einen benutzerdefinierten Authentifizierungsmechanismus implementieren http://undertow.io/undertow-docs/undertow-docs-1.3.0/#authentication-mechanisms (Beispiel: https: // github. com/dstraub/spnego-wildfly ) und ändern Sie es so, dass Sie überprüfen können, welche Rollen Ihr Anmeldemodul Ihrem Benutzer zuweist. Die Implementierung eines benutzerdefinierten Authentifizierungsmechanismus wird einige Zeit in Anspruch nehmen, aber Sie können die Funktionsweise der Sicherheit in Wildfly besser verstehen.

Eine andere Sache, die ich für meine Roles-Anmerkung tun musste, ist das Ändern der Datei standalone.xml und das Festlegen Ihrer Sicherheitsdomäne als Standarddomäne.

Auch das Hinzufügen dieser Zeilen ist für mich ein Schritt in die richtige Richtung. Ohne diese Zeilenanmerkungen funktioniert @RolesAllowed für mich nicht.

<context-param>
    <param-name>resteasy.role.based.security</param-name>
    <param-value>true</param-value>
</context-param>

Ich würde auch raten, die Sicherheit nur mithilfe von web.xml zu implementieren und erst dann @RolesAllowed hinzuzufügen. 

4
Ievgen

Ich habe eine Lösung für mein Problem gefunden. Dies ist jedoch nicht so sehr eine Lösung für das Problem wie eine workaround, da die Annotation @RolesAllowed nicht verwendet wird.

Da ich nicht herausfinden konnte, wie ich meine Implementierungsdeskriptoren und die Serverkonfiguration genau definieren sollte, dachte ich, das Problem wäre viel einfacher zu lösen, wenn ich einfach die Annotation @RolesAllowed nicht verwendet hätte.

Auch wenn andere Benutzer das login-config-Element in ihrer Datei web.xml wirklich verwenden möchten und keine anderen Authentifizierungsmethoden verwenden möchten, verwendet dieser Ansatz dieses Element nicht, sondern nur die Authentifizierung über RESTful Web Services) (was bedeutet, dass sich an den Implementierungsdeskriptoren oder der Serverkonfiguration nichts ändern muss).

Ich habe ein neues Enterprise Java Bean (EJB) mit dem Namen SecurityFilter erstellt, das überprüft, ob ein Benutzer die erforderlichen Rollen für bestimmte Funktionen besitzt. Es ist wie folgt implementiert:

import Java.util.Arrays;
import Java.util.HashSet;
import Java.util.Set;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ws.rs.core.HttpHeaders;
import org.profit.pgb.rest.user.UserService;

@Stateless
public class SecurityFilter
{
    @EJB(name = "UserServiceImp")
    UserService userService;

    public boolean isUserAllowed (String[] rolesArray, HttpHeaders hHeaders)
    {
        Set<String> rolesSet = new HashSet<>(Arrays.asList(rolesArray));

        String uuid = hHeaders.getRequestHeader("user").get(0);
        String token = hHeaders.getRequestHeader("token").get(0);

        if (userService.isAuthorizationTokenValid(uuid, token))
        {
           if (userService.isUserAllowed(uuid, rolesSet))
           {
               return true; // user allowed access
           }
        }   
        return false; // 401
    }
}

Die Methode isUserAllowed wird in der create -Methode von UserResource.Java aufgerufen. Die alte Implementierung dieser create -Methode kann der obigen Frage entnommen werden. Die neue Implementierung sieht wie folgt aus:

@PermitAll
@Path("create")
@POST
public Response create(CreateRequest request, @Context HttpHeaders hHeaders) {  
    if (securityFilter.isUserAllowed(new String[]{"admin"}, hHeaders))
    {
        try {
            System.out.println("Start of create method");
            User user = userService.createUser(request);
            return getCreateResponse(user);
        }
        catch (Exception e){
            return Response.status(401).entity("Failed to create user").build();
        }
    }
    else
        return Response.status(401).entity("Access denied! User does not have permission to create user").build();
}

Wie Sie sehen, ersetzt eine if-else-Anweisung die Annotation @RolesAllowed in diesem Ansatz, und mein Sicherheitsfilter ist etwas anders implementiert.

Dieser Ansatz verwendet HttpHeaders , um die Anforderungsheader (in denen die Benutzer-ID und das Token gespeichert sind) abzurufen. Die akzeptierte Antwort in der SO - Frage " Wie erhalte ich den" Accept "-Header in REST Webservice-Serverseite " hat mir geholfen, wie zu finden erhalte die Anforderungsheader .

Darüber hinaus funktioniert dieser Ansatz, ohne etwas an meinen Backbone.js - und Bootstrap -basierten Webseiten (d. H. Meine HTML- und JavaScript-Dateien) zu ändern.

1
PJvG

Ich habe Ihren Beitrag in meiner Antwort hier gesehen. Ich bin mit der proprietären Sicherheit von JBoss nicht sehr vertraut, und ich empfehle auch nicht, sie in den Code einzubetten, aber ich denke, das ist nicht mein Problem. In Ihrem Code sehe ich security-role oder @DeclareRoles nicht; In meiner Antwort wird eindeutig erwähnt, dass Sie entweder eine für die annotationsbasierte Sicherheit benötigen, um zu funktionieren. Haben Sie das der Kürze halber ausgeschlossen oder haben Sie es vermisst? Wenn dies der Fall ist, fügen Sie der Klasse UserResource@DeclareRoles hinzu und prüfen Sie, ob dies hilfreich ist.

0
Abhijit Sarkar