another question to authors

[bas duijzings]

Hi,

Do you describe anything about the requestprocessor, overwriting it etc ? When I look at the table of contents it does not really mention this.

regards,
baz

[friso dejonge]

he baz,
long time mate, but take a look at chapter 7 which is downloadable, this may answer your question.
(http://www.manning-source.com/books/franciscus/franciscus_chp7.pdf)
cheers,
friso

[Marc Peabody]

The Internationalization chapter may cover the topic, as the RequestProcessor class is mentioned in the chapter's description.

(looks like friso beat me to the post)
[ January 25, 2005: Message edited by: Marc Peabody ]

[George Franciscus]

There is no recipe on how to override the RequestProcessor per se. However, we do show you how to do that in the context of a problem you want to solve. There is a recipe on how override the RequestProcessor to use your own security mechanism to secure action mappings (recipe 7.5 Customized action mapping security). If you need to override the RequestProcessor for some other reason, this recipe will show you how to do that. That recipe is available for download in chapter 7.

Other than that, we talk about the RequestProcess a lot. Its mentioned whenever its useful to explain how things work.

[bas duijzings]

wow, that is some chapter. However one thing is a concern on the security part of this. Maybe this is outside the scope of the book, but it would be nice if we could discuss...

The username and password in the tomcat-users.xml are hardcoded and visible to anyone who has access from the inside. To me this sounds like storing unhashed passwords in a flat file which is a danger.
Also how can you add users interactively, are there any tools, api's or do you have to write them yourselves.

To bypass this my solution would be to store the usernames and passwords in the database and get the userrole when the user logs in. This also comes from the database. Then in the processroles you just check if the user has the same role (in the session) as what is needed for an action.

Am I still making sense, anyone wants to comment on this ?

[George Franciscus]

I'm not a Tomcat expert, so I can't comment on external tools to add user/id pwd. However, I would agree with you that its not a good idea to keep clear text user info in a flat file.

A better approach is to wire up another security framework (i.e LDAP). I *think* I read that you can wire Tomcat to some other security framework, but a cursory search through the tomcat documentation reveals nothing.

If there is no way to wire up Tomcat to another security framework, then you can use the 7.5 Customized action mapping security recipe to do it through Struts.

A easy way to encrypt the password is to use the Java Cryptography Extension (JCE) API. When the user registers a password, you use JCE to do a one way hash. You store the hashed password in the database. When the user authenticates, you hash what they entered and compare it the stored value in the database. This way nobody knows the value of the password (even the DBA) except for the user. To protect the password from a dictionary attack, you prepend (or suffix) it with a constant (random text is best) - a technique called salting. There is a great article on developerworks on this.

http://www-128.ibm.com/developerworks/edu/j-dw-javasec1-i.html

[bas duijzings]

I'm not a Tomcat expert, so I can't comment on external tools to add user/id pwd. However, I would agree with you that its not a good idea to keep clear text user info in a flat file.
A better approach is to wire up another security framework (i.e LDAP). I *think* I read that you can wire Tomcat to some other security framework, but a cursory search through the tomcat documentation reveals nothing.

I think i found it in the tomcat 5.5 documentation. This seems to answer my questions. http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html#JDBCRealm
can connect to a database and get the roles from there. So there must be a way to get them encrypted with this as well.

thanks for the pointer.