Btw, Gerhard on IRC made me aware that the whole security discussion is already heavily Off Topic ^^
It is an important discussion but the current context is: "How to make different impls for various situations possible in DeltaSpike?" So, back to the original topic. there are 2 ways a.) use CDI mechanisms as Gerhard already pointed out. This works in 95% of the cases and is only limited if we already need to know some 'alternatives' while booting the container. In this case we cannot fetch a @Dependent alternative because it just is not available yet b.) some kind of SPI which we implement via a 'ordinal' based configuration approach (for cases where a.) doesn't work out). LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Monday, January 30, 2012 2:31 PM > Subject: Re: AW: supporting different approaches,... > > Oki all good points... > > And all valid points... > > And all pretty heavy points... > > > > Means to ME that we should take a step back and think _really_ _hard_ before > going onti implementing something ;) > > Serious, this is indeed a very complex but also very often needed > functionality. > Not sure if we can do all this in 4 weeks (my _personal_ idea for a 0.2 > timeline) but rather for 0.3 or so. > > Could you please start setting up a wiki page collecting all the ideas please? > > LieGrue, > strub > > > ----- Original Message ----- >> From: Arne Limburg <[email protected]> >> To: "[email protected]" > <[email protected]> >> Cc: >> Sent: Monday, January 30, 2012 2:01 PM >> Subject: AW: supporting different approaches,... >> >> Hi Pete, >> >> At least that sounds like that what I am thinking of ;-) >> >> -----Ursprüngliche Nachricht----- >> Von: Pete Muir [mailto:[email protected]] >> Gesendet: Montag, 30. Januar 2012 13:58 >> An: [email protected] >> Cc: Shane Bryzak >> Betreff: Re: supporting different approaches,... >> >> I think we're suffering from a communication problem here, rather than > a >> different philosophy ;-) >> >> What we are proposing is an API/SPI abstraction which delegates the actual > work >> to other frameworks (or modules if there isn't a framework that does > what is >> needed). The backends could be Shiro, or PicketLink etc. Backends would be >> responsible for providing authentication, authorisation, and identity > management >> services. >> >> To put it another way, what we are providing is the *programming model* for > >> security. >> >> Gerhard, does that sound more inline with what you are thinking of? >> >> On 30 Jan 2012, at 12:45, Gerhard Petracek wrote: >> >>> 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 >>>>> >>>>> >>>> >> >
