[Acegisecurity-developer] Re: Acegi JSR-168 Portlet Integration
I just reposted the code and have included a DaoPortletAuthoritiesPopulator which is essentially a duplicate of DaoCasAuthoritiesPopulator. Thanks again for the feedback! John Ben Alex wrote: John Lewis wrote: - You are correct that the portlet container performs the authentication and then provides a String username to portlets running within the portlet container. It is very similar to CAS and X509 and I modeled the code after those two quite a bit. Unfortunately, the JSR-168 spec completely delegates the authentication to the portlet-container and does not provide a standard way to plug an authentication mechanism into it. Of course, a portlet container implementation could use Acegi directly (I believe that the Gridsphere team is considering this in the near future). I have not created a default implementation of PortletAuthoritiesPopulator at this point. The only authorities mechanism in JSR-168 is the same isUserInRole method as in the Servlet spec. I suppose we could create a default PortletAuthoritiesPopulator that could be configured with a list of roles to check. It seems a very common requirement for a separate system to authenticate a user and provide only a String-based username to an application. This is seen with CAS, X509, Portlets and a range of external authentication services. Therefore, it would seem desirable to offer a generic equivalent to CasAuthoritiesPopulator/X509AuthoritiesPopulator. Cheers Ben --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Contacts sample app using Annotations
Hi Ben, I have finished the Contacts sample application to use both Spring @Transactional and the new @Secured annotations. However, I currently have it under the same /samples/contacts build structure. I can exclude the samples/attributes project to get around the Java 5 compile issues, we discussed before. I just wanted to confirm (prior to committing) that this is ok... Basically, we will require Java 5 to build from the /samples/contacts dir... To do a full build of Acegi, we require Java 5 (for domain and core-tiger).. just wanted to make sure that this is ok for the samples as well. I didnt want to create a whole new project and duplicate the code just to separate the Java 5 code (1 class really). I just created a different implementation of ContactManager.. one that uses Annotations.. the rest is just replace the implementation in configuration, setup some auto proxies, etc.. and it works great. Again, the original ContactManager using XML configuration for transaction mgmt and security it untouched. So I think its a nice example of comparing and contrasting the two. Right now I just created a new annotated class in the /samples/contacts source dir.. then I reuse the build.xml, etc.. and it just creates an acegi-security-sample-contacts-filter-annotation war file. Anyway, just wanted to confirm if this sounds alright... or if this should be in a completely separate project ala.. acegisecurity/samples/contacts/ acegisecurity/samples/contacts-annotations/ Thoughts? Cheers, Mark
