Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-11925

CORSFIlter causing failures after moving to 5.x from 13.5.x

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 14.1.1, 14.5.0
    • Fix Version/s: 6.0.0, 14.1.2, 5.5.2
    • Component/s: rest
    • Labels:
    • Sprint:
      AM Sustaining Sprint 43, AM Sustaining Sprint 44
    • Story Points:
      2
    • Needs backport:
      No
    • Support Ticket IDs:
    • Verified Version/s:
    • Needs QA verification:
      Yes
    • Functional tests:
      Yes
    • Are the reproduction steps defined?:
      Yes and I used the same an in the description

      Description

      Bug description

      The change in OPENAM-9606, where the allowed headers are now checked on the Actual request is causing previously working CORS on 13.5.x to fail. The issue is that on Chrome the Origin header is always sent. So nearly every request will end up as sort of treated as "CORS" (even if they are not and so the pain is all the methods, headers are needed to be added).

      Before OPENAM-9606, checking of the allowed headers was in the preflight but it is now enforced in the Actual flow. This is causing issues since proxies that may be injecting headers to the request will break. Note that the CORS specs does not mention stopping or preventing Actual request (it is only mentioned in the preflight section) and so this explicit  enforcement is too strict (or not needed). It seems that neither Tomcat CORSFilter not Spring CORSFilter suffer from such issues (they do enforce preflight allowed-header restrictions).

      Impact: In the context of Proxies or client browser injecting headers, the OpenAM CORSFiiter will prevent request to be service to these clients.
       

      How to reproduce the issue

      Details steps outlining how to recreate the issue (remove this text)

      1. Setup AM
      2. Setup CORS (web.xml) give the origins=*, methods=GET, POST, allowed-headers=x-openam-password,x-openam-username
      3.Test preflight (should work)

      OPTIONS /openam/json/sessions HTTP/1.1
      Host: openam.example.com
      Origin: http://client.example.com
      Access-Control-Request-Method: GET
      Access-Control-Request-Headers: content-type,x-openam-password,x-openam-username
      Connection: close

      1. Test actual call

      GET /openam/json/sessions HTTP/1.1
      Host: openam.example.com
      Origin: http://client.example.com
      DNT: 1
      Connection: close

       (Failure as new header DNT is presented).

       

      Expected behaviour
      Request should pass like a normal flow. But it gets an empty 200 request. When actual request is send it should take any headers. 
      
      Current behaviour
      Unauthorized (since we send a invalid request) for the actual flow
      
      < HTTP/1.1 200 OK
      < Server: Apache-Coyote/1.1
      < X-Frame-Options: SAMEORIGIN
      < Content-Length: 0
      < Date: Mon, 09 Oct 2017 10:51:38 GMT
      
      

      Work around

      1) Tomcat CORSFilter

      OPTIONAL - If you already investigated the code, please share your finding here (remove this text)

      org.forgerock.openam.cors.CORSService.java
          private boolean handleActualRequestFlow(final HttpServletRequest req, final HttpServletResponse res) {
      ....
            // Remove the acceptedHeaders check and let the browser handle this
            // based on what we send back for preflight
      

      Ideally we should let the client browser do the checks and not enforce CORS. What we should do not make sure we send out the correct policy/header decision.

        Attachments

          Activity

            People

            • Assignee:
              chee-weng.chea C-Weng C
              Reporter:
              chee-weng.chea C-Weng C
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: