deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <pm...@redhat.com>
Subject Re: supporting different approaches,...
Date Mon, 30 Jan 2012 13:04:01 GMT
Sorry, yes, I was to specific calling out Gerhard ;-)

On 30 Jan 2012, at 12:57, Pete Muir wrote:

> 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 <sbryzak@redhat.com>
>> 
>>> 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
>>>> 
>>>> 
>>> 
> 


Mime
View raw message