On Nov 11, 2010, at 6:26 AM, Oscar Westra van Holthe - Kind wrote: > And honestly, I've not yet encountered a situation where JAAS authorization > was used. I know that JAAS authorization can be used for user authorization, > but specifying the permissions for users and objects in a dynamic way using > JAAS is just too complicated. There are many frameworks offering an easier > solution for this. > > There are only two reasons why I'd implement authentication using a filter: > 1. When I want the HttpServletRequest.getUserPrincipal() to return a (proxy > to a) domain object, or > 2. When I want to use the JAAS LoginModule to it's full extend (i.e. create a > login wizard using multiple calls to CallbackHandler.handle(Callback[]), > like com.sun.security.auth.callback.TextCallbackHandler implicitly does).
And Stripes has nothing to do with JAAS, or security for that matter. The fact that we have a convenient Security Interceptor is just that -- convenience. Now, if someone proposed extending stripes to add ROLE checks much like what JEE does already, but down to the event level, I'd be keen to read about such a proposal. Something that lets folks declaratively annotate events for certain roles, etc. Perhaps reusing the existing JEE annotation that they already have on the EJB tier (not quite sure how that would work out, but...its an idea). But if you were to do that, I'd rather it be off of the standard security mechanisms already in place within the Servlet container (i.e checking the getUserPrincipal, and isUserInRole). If someone wanted to integrate something like Acegi on the front end, but have it still work with a common set of annotations, that might be nice too. But, in theory Acegi can integrate with the existing JEE infrastructure, so I don't know what that really buys anyone. Unfortunately, this is easier said than done, especially before Servlet 3.0. It gets very container specific, especially if you want to propagate the credentials back to the EJB tier in a JEE server. However, there's nothing stopping Stripes from leveraging the existing infrastructure even if it doesn't provide a way to programmatically set the role and principle. If someone uses out of the box Form or BASIC security, the @Role or whatever annotations will do the trick. I know we have our own custom login handler and our own realm for GlassFish, using its programmatic login so it all works within the framework of the JEE server. But its also GF specific, we'd have to port that were we to go to another server. As far as implementing those modules and such in Stripes, that's not its role, frankly. We use Stripes for login forms, and feed those inputs in to our security mechanism. We use a Filter like every one else, but rely on the Principals and Roles back on the EJB tier. Regards, Will Hartung ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
