I know u are Guru of Struts , that's why i need ur help. I,m a newbie. I 'm involved in a Struts project where the is a need for security. Here is a the application behave. Fisrt, the user need to login into the intranet: he enter his user name and paasword. He accesses, who ever it is the Main Menu of the intranet. The is choses to enter my specific application. Then he enter specific parameter of my app with enables him to get a role. In addition Username + Password + DataX + DataY + Year => a role. I An example of role his supervisor, another else administrator, another else simple user. In my sttruts action , un the action part, i put the roles allowed per action. Now, how should manager my particular role to provide container managed security (if possible) . how should i used "Principal" reauest.getUserPrincipal(), . Or shall i write my own security , and how?
I'm new to Struts as well but have managed to get a reasonable security setup put together. My first bit of humble advice is this: *** don't write your own security layer *** To do this would be more time than it would take you to learn about your application container's security features. Writing your own would also be less secure and less flexible than using the container. (This is not a slam - container security is taken seriously by most vendors and they spend the time to do it "full-on") Ok, that being said... you must now decide on how you want your username/passwd to be stored. Containers usually give you the option of storage in a file or in a DB. If the usr/pwd are already predefined and unlikely to change, the file option might be easiest. But, if you want to be able to add/delete/change users on the fly from within the app, the JDBC option is most likely the best. A word about the JDBC option: in this scenario, because the container (and not struts) will be checking usernames, it may be easier to do your connection pooling on the container level as well. Not that I've heard anything bad about the struts connection pool, but it may be more difficult to set up the container to read from an outside pool than from it's own. A word about hashing: When storing the passwords, you may also want to store the hash of the password rather than the password itself. This ensures that the passwords are unreadable by anyone that is casually browsing the database or security file. Investigate if your container supports this and use it if it does. Then, just decide what URL patterns / subdirectories you want protected, set them up, and away you go. I hope this helps. - JK
They worship nothing. They say it's because nothing lasts forever. Like this tiny ad: