So basically there are two things to decide: 1. IF we provide an implementation for a certain part (i.e. authorization) 2. if that part is default and can be overridden by alternatives OR if there is no default and that part is just a module that can be enabled via putting it into the classpath.
Cheers, Arne -----Ursprüngliche Nachricht----- Von: Pete Muir [mailto:[email protected]] Gesendet: Montag, 30. Januar 2012 14:13 An: [email protected] Cc: Shane Bryzak Betreff: Re: supporting different approaches,... Yes, I certainly agree with the basic approach :-) On 30 Jan 2012, at 13:09, Gerhard Petracek wrote: > yes - since i wrote: >> the following part is just an example and is >not< a suggestion to > use/integrate the mentioned frameworks: >> ... > > it's just about the basic topic how we support different approaches. > there are 2 points: > #1 we provide multiple implementations in one module - e.g. different > persistence strategies -> we have one default impl. and the rest are > cdi alternatives > #2 we don't have an explicit default implementations (we have 0-n "equal" > modules - e.g. in case of the security module we might have multiple impl. > modules) or users aren't interested in using one of our impl. module > at all, but the other deltaspike modules need an api/spi to use it - > >if< the user adds an impl module to the application) > > regards, > gerhard > > > > 2012/1/30 Pete Muir <[email protected]> > >> 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 >>>>> >>>>> >>>> >> >>
