Use container-managed security, or this filter-based clone, for which I am the project leader: http://securityfilter.sourceforge.net/. The Servlet spec contains the information needed to get started with container-managed security. Your app server documentation will have information about how to configure realms. It may seem complicated at first, but it is much easier than writing your own system.
If you organize your action paths by what role they require, you can just use security-constraints and url-patterns to protect everything: /admin/* limited to users with the 'admin' role /order/* limited to users with the 'customer', 'sales', or 'admin' roles ... etc. If that is the case, that is all you need to do. Or you can protect everything with a security-constraint and / url-pattern. Then add a set of roles that will cover your entire user base. For instance, if every user has the 'admin' role OR the 'customer' role OR the 'sales' role, just add that set of roles to the security-constraint so everyone can get to everything after they login. The reason to protect everything like this is so that the container will authenticate users automatically when they make a request for any of these resources. You will add the real protection for individual actions (using roles) in struts-config.xml later. NOTE: You may also need to un-protect url-patterns like /images/* so that the images will display properly on your login form. You can do that by creating a security-constraint with the /images/* (and /styles/*, etc. -- whatever should be publicly accessible) url-pattern and don't assign any roles to it. Now that you have the container doing the authentication for your whole app, you will want to limit which users can execute a given action by assigning a role (or roles) to each action in Struts. You can do that by specifying a roles attribute in an action-mapping: <action-mappings> <action path="/editOrder" type="my.package.EditOrderAction" name="orderForm" scope="request" input="/editOrder.jsp" roles="admin,sales" /> </action-mappings>The roles="admin,sales" attribute here means that users with either the 'admin' or 'sales' role (or both) will be allowed to execute this action. See my posts in the recent "Verifying integrity of URLs" thread for some ideas on how to do programmatic security when the roles are not specific enough to decide if a user should be able to execute the action or not (e.g. a customer can only see their orders, but not orders for other users). That is a basic overview of how to do Struts security with container-managed security (or a filter-based clone of container-managed security like SecurityFilter). I am a big proponent of using as much standard security stuff as you can (container-managed, or a filter that is a clone of it) because it is easier to implement, generally more secure, generally works better (automatic, just-in-time authentication), and gets along better with other things (like the Struts roles= attribute) than writing your own. Everyone should learn how the container-managed security stuff works before making the decision of what to use for their app. At the very least, there are some useful patterns and behaviors in the standard that will help in writing your own system. Sometimes it still makes to write your own security, but I think we as developers have a tendency to skip over container-managed security before investigating how it could work for us and go right into writing our own stuff. Most of the time, it would be a lot less work and our apps would work a lot better if we just took the time to learn the standard. I am guilty of skipping it over in the past, but it is very clear to me now that learning the standard first is the best approach, even if you don't end up using it directly. -Max ----- Original Message ----- From: "Manganotti Francesco (USI)" <[EMAIL PROTECTED]> To: "Struts Users Mailing List (E-mail)" <[EMAIL PROTECTED]> Sent: Monday, October 06, 2003 12:41 AM Subject: re: authentication Anyone knows a good way to implement AUTHORIZATION with Struts. cheers, F. Questo messaggio di posta elettronica contiene informazioni di carattere confidenziale rivolte esclusivamente al destinatario sopra indicato. E' vietato l'uso, la diffusione, distribuzione o riproduzione da parte di ogni altra persona. Nel caso aveste ricevuto questo messaggio di posta elettronica per errore, siete pregati di segnalarlo immediatamente al mittente e distruggere quanto ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non prendere cognizione della corrispondenza tra altri soggetti, salvo pił grave illecito, ed espone il responsabile alle relative conseguenze. Confidentially notice. This e-mail transmission may contain legally privileged and/or confidential information. Please do not read it if you are not the intended recipient(S). Any use, distribution, reproduction or disclosure by any other person is strictly prohibited. If you have received this e-mail in error, please notify the sender and destroy the original transmission and its attachments without reading or saving it in any manner. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]