Yeah, same here on JAAS - it's good for locking parts of the codebase if you really needed to but way too cumbersome for web app security. Heh, as the committer and maintainer both in Tynamo and Shiro, I kind of have to recommend them.
Kalle On Wed, Jun 1, 2011 at 2:35 PM, Lenny Primak <lpri...@hope.nyc.ny.us> wrote: > The closest to CMA that I've used was JAAS. I didn't like it. Sounds like you > are recommending tynamo and shiro. > > > > On Jun 1, 2011, at 5:19 PM, Kalle Korhonen <kalle.o.korho...@gmail.com> wrote: > >> I see - should have said I assume you are using CMA. I'm biased of >> course, but when ever I've used CMA, I've found it too cumbersome and >> limiting. >> >> Kalle >> >> >> On Wed, Jun 1, 2011 at 2:03 PM, Lenny Primak <lpri...@hope.nyc.ny.us> wrote: >>> Thanks! I am not using CMA actually, it is JSP home-grown security, >>> which I am looking to replace. >>> In your opinion, should I look use CMA or go with tynamo & shiro? >>> I guess I can do a bake-off but I would rather not. >>> >>> On Jun 1, 2011, at 4:29 PM, Kalle Korhonen wrote: >>> >>>> The big three for Java are CMA (Container Managed Authentication) >>>> which you are using, Spring Security (ex-Acegi Security, Tapestry >>>> integration provided by tapestry-spring-security module) and Apache >>>> Shiro (ex-JSecurity, Tapestry integration provided by Tynamo's >>>> tapestry-security). I've spent more time with all of them that I care >>>> to admit, and I've moved through them in that order in search of more >>>> flexible security framework that allows me to do what I want without >>>> getting in the way. Shiro is by no means perfect (which is why I >>>> signed up as a committer) but from my experience, by far the most >>>> flexible. For OpenId and Oauth there are several projects available >>>> and you can piecemeal it together to your home-grown security >>>> framework or CMA if you really wanted to, but I wouldn't recommend. >>>> >>>> Kalle >>>> >>>> >>>> On Wed, Jun 1, 2011 at 12:40 PM, Lenny Primak <lpri...@hope.nyc.ny.us> >>>> wrote: >>>>> Thanks guys I'll definitely look at tynamo security. >>>>> There is a lot of homegrown code in our implementation that feels like it >>>>> should be a part of a framework that's already been written. I guess that >>>>> tynamo security is that framework. >>>>> >>>>> Anything else I should be l should be looking at in this space? Perhaps >>>>> not necessarily tapestry related? >>>>> >>>>> >>>>> On Jun 1, 2011, at 2:11 PM, "Thiago H. de Paula Figueiredo" >>>>> <thiag...@gmail.com> wrote: >>>>> >>>>>> On Wed, 01 Jun 2011 14:33:47 -0300, Lenny Primak >>>>>> <lpri...@hope.nyc.ny.us> wrote: >>>>>> >>>>>>> My current project is to refresh a client's web site using tapestry. >>>>>>> The web site currently uses JSP. We have a JEE/web service backend >>>>>>> that uses JPA/EJB3.1 which we will continue to use. >>>>>>> We now have a JEE based authorization service API based on plain method >>>>>>> calls now. >>>>>>> What we want is to keep the current login scheme and add LDAP and >>>>>>> possibly Facebook ID and openid. >>>>>> >>>>>> For using Facebook ID and OpenID, check >>>>>> http://tynamo.org/tynamo-federatedaccounts+guide. Beyond that, I can't >>>>>> see why using the existing API in Tapestry would be different from your >>>>>> existing code, besides that Tapestry templates don't allow code >>>>>> (scriptlets). I'd suggest you to build some components to encapsulate >>>>>> common scenarios (something like a IfUserHasPermission component), maybe >>>>>> a couple mixins, and using the ComponentRequestFilter and/or >>>>>> RequestFilter pipelines for cross-page logic. >>>>>> >>>>>> -- >>>>>> Thiago H. de Paula Figueiredo >>>>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, >>>>>> and instructor >>>>>> Owner, Ars Machina Tecnologia da Informação Ltda. >>>>>> http://www.arsmachina.com.br >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
