> "Depending on the container, your groups and group memberships can be > dynamically mapped to roles, with declarative specification of what > resources can be accessed." > > Is this the case with tomcat? I did not think so. > > Our needs our very similar. > The users with a admin page that allows them to change access to pages.
I haven't used Tomcat to do it, but it appears that this document addresses some of the details: http://www.jaydeetechnology.co.uk/planetjava/tutorials/server/SecuringJavaWe bApplications.pdf It looks like you can use JDBC, XML files, or JNDI (allows LDAP) to retrieve your users, etc. > > "This didn't meet our needs, so we went a step further with a ServletFilter. This is nice because it puts > > all of your security in one place rather than sprinkled across a variety of Actions, ActionMappings, etc. > > If you have access to a servlet 2.3 container, use this as your second option." > > Is this checking based on checking the requested the action_mapping against > a dynamic list of allowable action_mappings? > > Is there an area I can look that suggests how to implement this type of > dynamic security with a servlet filter? I didn't have anything to follow, but it sounds like declarative security via Tomcat can meet your needs. In my implementation, users belong to groups (roles), and groups are authorized for resources matching certain patterns. We store a list of resources a user is authorized for in their session (there is also a list of globally accessible resources), check the attempted URL against the user's list, and process or deny the user's request based on that. I don't know that it's the best implementation, and overall, I'd say to stick with container managed security. Our need to go beyond CMS was caused by a requirement to run different sites with different user groups from within the same web-app. We were concerned about the security implications of a user being authenticated with certain privileges being able to access sensitive data on another site. > Sorry for the simple questions. > > It is a new area for us. Not a problem - web apps seem to be getting more complex yet powerful by the day.... -Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
