> Rodney Schneider <[EMAIL PROTECTED]> writes: > > > ... and diving head first into one of the longest standing issues in > > Turbine land -- the notorious Security Service. > > > > The idea of removing most of the methods of the security interfaces has > > been discussed many times on this list. The archives will reveal a > > sordid tale. I think the final conclusion was to use empty security > > interfaces and allow users to define there own custom security > > services, with a default implementation similar to the current security > > scheme (ie: user, group, role, permission).
Yeah, old issue, big can'o worms. I participated in that old thread months (actually, I think it was more than a year) ago. I still believe we should go this route: * Everything is based on interfaces. * There is a security manager interface that provides two methods: one to authenticate a user given their credentials (to login), and one to determine whether a user is authorized to do something. Nothing more, nothing less. * From here on, there are several choices. I personally have an implementation of a concrete security manager that is pluggable: you specify how you authenticate and authorize (via objects that themselves implement a couple of generic interfaces). This means that I can then implement concrete authenticators and authorizers that, for example, replicate the current Turbine DB-based service, or I can implement null operators, etc., and switch from one to the other via TR.props. It also means that Turbine could ship with a default, simpler security implementation (null) AND a DB-based implementation that can be turned on if the user so desires. Just my opinions. Regards, -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
