IBM Security Verify

 View Only
Expand all | Collapse all

Question around CORS support

  • 1.  Question around CORS support

    Posted Mon February 11, 2019 01:03 PM
    We are trying to set CORS headers , Access-Control-Allow-Origin = * in below section, is there a way to specify multiple domains instead of star? is there a way to handle or set this using HTTP Transformation? FYI- CORS spec is not allowing to set multiple domains

    [rsp-header-names]

    #
    # This stanza is used to define static HTTP headers which will be added
    # to every HTTP response from the WebSEAL server. This will provide the
    # administrator with the ability to insert some standard security headers
    # into the response, such as strict-transport-security,
    # content-security-policy and x-frame-options.
    #
    # Please note that the headers which are defined in this stanza will replace
    # any matching headers which might have been added to the response by a
    # junctioned application.
    #
    # If multiple headers of the same name are specified in this stanza all
    # but the last of the matching entries will be ignored.
    #
    # The format of each entry in this stanza is:
    # <header-name> = <header-value>
    #
    # For example,
    # strict-transport-security = max-age=31536000; includeSubDomains
    #
    # A special <header-value> of '%SESSION_EXPIRY%' can be used to
    # designate a header which will contain the remaining length of time, in
    # seconds, before the current local session expires. This value does not
    # include the overall session timeout for sessions which are managed by
    # the distributed session cache (DSC), but just the length of time before
    # the session expires in the local cache.
    #
    # For example:
    # session-timeout = %SESSION_EXPIRY%
    #
    Access-Control-Allow-Origin = *



    ------------------------------
    Sairam Durgaraju

    ------------------------------


  • 2.  RE: Question around CORS support

    Posted Mon February 11, 2019 11:55 PM
    Sairam,

    The 'rsp-header-names' configuration entry is only designed to allow static headers to be inserted.  So, if you only have a single domain, or wish to allow all domains, you can use this configuration entry.  However, if you have more than one domain your only current option is to use HTTP transformation rules.  However, one issue with using HTTP transformation rules is that you have to create a 'response' transformation rule in order to set the response header, and the original HTTP request is not accessible from a 'response' transformation rule.  This means that you can't use the host header (or anything else from the request) when determining what value to set for the Access-Control-Allow-Origin header.  We currently plan to remove this restriction in the next release (due to be released towards the middle of the year).

    Thanks,

    Scott.

    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------



  • 3.  RE: Question around CORS support

    Posted Mon March 11, 2019 11:31 AM
    Thanks for the details, any idea which version of ISAM will have CORS multiple domain features available?

    ------------------------------
    Sairam Durgaraju
    Cigna
    ------------------------------



  • 4.  RE: Question around CORS support

    Posted Mon March 11, 2019 04:11 PM
    Sairam,

    The upcoming 9.0.7. release (which is due out in June) will allow you to use elements from the request when building a response HTTP transformation rule.  You will be able to use this capability to handle CORS multiple domains.

    Thanks,

    Scott.

    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------



  • 5.  RE: Question around CORS support

    Posted Wed January 22, 2020 06:54 AM
    Hi Scott,

    Apologies for reviving this thread, but I have an additional request for this; wouldn't it be simpler if you allow us to modify the response object from InfoMap? That way we can manage it from JavaScript, giving us some more contextual information, e.g.: have a specific set of origins for a given clientId which are set via JS:
    stsuu.addAttribute(new Attribute("Access-Control-Allow-Origin", "urn:ibm:names:ITFIM:http:response:headers", client.allowedOrigins));
    stsuu.addAttribute(new Attribute("Access-Control-Allow-Methods", "urn:ibm:names:ITFIM:http:response:headers", "POST"));
    Which is capable of enforcing a specific set of origins for a given client, instead of having it to manage on 2 locations (Client definition and Transformation rule) and the requirement to restart a reverse proxy in case you want to add a new origin.

    I can imagine having the capability to write custom response headers have other benefits as well.

    Regards,
    Dries

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------



  • 6.  RE: Question around CORS support

    Posted Wed January 22, 2020 03:17 PM
    Dries,

    Are you suggesting a call-out from WebSEAL to the AAC runtime on every request, or just pre-flight requests, so that you can invoke an InfoMap and use JavaScript?  This sounds like an awfully big performance hit.

    Anyway, the upcoming release of ISAM contains some more native WebSEAL capabilities around CORS and handling pre-flight requests.  I am hoping that this will remove the need for any transformation rules / javascript.

    Thanks.

    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------



  • 7.  RE: Question around CORS support

    Posted Wed January 22, 2020 03:29 PM

    Hello Dries,

    Furthermore, here is an HTTP Transformation that can be used at ISAM 9.0.7.X to do dynamic CORS response headers:

    https://github.com/IBM-Security/isam-support/blob/master/config-example/webseal/http-transformations/response/response-dynamic-cors-isam9070-above.xslt



    ------------------------------
    JACK YARBOROUGH
    ------------------------------



  • 8.  RE: Question around CORS support

    Posted Wed January 22, 2020 03:38 PM
    Hi Jack,

    Thanks for the link, I've found that transformation rule as well, but as you see in my new answer with origin whitelisting, a transformation rule might not be idea, because you'd have to restart the reverse prox(ies) for each new origin, if you want to have origin whitelisting for a specific client that is, otherwise that transformation rule will do nicely.

    Regards,

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------



  • 9.  RE: Question around CORS support

    Posted Wed January 22, 2020 03:34 PM
    Hi Scott,

    The pre-flight requests having "Access-Control-Allow-Origin: *" is no problem (I think this is ideal actually), but when you perform the actual POST to the /token endpoint, the browser expects CORS headers as well; the point I'm getting at are for example public clients, where we can perform some additional origin whitelisting in order to make sure it is not invoked from an unknown domain/origin.
    I can see "allowed-origins" being an extension property of a client for example, containing an array of whitelisted origins, which can be retrieved in PostToken Mapping Rule in order to set additional response headers going back to the client, therefore adding an additional layer of protection, all while not completely exposing this public client to "*".

    The pre-flight is pretty static in response anyway so whether that's Transformation Rules or some inbuilt mechanism in WebSEAL, it doesn't have to change that often.

    Why it would be nice to be able to manipulate response headers in a response from POST /oauth/token endpoint is not having to restart a reverse proxy to add an additional origin.

    Regards,
    Dries

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------



  • 10.  RE: Question around CORS support

    Posted Wed January 22, 2020 04:21 PM
    Dries,

    Unfortunately I still don't quite understand what you are proposing.  To my understanding the enforcement of CORS lies with the client.  The application (and in our case, WebSEAL) is responsible for providing the headers which are used by the client to enforce CORS.

    I can understand the desire to be able to dynamically create the Access-Control-Allow-Origin header in the response, rather than hard-coding this in the WebSEAL configuration.  You specifically mentioned the '/oauth/token' endpoint - which in WebSEAL is an authentication end-point.

    So, are you suggesting to allow the authentication end-point to be able to set HTTP headers for the session (in this case the Access-Control-Allow-Origin header) which will be returned for all requests which use the session?

    Thanks for persisting with this.

    Scott.

    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------



  • 11.  RE: Question around CORS support

    Posted Wed January 22, 2020 04:53 PM
    Edited by Dries Eestermans Wed January 22, 2020 04:54 PM
    Scott,

    Let me use an example;
    I have an angular application (purely browser-based JS application), which performs the authorization code + PKCE. What it would do first, is probably detect whether it has a valid access token in cache, let's assume it doesn't and thus is redirects us to the authorization endpoint (window redirect, so no CORS here).

    When we get back to the angular application, it extracts the authorization code from the query parameter (or fragment).

    This is part is important for the CORS header manipulation:
    1. The Angular (browser JS) attempts to send a POST to the /oauth/token endpoint
    2. The browser, which enforces CORS, now performs a pre-flight request, which is the OPTIONS /oauth/token
    3. At this point, it is perfectly fine that WebSEAL returns the following, also keep in mind that at this point, we have no information who the client could be (apart from an origin):
      • Access-Control-Allow-Origin: *
      • Access-Control-Allow-Methods: POST    <-- I think /oauth/token endpoint only takes POST requests
      • ...
    4. The browser now validates the pre flight response, which sees that any origin can perform a POST to /oauth/token, it now lets the initial POST (step 1) proceed.
    5. At this point, the POST /oauth/token is sent from Browser JS, it sets an "origin" in the request header, and it goes off.
      Now here is where my suggestion comes in.
    6. The POST /oauth/token (which is a regular token request) passes the WebSEAL and gets sent to the federation runtime, it processes it like normal, except for the part where the Federation runtime (beit Pre or Post Token Mapping rules) is capable of origin whitelisting, in InfoMap code we can perform an additional validation:
      • We know the client_id
      • We have a specific set of whitelisted origins for this client (this is not in the default menu, but for example's sake, it's array in the "Extensions Properties" tab.
      • Using OAuthMappingExtUtils we get the client's extensions properties from the PostToken mapping rule and extract the set of whitelisted origins
      • We then retrieve the incoming request header "origin", and validate whether the incoming "origin" is part of the whitelist
        • If it's part of the whitelist, we set an additional response header from code; stsuu.addAttribute("Access-Control-Allow-Origin", "urn:ibm:names:ITFIM:http:response:headers", requestHeader.origin);
        • If it's not part of the whitelist, we don't set the header.
      • PostToken Mapping Rule finishes and the response is sent to the client, the browser again validates it:
        • In case the response header contains the initial origin, the response is forwarded to the browser JS caller
        • In case the response header does not contain the initial origin, the response is blocked by the browser (CORS violation)

    So, are you suggesting to allow the authentication end-point to be able to set HTTP headers for the session (in this case the Access-Control-Allow-Origin header) which will be returned for all requests which use the session?
    --> not necessarily for the session, when performing the POST to the token endpoint with the browser JS, the session cookie is not injected (if at all possible, I think it's HttpOnly). It's basically an anonymous "session", it's just the request to the token endpoint, on which I would like to add an additional layer of protection for public clients in JS scenarios.

    I hope this illustrates my motive as to why I'd like to have this type of functionality in the InfoMap.

    Regards,
    Dries

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------



  • 12.  RE: Question around CORS support

    Posted Thu January 23, 2020 06:47 PM
    Dries,

    It sounds like you want the ability to be able to add a HTTP header in the response to an OAuth endpoint (e.g. /oauth/token).  Is my understanding correct?  If so, this is something which the product is not capable of doing today, and if you would like to see it added to the product it would be worthwhile creating an RFE for this enhancement.

    Thanks,

    Scott.



    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------



  • 13.  RE: Question around CORS support

    Posted Fri January 24, 2020 02:50 AM
    Hi Scott,

    Yes, that's exactly my use-case/request.

    I opened an RFE with ID: 139665.

    Regards,
    Dries

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------



  • 14.  RE: Question around CORS support

    Posted Tue November 03, 2020 05:43 AM
    Hello,

    Do we have any update on this?
    We have similar requirements where client is trying Authorization code flow with PKCS wiht Javascript based client...

    Regards,
    Piyush Agrawal

    ------------------------------
    Piyush Agrawal
    ------------------------------



  • 15.  RE: Question around CORS support

    Posted Tue November 03, 2020 06:00 PM
    Piyush,
     
    The capability to add HTTP Response headers from InfoMap rules will be available in the upcoming 10.0.1 release.  This version is due to be released in December.
     
    Thanks.
     
     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor


    Phone: 61-7-5552-4008
    E-mail: scotte@au1.ibm.com
    1 Corporate Court
    Bundall, QLD 4217
    Australia