by default implementation I meant a default integration. On Mon, Jan 30, 2012 at 9:16 AM, José Rodolfo Freitas < [email protected]> wrote:
> +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 < > [email protected]> 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 >> > >
