I'm trying to implement a fairly simple security policy for an example J2EE application, and am getting the following error when it attempts to do HTTP authentication:
I have implemented an application policy in login-confi.xml, as follows:
I've also implemented the two properties files (my-web-users.properties, and my-web-roles.properties) in the /props folder under config. Finally, I've added the following entry to jboss-web.xml:
And, of course, I have the security-constraint entry in my web.xml. I've spent a number of hours trying to track this down. Does anyone have any idea why JBoss is doing this? Have I messed up the configuration somehow? Thanks in advance.
Can you obtain the TRACE level logs from the jboss security package? Have a look at Q4 at SecurityFAQ to see how the logs can be enabled. Once this logs are obtained, you will be able to figure out what the problem is. In case, you dont get much info out of those, just post those logs here
Well, I added the entries to log4j.xml as the FAQ suggested, but it didn't appear to provide any more logging information (to the console, at least) than before. Here is the first few lines of the message it displays:
It apparently is looking for properties files that are not named according to the name specified in the usersProperties and roleProperties specified. The format used, as you can see from my post, is the same format used for the jmx-console application policy (in fact, it was copied from it, based on an article on security from the JBoss site).
I'll look to see if log4j is sending the log to a file I'm not seeing, rather than to the console, and post it if I find it. Thanks.
Joined: Mar 30, 2006
OK, I found the log file and examined it (it's way too lengthy to post here in its entirety)...it appears that the server can't find a security domain for the application, and is going to a default security domain:
I assume this means that my jboss.xml file is incorrect. There's not much to it:
I guess I'll do some further study of the proper use of the jboss.xml file for web applications...this is to test out an EJB deployment, and I haven't used it for web applications before, so I probably got something wrong.
Your first post mentioned that it is jboss-web.xml, in which case the security domain that you have used was correct. But starting from JBoss 4.0.4(if i remember right), for jboss.xml the security domain needs to be specified as
And, of course, the properties files in the prop directory, as named. Any ideas? Something appears to be in conflict with something else...the application attempts to do an HTTP authentication, but it doesn't appear to know anything at all about this application-policy I have set up. And to answer the unasked question: yes, I have validated that it is the default server in which the configuration is specified, and the default server is running. Thanks.
Joined: Mar 30, 2006
OK, I got the first problem solved, and created another.
I re-read your suggestion again, more carefully this time, and realized that you were telling me I needed a security entry in both my jboss.xml and jboss-web.xml files. I had it in only one of them. So I added it (in the format you suggested) and it worked! Excellent! It got past the HTTP authentication and got to my servlet.
Now, however, it no longer asks for HTTP authentication. I have tried re-deploying the application, restarting the server, all to no avail. Whenever I attempt to access one of the resources (jsp or servlet) it doesn't check for authentication. Dang. Any ideas?
1. I have created an application-policy entry in login-conf.xml named "my-web" in the same format as the entry for "jmx-console" 2. I have a jboss-web.xml file in the WEB-INF folder of my app, configured as suggested. 3. I have a security role and constraint in my web.xml
Excellent idea about securing the jmx console, by the way. I'll set to work on that right away. I don't think the properties directory prop is in my classpath, and I'll fix that right away...I don't remember seeing that in any documentation I read, including the articles you noted, which I read earlier when I started this process. In an attempt to solve the problem earlier, I tried locating these two files in various places my app would know about, such as WEB-INF, the web root, etc. to no avail. I never thought to place it in the classes folder, which theoretically would have the same effect as changing the classpath, but I'll try both, just to see.
As you can see from my previous post, the app is exhibiting some odd behavior still...it got past the initial HTTP authentication when I added a jboss.xml, but now it won't even ask for authentication. Maybe it got sick of me constantly trying to authenticate and gave me persmission...I do that with my kids sometime!
I'll check out these things. Thanks.
P.S. Yes, the names of the files are different. The entry in login-config.xml specifies that the names should be "my-web-users.properties" and "my-web-roles.properties", but the app is attempting to find default files. Which makes no sense, the format of the application-policy entry seems correct. I think your idea about the classpath makes the most sense.
Joined: Mar 30, 2006
Color me stupid...I mean, "challenged"...and mad props to my wife, who pointed out that the system retains information in the form of cookies or retained passwords that persist. I cleared out my cache, and the app is working OK...finding the properties files (they did not have to be on the classpath, just having them in the props folder for JBoss was enough...I guess that means they have to be on the classpath for the server, not the application.
Now I just have to work out the details of qualifying the access to specific EJB methods, as opposed to web resources such as JSPs or servlets. I have it specified, but it isn't failing as it should.
So then you are using "BASIC" as the login form type. Which is the built in browser login screen. Having a "FORM" with a login.jsp is better. The built in browser login screen, 1 is not secure, pure text over the wire, and that browsers cache it.
Good catch for you wife. I'd keep her if I were you.