Re: security: why creating thg from scratch?

[Glh <gs...@gmail.com>]

Dear all,

I start a JEE6 project (CDI/JPA/JSF) in a few months and security is a
problem. The 3 main frameworks handling security are (sorry if i miss one):

*- Spring Security:* not a good idea for a CDI-oriented architecture.
*- Apache Shiro:* very interesting but doesn't support multi-stage
authentication and need to be "POCed" because rather "exotic" (different
identity model, not based on JAAS). I lack of time to perform such a POC.
*- Seam Security:* has no future, lack of documentation.

So if we consider that delta-spike security is the future but not available
and not mature enough before a (too) long time; what should we do?

I'm under the impression that you pick the best of several security
frameworks and add some features of your own so how can we choose a security
framework that will not imply a costly refactoring when delta spike will be
available?
I found some answers along this forum (and related-jiras such as "Discuss
Security Module"; yet we need a clear path: 

1) please, what will exactly be the deltaspike security module? 
2) which existing security framework is the closest to the target? 
3) which one will imply the least refactoring?

If the answer is accurate/clear, it would be useful to highlight it: I think
a lot of architects are in the same trouble than me.

I'm not yet very confortable with Apache process so please forgive me if I
ask questions that have already been answered somewhere.

Regards.
Glh

P.S: I don't have the security requirements yet, I just know that
multi-authentication could be required.



--
View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/security-why-creating-thg-from-scratch-tp4653216p4654382.html
Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.

Re: security: why creating thg from scratch?

[Glh <gs...@gmail.com>]

Hi Shane,

Thank you, it helps me a lot :) 

Regards.
Glh



--
View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/security-why-creating-thg-from-scratch-tp4653216p4654386.html
Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.

Re: security: why creating thg from scratch?

[Shane Bryzak <sb...@redhat.com>]

Hi Glh,

The security features that we've implemented in DeltaSpike are intended 
to provide a basic typesafe mechanism for method and class 
authorization, while leaving the implementation side of things up to the 
developer and 3rd party security frameworks.  I'm not sure if other 
security projects have planned support for DeltaSpike, but at JBoss 
we've been very busy working on PicketLink 3.0, which is built on top of 
the DeltaSpike security SPI to provide a full featured security 
framework.  PicketLink 3.0 is the spiritual successor to Seam Security, 
and provides all of the same features (plus a whole lot more).  We're 
very close to a beta release, and hopefully will have a final release 
available over the next few months.  It should also be quite easy to 
integrate other frameworks such as Apache Shiro with the DeltaSpike 
security annotations, someone would just need to put in a little time 
and effort to make it work.

Shane

On 15/01/13 20:50, Glh wrote:
> Dear all,
>
> I start a JEE6 project (CDI/JPA/JSF) in a few months and security is a
> problem. The 3 main frameworks handling security are (sorry if i miss one):
>
> *- Spring Security:* not a good idea for a CDI-oriented architecture.
> *- Apache Shiro:* very interesting but doesn't support multi-stage
> authentication and need to be "POCed" because rather "exotic" (different
> identity model, not based on JAAS). I lack of time to perform such a POC.
> *- Seam Security:* has no future, lack of documentation.
>
> So if we consider that delta-spike security is the future but not available
> and not mature enough before a (too) long time; what should we do?
>
> I'm under the impression that you pick the best of several security
> frameworks and add some features of your own so how can we choose a security
> framework that will not imply a costly refactoring when delta spike will be
> available?
> I found some answers along this forum (and related-jiras such as "Discuss
> Security Module"; yet we need a clear path:
>
> 1) please, what will exactly be the deltaspike security module?
> 2) which existing security framework is the closest to the target?
> 3) which one will imply the least refactoring?
>
> If the answer is accurate/clear, it would be useful to highlight it: I think
> a lot of architects are in the same trouble than me.
>
> I'm not yet very confortable with Apache process so please forgive me if I
> ask questions that have already been answered somewhere.
>
> Regards.
> Glh
>
> P.S: I don't have the security requirements yet, I just know that
> multi-authentication could be required.
>
>
>
> --
> View this message in context: http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/security-why-creating-thg-from-scratch-tp4653216p4654382.html
> Sent from the Apache DeltaSpike Incubator Discussions mailing list archive at Nabble.com.