Ed and Angshu, To be honest, I read the e-mail in the dev list and read it here again and I don't quite understand the affect that is being proposed (and I'm pretty technical!).
Can we get some other explanation, or a more specific scenario? I think it'd then be easier to give feedback. For the most part though, I would say we should not change how roles and permissions are set, even if we are changing the underlying security mechanism, without very good reason (and wouldn't hopefully be due to it being stronger/better). Ryan On 9/9/10 10:07, "Ed Cable" <[email protected]> wrote: > 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 -- Ryan Whitney Mifos Technical Program Manager [email protected] Mifos - Technology that Empowers Microfinance (www.mifos.org) Our mission is to enable the poor, especially the poorest, to create a world without poverty. <http://grameenfoundation.org/take-action/ingenuity-fund-challenge/> P please consider the environment before printing this e-mail. ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Mifos-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-users
