payara / Payara

Payara Server is an open source middleware platform that supports reliable and secure deployments of Java EE (Jakarta EE) and MicroProfile applications in any environment: on premise, in the cloud or hybrid.
http://www.payara.fish
Other
882 stars 306 forks source link

Testing secured EJBs with Arquillian and Payara Embedded doesn't work #5148

Closed vgjokaj closed 1 year ago

vgjokaj commented 3 years ago

Description

I am trying to test jee security using the @RolesAllowed and @RunAs annotations in Arquillian and Payara Embedded but to me it doesn't seem to work correctly.

Expected Outcome

If a method is annotated with @RolesAllowed({"User"}) and it is called from an EJB using @RunAs("User"), then it should work correctly and there should be no exceptions thrown.

Current Outcome

Currently the following exception is thrown:

javax.ejb.EJBAccessException: Client not authorized for this invocation

Steps to reproduce

I have created the following simple project to reproduce the bug: https://github.com/vgjokaj/PayaraEmbeddedSecurityTesting

MeroRai commented 3 years ago

Hi @vgjokaj, did you test it on the latest release of Payara Community Edition?

vgjokaj commented 3 years ago

Hi @MeroRai. Yes, I have tested it with Payara Community Edition 5.2021.1 as well and the sample project that I provided doesn't work, but it works with Wildfly though.

After a while I found out that adding a 'glassfish-web.xml' resource with security-role-mappings was necessary for it work. And for each security-role-mapping, the principal-name MUST be specified, otherwise it just doesn't work, ex.:

`

Admin
 <role-name>admin</role-name>

`

Now, I am not sure if this is supposed to work only in combination with glassfish-web.xml resource or it should also be possible to work without it (maybe in combination with @DeclareRoles - which I also tried, but with no success).

smillidge commented 3 years ago

Interesting that the case is different in the mapping. By default Payara will map principal to role automatically but the case is different in your example.

rsoika commented 2 years ago

I run into a similar problem migrating my Jakarta EE8 app form wildfly to payara/micro:5.2021.9-jdk11

I have a EJB with the following annotations:

@DeclareRoles({ "org.imixs.ACCESSLEVEL.MANAGERACCESS" })
@RunAs("org.imixs.ACCESSLEVEL.MANAGERACCESS")
@Startup
@Singleton
public class SetupService {
 ....
}

To get it working I needed the glassfish-web.xml file with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<glassfish-web-app>
    <context-root>${imixs-office.contextroot}</context-root>

    <security-role-mapping>
        <principal-name>IMIXS-WORKFLOW-Service</principal-name>
        <role-name>org.imixs.ACCESSLEVEL.MANAGERACCESS</role-name>
    </security-role-mapping>
</glassfish-web-app>

My glassfish-ejb-jar.xml file is empty.

But to be honest also in Wildfly it was necessary to tweak the jboss-ejb3.xml file:

<?xml version="1.1" encoding="UTF-8"?>
<jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
    xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:s="urn:security:1.1"
    xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
    version="3.1" impl-version="2.0">

    <assembly-descriptor>
        <s:security>
            <ejb-name>*</ejb-name>
            <s:security-domain>${imixs-office.realm}</s:security-domain>
            <!-- This configuration is necessary to enable @runAs for the SetupService  -->
            <s:missing-method-permissions-deny-access>false</s:missing-method-permissions-deny-access>
            <s:run-as-principal>imixs-workflow-service</s:run-as-principal>         
        </s:security>
    </assembly-descriptor>
</jboss:ejb-jar>

I am not sure if this is a helpful comment ;-)

fturizo commented 1 year ago

@vgjokaj, sorry this issue fell under the cracks, we were not able to properly review it on time initially.

Payara Community 5 is out of support, so we are closing this issue but please if you are able to test this issue on the current release of Community 6 and confirm that is no longer a problem, that'd be great.

If the issue is still present in the latest release of Community, please raise a new issue by making a full report with the reproducer so we can take a look at it.