|
Hello Ramandeep, Yes you are indeed describing one of the limitations for traditional JEE security, or perhaps more correctly - pre-JACC JEE security. While providing a JACC provider is on our roadmap in the meantime you can work around the limiation by using hierarchical roles. That is to say you place the parent role within the JEE deployment descriptor. This declaration does not need to change. New users (who presumably require new roles), will be assigned a role that has the JEE role (declared in web.xml) as parent. Note this is a prescription for coarse-grained security. JEE security is providing authentiation and validation that user has at least one of the roles required to hit the app. This means the container will make sure a user doesn't wander into the app unnecessarily by stopping him or her at the front door. Finer-grained checks, i.e. fortress-style permission checks, happen deeper in the app and will enforce the application security controls. The best place for the fine-grained checks is inside spring or application framework as described in this paper/sample application: https://symas.com/kb/using-ansi-rbac-security-enforcement-inside-wicket-6-x-applications/ Shawn On 11/29/2013 07:50 AM, raman nanda
wrote:
-- Shawn McKinney shawn.mckinney@jts.us |