> By using this method, someone could use any security mechanism > they wanted. > They may be able to start simple if they want, even using a > simple text file > and they can evolve their security model as they need to or move > to a model > written by another. It might even be nice to allow many models to > run in the > same application so that other systems could be integrated or allow > selective migration to other models. Maybe the SecurityManger could > manage many security models and map them to a portion of your application > using a policy or security region.
This would be great! > Right now with the pipeline in place and functioning it would be > possible to > implement this system, and I think I could get the skeleton in there this > week. That would also be great! Three things: * It would be very good if we could standardize on the names used for different entities in the model: I have used User, Credentials (password), Permissions, etc., others have used different terms. Is there a standard we can follow? * It would be very good if Turbine's default implementation of the security model did not require a DB; this way, we would be lowering the requirements for new users to install Turbine. * I think it is necessary to port Turbine's current security implementation, along with a couple more implementations long overdue (LDAP!) to this new security model. > I think that it is painfully evident that trying to extend > or modify the security mechanism we have doesn't work very well. > People are > always asking questions, the nomenclature is confusing, and nobody has > really volunteered to write any documentation because it's a bit > overwhelming. Absolutely! > I am ready to put in the necessary code to allow this flexibility > if people agree. +1, and my offer to help you with anything you need. Let me know. > Jason van Zyl -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
