I am not sure what you are trying to do here. Your application does not need to know what roles a user has with regard to url restriction. That is what container managed authentication is for. However, the servlet spec provides for a getUserPrincipal and isUserInRole methods. Note that if you update a user account while they are logged in, the change will not take effect. This is due to the roles being cached by both Tomcat and JBoss. I believe there is WIP on a feature request to allow dynamic updates though.
Your application does not need to know what roles a user has with regard to url restriction.
Then I don't understand. I think my application does need to know what roles a user plays. When the user logs in, if he's only a member, then I will allow him basic functionality (a limited number of views w/ permissions to edit certain fields), but if the user is *gold* or *platinum* member, then the user is allowed access to more resources on the site.
And since all of my views are database driven and accessed w/ url's that map to controllers, I'd think my app does need to know.
How and why would the web container need to know which links some of my pages should include or what data in the database the user gets access to ... maybe I'm not understanding your comment.
Following the Java Enterprise Edition's container managed security spec, you can set (in your web.xml) what url's can be accessed by users with certain roles. This is all external to your application. Your original post only mentions restricting pages to roles. To use your example. If a user with role 'member' logs in to your app, they would not be allow access to a url that a user with role 'gold' or 'platinum' has.
This may not be fine grained enough for you. If for example you have a view page whose content is dependant on the user's role. Currently I have never crafted such an application. So I can only speculate. But I would see your view making descision of what to display based on the user's role. In such a case then you would need to access. Also in such a case you can use the methods I mentioned before.
I just think it is better to externalize these descions as much as possible and whenever possible.
Hope this clarifies things, cgriffith
I think I understand what your saying about URL access based on roles, but it sort of seems like added complexity, waste of page work, lots of duplication to me. For example, I have a common menu bar for all users with only minor changes to the available menu items. This menu bar is a single page inclusion using my templating system (sitemesh).
But when accessing roles based on URL's ... instead of putting something in a page that says, "leave this option out" based on user role X, I would have to create completely separate menu bar templates for every role instead of one single template that knows how to make it's own decicions based on role X.
Does that make sense?
HttpServletRequest.isUserInRole("member"), etc. is the only supported check for querying a user to role relationship. You can get the associated Subject and look at the principals set java.security.acl.Group instance named "Roles" to see all of the caller roles. This is jboss specific logic.