Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1111017

Summary: Secured EJB in a WAR requires the annotation resteasy.role.based.security set to true
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: William Antônio <wsiqueir>
Component: RESTEasyAssignee: Stuart Douglas <sdouglas>
Status: CLOSED NOTABUG QA Contact: Katerina Odabasi <kanovotn>
Severity: high Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.2.0CC: clichybi, wsiqueir
Target Milestone: ---   
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-15 20:28:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
EJB in a WAR with security annotations
none
EJB in a JAR exposed as a REST resources and secured
none
No role based security parameter
none
Role based security on none

Description William Antônio 2014-06-19 04:41:11 UTC
Created attachment 910244 [details]
EJB in a WAR with security annotations

Description of problem:

The resteasy documentation about EJB exposed as JAX-RS resources warn us the following about the boolean paramenter "resteasy.role.based.security":

"Do not turn on this switch if you are using EJBs. The EJB container will provide this functionality instead of Resteasy. "

This rule, however, seems not to be true for EJB that are in WARs. It seems I need to turn this on parameter.


It, however, is not needed when we uses an EJB in a JAR and lookup it from war using RESTEasy to expose it as a JAX-RS resource.


How reproducible:

Easy. There are two reproducers ready to be used.

Steps to Reproduce:

Find attached two examples:

1) helloworld-rs-ejb-secured: An example that shows the security on an EJB using annotations and using only WAR packaging (EJB 3.1 or EJB Lite);
2) rs-ejb-ear-secured: contains EJBs in a separated EAR and a web application to lookup these EJBs.

In 1, we have an EJB in a WAR("EJB Lite") packaged and exposed as a JAX-RS resource. However, you will also see the parameter "resteasy.role.based.security" set as true in web.xml. In 2, it doesn't have the resteasy.role.based.security set as true, but the EJB is on a JAR and in an EAR deployment.

Actual results:

need to set the parameter to true in reproducer 1.

Expected results:

Reproducer 1 shouldn't require us to set the parameter as true, since it's an EJB.

Additional info:

If this is an expected behaviour, not fix is needed, just an update in the documentation.

Mentioned documentation: https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Development_Guide/sect-JAX-RS_Application_Security.html#Enable_Role-Based_Security_for_a_RESTEasy_JAX-RS_Web_Service1-1

Comment 1 William Antônio 2014-06-19 04:41:49 UTC
Created attachment 910245 [details]
EJB in a JAR exposed as a REST resources and secured

Comment 3 Katerina Odabasi 2014-08-19 10:11:55 UTC
Created attachment 928272 [details]
No role based security parameter

Comment 4 Katerina Odabasi 2014-08-19 10:12:22 UTC
Created attachment 928273 [details]
Role based security on

Comment 5 Katerina Odabasi 2014-08-19 10:13:25 UTC
I used reproducer 1 on 6.3.0.GA. 

The role-based authentication works, however I see Error messages in server side when accessing http://localhost:8080/helloworld-rs-ejb-secured/rest/hello/authorization with user in group norole and resteasy.role.based.security commented out. See attachment error_no_role_based_security.txt

When resteasy.role.based.security is set up on true the more friendly warning shows up on server side. See attachment role_based_security_on.txt

Comment 7 Katerina Odabasi 2014-09-30 08:18:30 UTC
Hello William,

any news?

Comment 8 William Antônio 2014-10-24 21:41:32 UTC
Katerina,

I was on vacations and since I came back I couldn't focus on this issue

I will get back to it on next weeek.

Sorry for any inconvenience.

- William

Comment 9 William Antônio 2015-04-15 20:28:35 UTC
Hello,

I could confirm that what was mentioned by Katherine is true.

I am closing this bug as a "not a bug".