Hi Curt, >From http://www.jboss.org/developers/guides/jboss.net/security
<p> Hint: Some web service implementations, such as the M$ Soap Toolkit do not send basic authentication data until the server will present them a 401 message. To ensure that the JBossAuthenticationHandler will not route an unauthenticated call with a "null" security association further down the line, but notify the client, you should set the "validateUnauthenticatedCalls" option to "false". See <a href="http://www.nsdev.org/jboss/stories/jboss-net.html";>Neal Sanches investigations about that topic</a>. </p> The default is that unauthenticated calls are routed through with a null association. How do you implement role checking? Through ejb-security or JBossAuthorizationHandler? CGJ -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von jcurt Gesendet: Dienstag, 3. Februar 2004 02:57 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] [JBoss.net] - JBoss.net HTTP Basic Authentication problem View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3819987#3819987 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3819987 I'm seeing unexpected behavior when accessing a secured JBoss.net web service. The web service is configured to require HTTP Basic Authentication. Here are the 3 cases, the third one is the problem: 1. If the SOAP/HTTP request contains a valid username/password (i.e. Authentication header field is set to a valid username+password) then the service can be accessed as expected. 2. If the request contains an incorrect username/password (i.e. Authentication header field set, but invalid username and/or password), then the server returns "401 Unauthorized" as expected. 3. If the request does not contain an Authentication header field entry, the server returns "500 Internal Server Error". In this case, the server should return "401 Unauthorized" so the client's HTTP layer knows that it needs to obtain authorization information (i.e. prompt user for a username & password). As it is, the client has no idea how to deal with the error. I have verified this behavior using a TCP Monitor. Also, I have verified that web applications on JBoss do NOT exhibit this behavior, i.e. they behave as expected in case #3 when accessing a secured html or jsp page. I am using server version: jboss 3.2.1 w/tomcat 4.1.24 Has anyone else dealt with this? Thanks, -Curt ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
