[seam-issues] [JBoss JIRA] Created: (JBSEAM-4494) Authorization is not working when using drools based security in Seam 2.2

[Parvathy V (JIRA)]

Authorization is not working when using drools based security in Seam 2.2
-------------------------------------------------------------------------

                 Key: JBSEAM-4494
                 URL: https://jira.jboss.org/jira/browse/JBSEAM-4494
             Project: Seam
          Issue Type: Bug
          Components: Drools, Security
    Affects Versions: 2.2.0.GA
         Environment: Windows XP,Drools 5.0.1, Seam 2.2.0, JDK1.6, JBoss AS 5
            Reporter: Parvathy V


I am using Seam 2.2 with drools based security for authentication and authorization in my application. During the security check for CRUD persistence at Entity Level, I get "org.jboss.seam.security.AuthorizationException: Authorization check failed" message when accessing functionality for all the roles when the EntitySecurityListener is on. The authentication works, but authorization is not working as expected. The rule in my security.drl file is as follows:

rule "Entity View"
                no-loop
                activation-group "permissions"
                when
                                check: PermissionCheck( target == "entity1", action == "read" )
                then
                                check.grant();
end
All other configuration such as additions in component.xml and orm.xml seemed to be correct. I used drools:rule-base & RuleBasedPermissionResolver for authorization.

So I debugged using the source code of Seam 2.2. Inside RuleBasedPermissionResolver, the method hasPermission(Object target, String action) is invoked to decide whether permission should be allowed. The target passed in is an instance of the entity com.entity.Entity1, which has the seam component name "entity1". Since no role was mentioned in the security.drl, I expect the hasPermission method to return true when I try to perform a read operation on an Entity1. However, it returns false,causing the AuthorizationException to be thrown. The execution flow inside the hasPermission method is as follows:

1. The securityContext is obtained and checked for null value. It is not null.
2. The synchronized block is entered.
3. The target is an instance of Entity1. It is not an instance of String or Class. Hence it enters the first loop.
4. A new instance of PermissionCheck is created, which has the granted attribute set to false.
5. securityContext.fireAllRules() is invoked. The target which is an instance of Entity1 does not match with the Seam component name, which is a String, given in security.drl file; hence the above mentioned rule is not fired.
6. The check.isGranted() method returns false.


I made a change in the first if construct of hasPermission method as follows, similar to the code in the second if construct. After this, my application's security works just fine:

public boolean hasPermission(Object target, String action)
{
.......................
.......................
                .......................
                synchronized( securityContext )
                {
                                if (!(target instanceof String) && !(target instanceof Class))
                                {
                                                //commented out the existing one line of code below
                                                //handles.add( securityContext.insert(target) );
                                                //added the following two lines of code
                                                String componentName = Seam.getComponentName(target.getClass());
                                                target = componentName != null ? componentName : target.getClass().getName();
                                }
                                else if (target instanceof Class)
                                {
                                .......................
.......................
.......................
                                }

                                .......................
                                .......................
                                .......................
                }
                
                return check.isGranted();
}

I would like to know whether the above is a bug in the framework, or whether my target is supposed to enter this method as a String or an instance of Class. Alternately, should I change the way the rule is defined in security.drl?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira