ok, got it. On Mon, Jan 30, 2012 at 9:35 AM, Gerhard Petracek < [email protected]> wrote:
> hi jose, > > that isn't a discussion about a default implementation. > the suggestion is that we can agree on a default implementation if >we< > implement different approaches and for the other implementations we use cdi > alternatives. this concept allows to switch between the implementations. > > in case of the security module we see multiple suggestions and if we > integrate multiple frameworks, we need a module per framework. in such a > case we don't really need a default implementation. > users just add the impl. module of their choice (to an application) and it > gets activated automatically. > > regards, > gerhard > > > > 2012/1/30 José Rodolfo Freitas <[email protected]> > > > +1 for a thin integration layer for third party based on CDI mechanisms. > > +1 for default implementation. > > I'd suggest Shiro or ESAPI. > > > > ESAPI[1] doesn't seem to be very known, but it's an API that should be > > considered since it's the API developed by OWASP[2] team, based on the > > lines and concerns gathered by that open security group. > > > > [1] http://code.google.com/p/owasp-esapi-java/ > > [2] https://www.owasp.org/index.php/Main_Page > > > > On Mon, Jan 30, 2012 at 8:57 AM, Gerhard Petracek < > > [email protected]> wrote: > > > > > hi @ all, > > > > > > as discussed at [1] the current suggestion is to start with new modules > > > (esp. the jpa and the security module). > > > both will show that we will face very different approaches we need to > > > support. e.g. in case of the security module dan suggested an > integration > > > for apache shiro, shane mentioned picketlink idm and in myfaces codi we > > > have a very thin integration layer for 3rd party frameworks (but no > > > concrete implementation). > > > > > > in general: > > > in myfaces codi we are using cdi mechanisms to handle different > > approaches. > > > if we support multiple approaches, we have only one default > > implementation > > > or only optional implementations. > > > if there is a default implementation, the other implementations are cdi > > > alternatives. > > > in case of interceptors it's similar - it's handled via different > > dependent > > > scoped strategies and the current one (default or an activated > > alternative > > > implementation) gets injected in the interceptor. > > > (since the interceptor-strategies are dependent scoped, there is >no< > > > additional overhead caused by a proxy.) > > > > > > i suggest that we also rely on (the same) cdi mechanisms. > > > > > > a 2nd topic is the usage in other modules (e.g. security concepts in an > > > other deltaspike module). as discussed at [2], we can't use optional > > > dependencies easily. > > > in myfaces codi we keep such basic interfaces in core-api. however, the > > > core would grow quickly as soon as we add further modules (+ we know > that > > > we will see more modules in deltaspike than we intended to have in > > myfaces > > > codi). therefore we could think about a different approach. > > > > > > imo the security module(s) will be the perfect fit to discuss and > > prototype > > > the basic concept. the following part is just an example and is >not< a > > > suggestion to use/integrate the mentioned frameworks: > > > > > > - deltaspike-security-api > > > * deltaspike-security-picketlink-impl > > > * deltaspike-security-shiro-integration-impl > > > * deltaspike-security-xyz-integration-impl > > > > > > all impl. modules are optional -> there wouldn't be a dedicated default > > > implementation. that means other modules only use > > > the deltaspike-security-api. since there is no default implementation, > we > > > would have to use >e.g.< our BeanProvider which allows to resolve > > optional > > > beans easily. that would allow us to support different frameworks and > an > > > implementation gets activated automatically as soon as it gets added to > > an > > > application -> we don't have to choose a preferred approach and even > > > possible add-ons for deltaspike can provide adapters for 3rd party > > > frameworks easily. > > > > > > regards, > > > gerhard > > > > > > [1] http://s.apache.org/QUU > > > [2] http://s.apache.org/qAK > > > > > >
