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 >>>> >>>> >>> >
