> I don't like the need to create an additional class to wrap > actions that are to be made secure. (Having written that > complaint I suppose it's really just a matter of having the > original objects implement the right interfaces.) > > My second complaint is that I don't exactly see how to use > Subject.doAs() to control what gets displayed in the UI. It > is very clear how that fits into Turbine actions, but > doesn't seem to fit well in limiting what is displayed. > (Someone correct me if you know how to make that work.) > > If those complaints can be addressed, then I think there may > be good reason to consider JAAS for Turbine security. > > > > Renaming Group -> Project and > > documenting the heck out of it would be the only changes I see as being > > necessary in order to have a pretty functional security system for > > webapps. > > Here are the other things I'd like included: > > 1) Inheritance of permissions. > I would follow the JAAS model of 'permission.implies(...)'. > That would satisfy the use case Jason brought up. If you > want a wepapp without security limits, just set default > permissions that grant every user 'AllPermissions'. > > 2) Support for groups of users in addition to user roles. > Permissions could be assigned by role (e.g. Developer) and > by group (e.g. Denver Office). Both are reasonable ways > assign permissions. "Denver Office" isn't a "role". >
It can be interesting for you that almost the same discussion topic was raised nowadays on the avalon-dev list and (suprise) there are many similarities. Search for McCay's "AAA Security" mail (which has nice design in it) and the thread following it. incze -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
