Cross-Origin Resource Sharing (CORS)

Overview

CORS is a mechanism that supports cross-origin requests between a browser and a web application server. A cross-origin request, in other words, a CORS request is an HTTP request that includes an Origin header. The Origin header is introduced by browsers and labels the origin (scheme, domain or port) in case the request is sent (via JavaScript or Ajax technology) to a different location (scheme, domain or port) than the location from which the page was served from.

For more information about CORS mechanism in general and division of CORS requests, see the CORS standard.

CORS in DirX Access

Each DirX Access Server endpoint processes and filters CORS requests according CORS parameters.

CORS parameters can be either auto-generated or explicitly set in DirX Access application repository based on the existing endpoint configuration.

Auto-generated (Implicit) CORS Parameters

These implicit CORS parameters are generated for each endpoint based on its partnership configuration. The following DirX Access endpoints are covered:

  • OAuth Server/Provider

    • OAuth Client metadata references

  • OAuth Client

    • OAuth Client-Server metadata mapping

  • SAML IdP

    • SAML Peer (SP) metadata references

  • SAML SP

    • SAML Peer (IdP) metadata references

  • WsFederation

    • WsFederation (PRP) Peer metadata references

If there is a change in the configuration, the CORS parameters are regenerated.

Explicit CORS Parameters

In some cases, CORS parameters cannot be auto-generated just from the existing endpoint’s configuration. Therefore, each endpoint includes the option to explicitly add CORS parameters to the already existing generated parameters.

The explicit CORS Parameters configuration covers:

  • Allowed origins

    • For the Access-Control-Allow-Origin HTTP servlet response header

  • Allowed methods

    • For the Access-Control-Allow-Methods HTTP servlet response header

  • Allowed headers

    • For the Access-Control-Allow-Headers HTTP servlet response header

For more information on how to add these CORS parameters, search “CORS parameters” in the Administrative Tasks.

Examples

SAML Single Sign-on at IdP with POST request binding to SP Assertion Consumer Service

There might be misunderstanding that CORS is only relevant for interactive single-page applications where JavaScript or Ajax technologies are heavily used. CORS also needs to be addressed in cases where the form is automatically submitted (via JavaScript) if SAML functionality requires a POST request binding.

attachments/cors++_++example++_++saml++_++sso++_++idp++_++post++_++binding.drawio
Figure 1. SAML Single Sign-on at IdP with POST request binding to SP Assertion Consumer Service

The above situation is covered by the auto-generated CORS parameters, but a similar situation can occur in any case where POST redirection needs to be performed.

Auto-submitted POST request coming from a Protected App

There is a POST redirection with parameters coming from a Protected App to the DirX Access Server. The situation is very similar to the one already described in the previous example, but the situation is worse. We have no configuration to auto-generate CORS parameters.

The DirX Access CORS framework presents a 403 Forbidden HTTP servlet response with a body describing that the request was blocked by the CORS.