Jul 11th, 2007, 03:13 PM
J2EE Container Authentication, Acegi Authorization - Design review
In our organization it is mandatory to use J2EE container-managed authentication. E.g. the container is responsible for authenticating the user and determining the corresponding user roles. These are available to the application using the regular J2EE isUserInRole(), getUserPrincipal() etc. methods.
In the applications itself, we would like to use Acegi for authorization purposes, so we need to make the J2EE user and roles as provided by the J2EE container available as an Acegi Authentication object. I've created a proof of concept for this (attached) using a custom ProcessingFilter and AuthenticationProvider.
The main obstacle here is mapping the J2EE roles to Acegi GrantedAuthorities, as J2EE doesn't provide a method for retrieving a list of user roles. I've overcome this (in the default implementation) by reading the <security-role> elements from web.xml to create a list of all available roles, and then doing an isUserInRole() for each of those to create the list of user roles.
Can anyone please comment on the code that I've attached (apart from missing JavaDoc and such )? Do I have the correct responsibilities attached to the correct classes? Correct naming conventions? Do you think that this code (after polishing) could be added to Acegi itself so this functionality is provided out of the box?
Some things that I'm not sure about in the current version:
- The use of a request attribute to pass the list of available J2EE roles from ProcessingFilter to J2eeWebAuthenticationDetails. Is there a better way for this?
- Is the current AuthoritiesPopulator flexible enough? For example it would be nice to be able to combine an application-specific UserDetails object (retrieved from regular UserDetailsService, possibly with custom GrantedAuthorities) with the default list of J2EE role-based GrantedAuthorities.
- In addition to the current functionality, we need to be able to propagate some security token (LTPA token) when using HTTP remoting. This token is available as a cookie in the HTTP request and should be propagated as a cookie as well. What would be a good place to store this token? Should it be stored as the Authentication credential, as part of the Authentication Principal, as part of the UserDetails, or even something else? Of course, the generic J2EE solution as described above should be extensible to be able to add this custom functionality.
Thanks in advance for your help.
Kind regards, Ruud.
Nov 20th, 2007, 04:00 AM
Thanks for the knowledge share
Thanks a lot for the knowledge share. We are also trying to implement the container based authentication and authorization and using Acegi to do the application security. Can you please share any design docs or materials you have. It will be a big help to me to understand the whole process.
Nov 20th, 2007, 06:33 AM
I've been doing some rework on the code and attached that code to a JIRA issue that I started on this topic: http://opensource.atlassian.com/proj...browse/SEC-576.
Unfortunately I do not have any additional information like design docs available ate the moment.