Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-2988

Class-level @RolesAllowed does not affect inherited methods

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Do
    • Major
    • 8.1.0.CR2, 8.1.0.Final
    • 8.0.0.Final
    • Security
    • None
    • Workaround Exists
    • Hide

      As workaround one could extend the ejb-jar.xml to add the desired roles in a method-permission section for the concrete EJB and set the method-name to "*".

      Show
      As workaround one could extend the ejb-jar.xml to add the desired roles in a method-permission section for the concrete EJB and set the method-name to "*".

    Description

      Excerpt from the forum reference:
      Basically I have an EJB which derives from a base class. At the EJB itself there is an class-level @RolesAllowed annotation. With this annotation all methods which are implemented directly in the class can be accessed when the caller has the appropriate role. But when he tries to call a method which has been implemented in the base class, access is denied.

      Reading the EJB 3.2 Spec which says

      Specifying the RolesAllowed or PermitAll or DenyAll annotation on the bean class means that it applies to all applicable business methods of the class.

      I would suggest that this should work. Although this worked with JBoss AS 5.

      Attachments

        Issue Links

          is related to

          Task - Represents a small unit of work that is not end-user facing. WFLY-3837 Add tests for @RolesAllowed use if bean class has superclasses

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          relates to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-24928 [GSS](7.4.z) Annotations not working on class that extends abstract class

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              darran.lofthouse@redhat.com Darran Lofthouse
              daniell_jira Daniel Lechner (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: