deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <>
Subject Re: supporting different approaches,...
Date Mon, 30 Jan 2012 12:57:53 GMT
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 <>
>> 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