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