incubator-deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Bryzak <>
Subject Re: AW: supporting different approaches,...
Date Mon, 30 Jan 2012 12:51:07 GMT
There would of course be extension points for pluggable authentication 
and authorization, something that has existed in Seam Security for many 
years already.  I think our existing design in this area is already 
quite robust, and gives the developer a choice whether to use one of the 
built-in implementations, or to (easily) implement their own.

On 30/01/12 20:29, Arne Limburg wrote:
> Hi,
> +1 for providing a ready-to-use security implementation (i.e. supporting authentication
and @RolesAllowed), but
> -1 for not providing integration for other frameworks. At least we should provide a rich
set of extension points for them. There are so many parts of security that we should not expect
to find the best solution for all cases, like authentication, authorization (role-based and/or
other approaches?), handling of the current security context...
> Cheers,
> Arne
> -----Urspr√ľngliche Nachricht-----
> Von: Shane Bryzak []
> Gesendet: Montag, 30. Januar 2012 13:15
> An:
> Cc: Gerhard Petracek
> Betreff: Re: supporting different approaches,...
> 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]
>> [2]

View raw message