Mifos Users, Forwarding this thread over from mifos-developer so that end users can respond to Angshu regarding the improvements being made to security and permissioning as we move over to the Spring Security framework.
Angshu is exploring creating higher level roles for security with less granularity. He would like to know if we need to keep security at such granular levels as it is currently. Could you please share your thoughts on the level of granularity you are using with the roles and permissions in Mifos? Are you using Mifos with such granular activities that grouping these into hierarchical roles would affect you? Please see his message below for examples of various scenarios. ---------- Forwarded message ---------- From: Angshuman Sarkar <[email protected]> Date: Sep 8, 8:51 am Subject: Mifos security enhanced To: Mifos Developer regarding hierarchical roles, I think it is possible, technically! We can group granualar activities to higher orders: In "modify role" page, you would find that the permissions are grouped. At the datamodel level, the groups are also activities although they aren't assigned to the role. Possibly they are just for UI display/grouping purpose only. (like "Organization management"). So one possible way is to use these activities as higher level roles. e.g. - following SQL would get you those group level activities -------------------------------------------------- select a.activity_id, a.parent_id, l.lookup_name from activity a left outer join lookup_value l on a.activity_name_lookup_id=l.lookup_id where parent_id is null; -------------------------------------------------- While we hook with spring security, we can have another mapper (like activity_id to role properties file mapping) - this mapper will roll up the granular activities to higher level roles. Instead of using default Spring's default AffirmativeBased access decision voting, we can use UnanimousBased voting mechanism. We can write a custom AccessDecisionVoter implementation, which would do the checks against the higher order activities. This would give us to secure the application at higher levels, for eg. @Secured( {"ROLE_ORG_MANAGEMENT"} ) [example of using custom access decision manager -http:// blog.springsource.com/2009/01/02/spring-security-customization... ] However from what I learnt from Udai, - there are existing customers who use such granular activities - there are apparently activities dynamically created and permissions granted to roles at runtime for reports. (this may change if we move report delivery from a reporting server eventually) So, I guess the question really is - do we want to keep/provide security at such low/granular levels? Technically this is quite feasible, and as described above, we can ride on have existing data model. Please let me know your thoughts. regards ~angshu --------------------------------------------------------------------------- --- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010.http://p.sf.net/sfu/intel- thread-sfd ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Mifos-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-users
