deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: supporting different approaches,...
Date Mon, 30 Jan 2012 12:45:53 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message