IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  ACL blocks CORS OPTION Request Downstream

    Posted Tue September 24, 2024 07:00 PM

    Hi,

    I might be a noob here, but I do not get it working.

    We have a junction /api that needs to be ACL protected, it should only be available to authenticated visitors.

    This is all working as expected.

    Currently we got a working setup with these CORS settings;

    [cors-policy:myfirstcors]
    request-match = OPTIONS /api*
    handle-pre-flight = true
    allow-origin = https://lalala.com
    allow-credentials = true
    allow-header = x-correlation-id
    allow-header = authorization
    allow-header = content-type
    allow-method = GET
    allow-method = POST
    allow-method = PUT
    allow-method = DELETE
    allow-method = PATCH
    max-age = -1
    expose-header =

    These settings mean that WebSEAL responds to the pre-flight options request and returns above settings.

    Behind this https://lalala.com/api are several microservices published, each with there own set of allow-methods.

    https://lalala.com/api/info only needs GET

    https://lalala.com/api/form only needs GET and POST for example.

    What our developers asked is to forward the pre-flight request to the targeted microservice, so that one returns exactly the correct allow-methods and nothing more.

    So the OPTION request to https://lalala.com/api/info returns allow-method = GET

    The OPTION request to https://lalala.com/api/form returns allow-method = GET and allow-method = POST

    I tried the handle-pre-flight = false option, the LMI states that the request is then forwarded downstream.

    But it doesn't work, I get the impression the ACL on the junction blocks this.

    Is there a way to achieve? Or is this a path I should absolutely not follow?

    Happy to hear.

    Kind regards,

    Derk



    ------------------------------
    Derk Bijmolt
    ------------------------------



  • 2.  RE: ACL blocks CORS OPTION Request Downstream

    Posted Wed September 25, 2024 02:25 AM
    Edited by Shane Weeden Wed September 25, 2024 02:27 AM

    If you want to forward (i.e. allow through) the pre-flight (OPTIONS not OPTION) requests to the backend and have it in turn handle them and return the correct CORS headers, the easiest and fastest way to do this would be to use a preazn Lua HTTP transformation rule to simply skip the ACL check for those pre-flight calls. Here's one documented with how to configure it for the example you have given:

    --[[
        A HTTP transformation that skips the standard authorization decision for matching requests.

        Make SURE you only attach it for HTTP methods and resources that you want to allow through.
        The example below permits the OPTIONS call to the /api/info and /api/form URLs.

        Activated in Reverse Proxy config with:

        ================
        [http-transformations]
        allow_unauthenticated = allow_unauthenticated.lua

        [http-transformations:allow_unauthenticated]
        request-match = preazn:OPTIONS /api/info *
        request-match = preazn:OPTIONS /api/form *

        =============

--]]
Authorization.setDecision("allow")



    ------------------------------
    Shane Weeden
    IBM
    ------------------------------

    Original Message


  • 3.  RE: ACL blocks CORS OPTION Request Downstream

    Posted Wed October 02, 2024 08:11 AM

    Hi Derk,

    I had the same issue. I solved it by adding the following lines to the config:

    [http-method-perms:/api]
    <default> = r
    PUT = m
    DELETE = d
    OPTIONS = T

    Regards,



    ------------------------------
    Paul van den Brink
    ------------------------------

    Original Message


Related Content