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 [mailto:[email protected]]
Gesendet: Montag, 30. Januar 2012 13:15
An: [email protected]
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] http://s.apache.org/QUU
[2] http://s.apache.org/qAK
