@RolesAllowed rejects unauthenticated users when they mapped to an allowed (EVERYONE) role

[lmsurpre]

Describe the bug
The special-subject EVERYONE doesn't play well with the @RolesAllowed annotation on JAX-RS resources.

Steps to Reproduce

1. Define a simple webapp with a single JAX-RS resource such as this one thats based on the guide:

package io.openliberty.guides.rest;

import java.util.Properties;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("properties")
public class PropertiesResource {

  @GET
  @Produces(MediaType.APPLICATION_JSON)
  public Properties getProperties() {
      return System.getProperties();
  }

}

2. Add a @RolesAllowed("User") annotation to this class and bind the special-subject EVERYONE to this security-role:

<server description="Auth issue example">

<featureManager>
    <feature>jaxrs-2.1</feature>
    <feature>appSecurity-2.0</feature>
</featureManager>

<httpEndpoint httpPort="${default.http.port}" httpsPort="${default.https.port}" host="*"/>

<webApplication location="guide-rest-intro.war" contextRoot="${app.context.root}">
  <application-bnd>
    <security-role name="User">
      <special-subject type="EVERYONE"/>
    </security-role>
  </application-bnd>
</webApplication>

<webAppSecurity singleSignonEnabled="false"/>
</server>

3. Invoke the endpoint (e.g. http://localhost:9080/LibertyProject/System/properties) without passing auth information. Note that the server rejects the request with status of HTTP 401.

Expected behavior
When the special-subject EVERYONE is bound to a security-role, unauthenticated users should be considered to be in that role and should have access to the endpoints allowed for that role.

Diagnostic information:

• OpenLiberty Version: 20.0.0.4
• Java Version:

openjdk version "11.0.5" 2019-10-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.17.0, JRE 11 Mac OS X amd64-64-Bit Compressed References 20191016_371 (JIT enabled, AOT enabled)
OpenJ9   - 77c1cf708
OMR      - 20db4fbc
JCL      - 2a7af5674b based on jdk-11.0.5+10)

Additional context
If I remove the @RolesAllowed("User") annotation, I am now able to access this endpoint, even when my web.xml includes a security-constraint like the following:

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Properties</web-resource-name>
            <url-pattern>/*</url-pattern>
            <http-method>GET</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>User</role-name>
        </auth-constraint>
    </security-constraint>

If I remove the special-subject mapping and keep this in the web.xml, it returns a 401 as expected. So it seems that special-subject works as expected with the auth-constraint in web.xml.

Similarly, if I add a basicRegistry to the server.xml, then this user is able to access the resource, despite not being explicitly mapped to the seurity-role.

  <basicRegistry> 
    <user name="a" password="a"/>
  </basicRegistry>

So it seems like special-subject EVERYONE is actually behaving the way I would expect special-subject ALL_AUTHENTICATED_USERS to behave.

[arkarkala]

Hi, have you tried using @permitAll annotation? JAX-RS is using the standard security annotations to perform the security checks. The EVERYONE special subject is specific to WebSphere.

[lmsurpre]

Thanks @arkarkala, in our case we normally have a user group mapped to this security-role.
Its only for a handful of special deployments that we'd like to override that binding and map the EVERYONE special subject instead. So, we really don't want @permitAll on the resources.

[prb112]

HI @arkarkala @andymc12 do you have any other approaches or ideas on how to approach the case that @lmsurpre highlights in this issue?

[andymc12]

I chatted with @arkarkala and we think that the reason this is failing is because the RoleMethodAuthUtil is checking that the request is authenticated before checking whether the user is in one of the specified roles. The EVERYONE subject should make the isUserInRole method return true, but we're throwing a UnauthenticatedException before checking the isUserInRole method. We're thinking that if we reverse the order of this, this scenario should work - without breaking more traditional scenarios.

Our plan is to create a test case using the EVERYONE subject and validating that we get the same failure you are seeing - and then swap the order so that isUserInRole is checked before authentication is checked to see if it resolves it.

Hope this helps!

[prb112]

awesome - thank you so much

[andymc12]

Just an update (sorry for the long delay) - in our tests, even when we switched the order so that we check that the user is authorized after checking that the user is in the role, the isUserInRole method still returned false. @WhiteCat22 will be working with @arkarkala to figure out why that is - possibly the test case is mis-configured, or possibly the EVERYONE role is not working correctly with the web container.

[lmsurpre]

@andymc12 we're still quite interested in this one. Having this supported would give us a way to ship a Liberty application which has endpoints that are tied to specific security roles (protected via a JAX-RS @RolesAllowed annotation) while still allowing deployers to bind the "unauthenticated" user to this role.

Is it still on your radar?

[sdehors-ibm]

we are also interested by the support of EVERYONE, any update ? I facing the issue with 21.0.0.9

[WhiteCat22]

@lmsurpre, prb112, sdehors-ibm,

Thank you for your patience, this has been merged into our integration branch and should be released with 22.0.0.3.