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(a)gmail.com <mailto:gsouzeau@gmail.com>> >> *Date:* January 15, 2013, 3:50:32 MST >> *To:* deltaspike-dev(a)incubator.apache.org >> <mailto:deltaspike-dev@incubator.apache.org> >> *Subject:* *Re: security: why creating thg from scratch?* >> *Reply-To:* deltaspike-dev(a)incubator.apache.org >> <mailto:deltaspike-dev@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Not sure if it is about the multi-step one. Then it would be like in SSO with few possible redirects and additional steps. You need to be able to check in which step of the process user is. At least thats how I understand it but I may be wrong :) On Jan 15, 2013, at 10:01 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > 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(a)gmail.com <mailto:gsouzeau@gmail.com>> >>>> *Date:* January 15, 2013, 3:50:32 MST >>>> *To:* deltaspike-dev(a)incubator.apache.org >>>> <mailto:deltaspike-dev@incubator.apache.org> >>>> *Subject:* *Re: security: why creating thg from scratch?* >>>> *Reply-To:* deltaspike-dev(a)incubator.apache.org >>>> <mailto:deltaspike-dev@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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev