Hi, +1 for providing a ready-to-use security implementation (i.e. supporting authentication and @RolesAllowed), but -1 for not providing integration for other frameworks. At least we should provide a rich set of extension points for them. There are so many parts of security that we should not expect to find the best solution for all cases, like authentication, authorization (role-based and/or other approaches?), handling of the current security context...
Cheers, Arne -----Ursprüngliche Nachricht----- Von: Shane Bryzak [mailto:[email protected]] Gesendet: Montag, 30. Januar 2012 13:15 An: [email protected] Cc: Gerhard Petracek Betreff: Re: supporting different approaches,... On 30/01/12 18:57, Gerhard Petracek 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 As far as security goes, I don't think we should be using any 3rd party frameworks. I've looked at Shiro and it's quite simplistic compared to what we plan to do, and the existing PicketLink IDM needs an overhaul to simplify its API. What I envision is a new security framework, inspired by the best features wherever we find them, designed from the ground up to take advantage of CDI. I want people to automatically think of DeltaSpike Security as the defacto application security solution when they need to secure their Java EE apps. We also have JSR-351 (Java Identity API) to consider, of which both Bolek and I are members of the expert group - DeltaSpike might be a good place to implement this new specification also. > > 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 >
