[jboss-jira] [JBoss JIRA] (WFLY-2129) @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration

[Kabir Khan (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2129:
-----------------------------
    Fix Version/s: 11.0.0.Final


I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.

> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2129
>                 URL: https://issues.jboss.org/browse/WFLY-2129
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Mac OS X
>            Reporter: Nicky Mølholm
>            Assignee: Jim Ma
>             Fix For: 11.0.0.Final
>
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc) 
> A simple EJB with a Web service view can illustrate the first problem: 
> {code:java}
> @Stateless 
> @WebService 
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> 	@PermitAll // <-- This doesn't work
> 	//@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> 	// <--- unless you put them on class level 
>     public String sayHello(String name) {
>         System.out.println("******** Greeter.sayHello(" + name + ")");
>         return "Hello " + name;
>     }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>  
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll, at DenyAll, at RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>  
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)