deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject AW: supporting different approaches,...
Date Mon, 30 Jan 2012 13:25:23 GMT
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:pmuir@redhat.com] 
Gesendet: Montag, 30. Januar 2012 14:13
An: deltaspike-dev@incubator.apache.org
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 <pmuir@redhat.com>
> 
>> 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