Hi, I too would like to make an attempt to explain as I can give some concrete examples of how various disparate security models can be made to work in Turbine.
What Dan is describing is basically the assigning of a role of a component by using an interface, it could also be considered a somewhat degenerate form of the Decorator pattern where the Decorator itself houses all the functionality: I believe Dan's examples were SecurityManager, Credentials, and User. Typically the decorator pattern deals with giving a component additional functionality by having that component share an interface, say <operations>, with a set of Decorators that also implement the <operations> interface. So you're adding functionality to the component dynamically instead of using inheritance. What we're talking about here with the security is the interface being empty, the decorator doing everything, and placing these decorators into turbine's system dynamically. Aside: Here's a couple references on the Decorator pattern if you're interested: pg. 175 Design Patterns, pg. 243 Patterns in Java vol. 1. And the clearest example I think I've seen is Bruce Eckel's Thinking in Patterns, can't remember where it is but it's free on the net. 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 the SecurityManger could manage many security models and map them to a portion of your application using a a policy or security region. A case in point that I can think of is Scarab and Helm (Dan and Jon can correct me if I'm wrong). Right now they use different models but as SourceCast evovles they may eventually want to use the same model, or Helm might want to use Turbine. With the system outlined above, Helm could run with its security model and Scarab could run with its own and they could gradually be merged as desired because both models will work simultaneously. I think all the models presented are valid, I'm not trying to sit on the fence: I think that security models that organizations wish to implement are not all going to fall under the same umbrella. 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. The classic pipeline currently has a DefaultACLCreationValve where the ACL based on the fulcrum security service is built up and placed into rundata. So a valve could be made to accompany a security model implementation, you specify this valve in an XML file and you can push whatever want into rundata. People using the push model can make a base Module that can provide convenience methods for dealing with their particular security model, and people using pull can trying using a site policy that I'm going to try and whip up so that various security measures can be applied to regions of the site. Again what I would like to do might be specific to my needs and need not be forced on people not wishing to use it. I'm hoping that a selection of models will be made available on the turbine page. People can then choose what best suits there needs and either use the provided models directly or extend them to fit particular requirements. So we could have a ClassicSecurityModel, a RBACSecurityModel or whatever. So if people agree with general sentitment than I believe within the week I could have the mechanism in place that would allow people to experiment with their own models. 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. I am ready to put in the necessary code to allow this flexibility if people agree. -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
