[security-dev] Fwd: security: why creating thg from scratch?
Bill Burke
bburke at redhat.com
Tue Jan 15 16:01:39 EST 2013
What is "multi-stage" authentication?
On 1/15/2013 10:26 AM, Anil Saldhana wrote:
> Jason,
> I did see this on the apache list this morning.
>
> I think quickstarts such as TicketMonster will help IMO.
>
> Regards,
> Anil
>
> On 01/15/2013 08:04 AM, Jason Porter wrote:
>> Thought if forward this one on to make sure we have it covered.
>>
>> Begin forwarded message:
>>
>>> *From:* Glh <gsouzeau at gmail.com <mailto:gsouzeau at gmail.com>>
>>> *Date:* January 15, 2013, 3:50:32 MST
>>> *To:* deltaspike-dev at incubator.apache.org
>>> <mailto:deltaspike-dev at incubator.apache.org>
>>> *Subject:* *Re: security: why creating thg from scratch?*
>>> *Reply-To:* deltaspike-dev at incubator.apache.org
>>> <mailto:deltaspike-dev at incubator.apache.org>
>>>
>>> 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.
>>>
>>>
>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the security-dev
mailing list