On Monday, January 21, 2002, at 12:29 PM, Jon Scott Stevens wrote: > API's like JAAS are great at securing access to source code. But, they > really don't go beyond that without trying to munge them into something > they > aren't.
I think you have the wrong API. There are complaints to be made about JAAS, but I don't think that's one of them. The rest of Java Security is good at limiting how much damage a given program can do to your system by verifying its origins and other measures. JAAS does go beyond that by extending Java Security to also enforce control over what a program is allowed to do when it is run by a particular user. I have two complaints about JAAS in the context of Turbine. 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". -Eric -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
