jaspic-spec
  1. jaspic-spec
  2. JASPIC_SPEC-9

Clarify and/or add TCK test for validateRequest/invoke service/secureResponse ordering

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      Section 3.8.2.2 of the JASPIC spec discusses the invocation of validateRequest after a service invocation for the Servlet Container Profile.

      It does however not give any details under which circumstances the runtime should call this method after a service invocation, and neither does it give any details about how an implementation of this method should distinguish between being called before service invocation (in which its job is to do authentication) and after service invocation (in which its job is to secure a response). For the SOAP profile, footnote 6 in 4.9.5.3 does give an explanation.

      Section 3.8.3.3 says that the semantics of secureResponse are as defined in Section 3.8.2.2, which thus means that secureResponse should be called after a service invocation. Figure 1.1 in Section 1.1 shows this as well, and the general flow as described is Section 3.8 also mentions this.

      Unfortunately, not all JASPIC implementations indeed call secureResponse after a service invocation. GlassFish 3.1.2.2, Geronimo V3.0 and WebSphere 8.5 do make the call afterwards, but the certified implementations of JBoss EAP 6.0.1 (and AS 7.1.1) as well as WebLogic 12.1.1 call secureResponse before a service invocation. In fact, both those implementations call secureResponse nearly immediately after validateRequest is called. In case of WebLogic 12.1.1 this can be deduced from the call stack in debug mode, while in case of JBoss EAP 6.0.1 it can be seen directly in its source code.

      E.g. consider the following abbreviated excerpt from JBoss EAP's WebJASPIAuthenticator:

      GenericMessageInfo messageInfo = new GenericMessageInfo();
      messageInfo.setRequestMessage(request);
      messageInfo.setResponseMessage(request.getResponse());
      
      // [...]
      
      ServerAuthenticationManager sam = getServerAuthenticationManager();
             
      if (sam != null) {
          // Calls through to validateRequest on SAM
          result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh);
      }
      
      if (result) {
      
          // [Jboss specific login]
      
          if (this.secureResponse)
              // Calls through to secureResponse on SAM
              sam.secureResponse(messageInfo, new Subject(), messageLayer, appContext, cbh);
          }
       }
      
      return result; // Service invocation will happen after this if result == true
      

      In case of JBoss EAP, secureResponse is not only seemingly called at the wrong time, it's also an optional operation (default false) but the spec does not mention this operation to be optional.

      I would like to request a TCK test to be added that tests that secureResponse is indeed called after a service invocation, and clarification of the following items:

      • 3.8.2.2 - Why or when would validateRequest be called after a service invocation
      • Perhaps in 3.8.3.3 an explicit statement that secureResponse is to be called after a service invocation and not before.

        Activity

        Hide
        monzillo added a comment -

        the spec states that secureResponse is to be called at point 3 (point 3 is defined to occur after the service invocation), and that the service invocation is only done when validateRequest returns AuthStatus.SUCCESS and the container authorization check succeeds. The only case in which secureResponse must not be called after the service invocation, is when the service invocation throws an exception.

        validateRequest must be called on every incoming request. If for example, secureResponse invokes a challenge response mechanism, validateRequest will be called for the requset that is the response to the challenge from secureResponse (which occurs after the server invocation) This is described in 3.8.3

        Show
        monzillo added a comment - the spec states that secureResponse is to be called at point 3 (point 3 is defined to occur after the service invocation), and that the service invocation is only done when validateRequest returns AuthStatus.SUCCESS and the container authorization check succeeds. The only case in which secureResponse must not be called after the service invocation, is when the service invocation throws an exception. validateRequest must be called on every incoming request. If for example, secureResponse invokes a challenge response mechanism, validateRequest will be called for the requset that is the response to the challenge from secureResponse (which occurs after the server invocation) This is described in 3.8.3
        Hide
        arjan tijms added a comment -

        the spec states that secureResponse is to be called at point 3 (point 3 is defined to occur after the service invocation)

        Indeed, so at least to me this part of the spec seems clear. But apparently, it wasn't clear to the WebLogic and JBoss AS/EAP engineers, since they both call secureResponse before the service invocation.

        Both implementations passed the TCK.

        What would be the best thing to do, to ensure that WebLogic, JBoss AS/EAP and any possible future implementations don't make this mistake (again)? Would just adding a TCK test for this be enough?

        Show
        arjan tijms added a comment - the spec states that secureResponse is to be called at point 3 (point 3 is defined to occur after the service invocation) Indeed, so at least to me this part of the spec seems clear. But apparently, it wasn't clear to the WebLogic and JBoss AS/EAP engineers, since they both call secureResponse before the service invocation. Both implementations passed the TCK. What would be the best thing to do, to ensure that WebLogic, JBoss AS/EAP and any possible future implementations don't make this mistake (again)? Would just adding a TCK test for this be enough?
        Hide
        monzillo added a comment -

        I assigned this to the tck team. I think it would help to check compatibility for this requirement.
        what you are doing is also a great help, in that you are pointing out where the problems are, and
        hopefully the product engineers will be working to fix this product. If you have a way to create an
        issue in their issue trackers that would also help (or send us any info you have on where such info
        could be entered)

        Show
        monzillo added a comment - I assigned this to the tck team. I think it would help to check compatibility for this requirement. what you are doing is also a great help, in that you are pointing out where the problems are, and hopefully the product engineers will be working to fix this product. If you have a way to create an issue in their issue trackers that would also help (or send us any info you have on where such info could be entered)
        Hide
        arjan tijms added a comment -

        I assigned this to the tck team.

        Great!

        what you are doing is also a great help, in that you are pointing out where the problems are

        Happy to do so, it's great that Oracle and the JCP offer the community a vehicle to be able to help.

        If you have a way to create an issue in their issue trackers that would also help

        If have created an issue for JBoss EAP/AS here: SECURITY-727.

        I couldn't find an issue tracker for WebLogic though. It seems they don't have a public one. But since WebLogic is from Oracle and you work for Oracle as well, it might be easier for you to enter this or ask around where the WebLogic issue tracker is located?

        Show
        arjan tijms added a comment - I assigned this to the tck team. Great! what you are doing is also a great help, in that you are pointing out where the problems are Happy to do so, it's great that Oracle and the JCP offer the community a vehicle to be able to help. If you have a way to create an issue in their issue trackers that would also help If have created an issue for JBoss EAP/AS here: SECURITY-727 . I couldn't find an issue tracker for WebLogic though. It seems they don't have a public one. But since WebLogic is from Oracle and you work for Oracle as well, it might be easier for you to enter this or ask around where the WebLogic issue tracker is located?
        Hide
        jhendley added a comment -

        6-18-2015 update:
        added more test coverage for this area (i.e. jaspic 1.1 spec section 3.8.3.1 & 3.8.3.3). This will appear in EE8/CTS8 but not in releases before that.
        -phendley

        Show
        jhendley added a comment - 6-18-2015 update: added more test coverage for this area (i.e. jaspic 1.1 spec section 3.8.3.1 & 3.8.3.3). This will appear in EE8/CTS8 but not in releases before that. -phendley

          People

          • Assignee:
            phendley
            Reporter:
            arjan tijms
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: