Uploaded image for project: 'Geronimo'
  1. Geronimo
  2. GERONIMO-4587

Array security issue

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.2
    • 2.2
    • security
    • Security Level: public (Regular issues)
    • None
    • Java 6 on OS X 10.5.

    • Patch Available

    Description

      We have a stateless session bean called SSB, with a method called getX:

      SSB#getX(java.lang.String)

      Our security model has 5 roles; admin, anonymous, customer, partner and system. Users can only be in one role. SSB is accessible for all roles, but the getX method does not allow anonymous access. So we have these annotations:

      @DeclareRoles(

      { Constants.ROLE_ADMIN, Constants.ROLE_ANONYMOUS, Constants.ROLE_CUSTOMER, Constants.ROLE_PARTNER, Constants.ROLE_SYSTEM}

      )
      public class SSB ....

      @RolesAllowed(

      { Constants.ROLE_ADMIN, Constants.ROLE_CUSTOMER, Constants.ROLE_PARTNER, Constants.ROLE_SYSTEM}

      )
      public X getX(String y)

      In out test suite I have a simple test case to verify that access by users in the anonymous role (unauthenticated web users) is not permitted for the getX method:

      SSB anonymous_service = LOG_IN_AS_ANONYMOUS_USER....
      X obj = null;
      EJBAccessException eae = null;
      try{
      obj = anonymous_service.getX("test")
      ;
      }catch (EJBAccessException e) {
      eae = e;
      }
      Assert.assertNull(obj);
      Assert.assertNotNull(eae);
      Assert.assertEquals(eae.getMessage(), "Unauthorized Access by Principal Denied");

      We've not had issues with this test case for months. However yesterday we decided to change the method signature of getX to support an optional list of int flags than control the object initialization (which related records to get from the DB):

      public X getX(String y, int... flags)

      After this the test shown above fails. An object is returned back and no exception is raised. The security system still works; we can check the user manually using the SessionContext resource. But the container authorization does not trigger.

      We have also confirmed that the security system fails if a "proper array" is used instead of the "vararg array". We have not had a chance to test whether using a XML-based configuration solves the issue.

      Since the security system is accessible through the SessionContext we work around this issue by manually checking the user role from our code.

      Attachments

        1. G4587.patch
          10 kB
          Lin Quan Jiang

        Activity

          People

            djencks David Jencks
            trygve Trygve Hardersen
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: