As we all know, its possible to define attribute level security for ADF BC EO and control update operation. However, there is one catch - users granted with create access for the same EO, will be able to insert values into restricted fields during new row creation. These values will be stored during new row commit, typically we would like to avoid such situation and preserve consistency between different modes (update or create) for the same EO attributes. We can achieve this by overriding EO create() method and checking EntityAttributePermission class against row attributes.
Download sample application - ADFEOSecurity.zip. ManagerId and DepartmentId attributes are selected to be editable only by managers-role:
There is user in the system, who is not granted with managers-role - redsam2:
Let's use redsam2 user to perform our tests:
This user is not granted editing privileges for ManagerId and DepartmentId attributes, as expected these fields are disabled:
Press Create button now - disabled fields are becoming enabled, user can type data and commit:
Unauthorized user can save values for these fields, user is not authorized to update:
We can prevent such behavior during new rows creation by overriding ADF BC method - create(), on EO level:
Through this method we can access attributes of newly created row and check security permissions against those defined in jazn-data.xml. We can assume, if user don't have editable access to certain attribute, same level of security restriction must be applied for newly created row as well. We are iterating over the set of attributes and through EntityAttributePermission class validating if current attribute can be updated by current user. If no, attribute is set with readonly flag:
It works now much better - secured attributes for update, are protected during new row creation as well:
Download sample application - ADFEOSecurity.zip. ManagerId and DepartmentId attributes are selected to be editable only by managers-role:
There is user in the system, who is not granted with managers-role - redsam2:
Let's use redsam2 user to perform our tests:
This user is not granted editing privileges for ManagerId and DepartmentId attributes, as expected these fields are disabled:
Press Create button now - disabled fields are becoming enabled, user can type data and commit:
Unauthorized user can save values for these fields, user is not authorized to update:
We can prevent such behavior during new rows creation by overriding ADF BC method - create(), on EO level:
Through this method we can access attributes of newly created row and check security permissions against those defined in jazn-data.xml. We can assume, if user don't have editable access to certain attribute, same level of security restriction must be applied for newly created row as well. We are iterating over the set of attributes and through EntityAttributePermission class validating if current attribute can be updated by current user. If no, attribute is set with readonly flag:
It works now much better - secured attributes for update, are protected during new row creation as well:
3 comments:
Hi,
and again a good example! But the class oracle.adf.share.security.authorization.EntityAttributePermission is deprecated in the new JDEV/ADF. The javadoc says nothing but maybe we must use the oracle.adf.share.security.authorization.AttributePermission instead.
AttributePermission permission = new AttributePermission(attrDef.getFullName(), AttributePermission.EDIT_ACTION);
Martin
Hi,
Yes, I was asking Oracle. They said its safe to use this class, even its marked deprecated. At the end, even jazn-data.xml is using same class to define EO Attribute permission - EntityAttributePermission.
Thanks for asking.
Andrejus
FYI: jazn-data.xml is using EntityAttributePermission, so AttributePermission check never would work.
I had same thought as well...
Regards,
Andrejus
Post a Comment