How do I prevent access to JBoss configuration files?

I see it as protecting SOA type. See this article that sums up in general security approach
@ http://soa.sys-con.com/node/232071

For example, this is one real vulnerability due to no authentication, no password or default password in console and mgmt. Actually applicable for other domain in network and web services
@ http://www.articlesbase.com/security-articles/exploitation-and-remediation-of-jboss-application-server-default-configuration-vulnerability-1889469.html

For .htaccess file, I understand that only the lowest .htaccess file along the path affects access; clients can skip over protected directories if they know the URL to lesser protected directories below there. But it is better than direct access w/o authentication. Need to plan for segregation based on the risk appetite of the files or document. In general top level directories are left public and have no ".htaccess" file, while some lower directories might be restricted. Two level of protection might be employed, for example there might be a set of documents that is protected for specific group of hosts only, with one subdirectory inside that also requiring a password to be supplied, to further limit access.

Not full proof though but layer of defense should be in place to secure the appl server as in the article shared above.

Application wise, if possible, should relook at establishing deployment roles to define the logical security view of an application. Only authenticated groups should have access and have audit enabled to track. See 8.1.3 (ref link
Ref: http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch8.chapter.html) for a start.

This link would be of interest, related to the roles and authentication/authorisation mentioned
@ http://www.packtpub.com/article/user-security-access-control-in-jboss-portals

The authentication, and default passwords have already been changed.  This was primarily a concern about protecting the JBoss config files from being accessible.  

The primary cause of their accessibility was a lack of security logic in the servlet, but it started me thinking about someone being able to gain access to the config files in other ways.  I wanted to lock things down as best I could.  

It wasn't exactly the answer I was looking for, but thank you for the articles.  They were helpful in verifying what I'd already done. :)

Wasn't really the solution I was looking for, but you get the points for the effort. :)

Wasn't exactly the solution I was looking for.