deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From José Rodolfo Freitas <joserodolfo.frei...@gmail.com>
Subject Re: supporting different approaches,...
Date Mon, 30 Jan 2012 11:16:26 GMT
+1 for a thin integration layer for third party based on CDI mechanisms.
+1 for default implementation.
I'd suggest Shiro or ESAPI.

ESAPI[1] doesn't seem to be very known, but it's an API that should be
considered since it's the API developed by OWASP[2] team, based on the
lines and concerns gathered by that open security group.

[1] http://code.google.com/p/owasp-esapi-java/
[2] https://www.owasp.org/index.php/Main_Page

On Mon, Jan 30, 2012 at 8:57 AM, Gerhard Petracek <
gerhard.petracek@gmail.com> 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
>
> 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