2 Replies Latest reply on Feb 3, 2004 2:47 PM by jcurt

    JBoss.net HTTP Basic Authentication problem

    jcurt Newbie

      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

        • 1. Re: JBoss.net HTTP Basic Authentication problem
          Dr. Christoph Georg Jung Newbie

          Hi Curt,

          From http://www.jboss.org/developers/guides/jboss.net/security


          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
          Neal Sanches investigations about that topic.

          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

          • 2. Re: JBoss.net HTTP Basic Authentication problem
            jcurt Newbie

            Thanks for your reply, CGJ.

            I am doing role checking through JBossAuthorizationHandler.

            After a bit more research I was able to get it to work. I tried setting validateUnauthenticatedCalls option to "false", as in the reference you provided, but it didnt work. I couldnt find any documentation on that option, but a web search led me to this, which described it differently, indicating I should set the option to "true":

            "By specifiying the
            validateUnauthenticatedCalls=true option, the
            handler will however try to interface the
            securityManager with the NobodyPrincipal and an
            empty password and ask for a proper security
            association. This is important when dealing with
            MS Clients (thanks to John Landers for pointing
            this out) that won´t send any authentication data
            if not confronted with an HTTP error on the first try."
            (found in google cache, original doc was gone)

            So I set it to true and it worked... the initial unauthorized HTTP request returned a "401 Unauthorized" response, prompting the client to supply the user/password.

            So it works, at least for now.... however, this comment in the "Neal Sanches investigations" reference is a little worrysome:

            "Another UPDATE: I have been contacted by Frank
            Heldt who let me know that JBoss 3.2.2 breaks the
            @jboss-net.authentication
            validate-unauthenticated-calls parameter."

            I am using 3.2.1... I guess I wont be upgrading!

            Thanks again for your help!
            -Curt