hi shane, that's a noble goal. however, i know a lot of users who will never use our security >implementation< - only the api/spi to integrate with the other modules of deltaspike (that's >independent< of what we are providing in this area).
-> -1 for only providing one way of doing things in this case. users should be able to plug in easily. +1 for designing a new and simple module based on ideas of existing solutions, >but< based on a thin generic api used by the rest of deltaspike which can be used also for custom integrations of 3rd party solutions. +1 for providing adapters for existing security frameworks like shiro (or at least we shouldn't block the possibility to implement such custom adapters easily). regards, gerhard 2012/1/30 Shane Bryzak <[email protected]> > 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 >> >> >
