[
https://issues.apache.org/jira/browse/GERONIMO-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang reassigned GERONIMO-4587:
-------------------------------------
Assignee: Shawn Jiang
> Array security issue
> --------------------
>
> Key: GERONIMO-4587
> URL: https://issues.apache.org/jira/browse/GERONIMO-4587
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: security
> Affects Versions: 2.2
> Environment: Java 6 on OS X 10.5.
> Reporter: Trygve Hardersen
> Assignee: Shawn Jiang
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
