Handling Cross-Origin Resource Sharing (CORS)¶

Introduction¶

Cross-Origin Resource Sharing (CORS) is a standard security mechanism which is HTTP header based that prohibits a server loading resources from any origins (domain /scheme / port) other than its own, unless explicitly indicated.

When deploying a web-based client (as an integration) in a different domain other than IFS middle-tier, while trying to access IFS APIs, the CORS issue emerges. The reason behind this is that IFS middle-tier does not allow such outside requests adhering to CORS principles.

Note that you can use various industry standard API managers to handle CORS according to your preference.

The steps given below describe in detail how to configure Azure API Manager to solve Cross-Origin Resource Sharing (CORS) for localhost:4200.

Steps¶

1. Create a resource group in your Azure subscription¶

2. Create an API management service in the above resource group¶

3. Choose a method to add an API to the API manager¶

Using an HTTP method, manually define an HTTP API.

Let's use dlk1k8s302-ext-rnd-dev.corporate.ifs.com as the web server external URL in this example.

It is possible to create as many APIs as you like in one single API manager.

4. Add required API endpoints (Add Operations)¶

All operations from the given HTTP method can be allowed using the asterisk \*.
Add operations one by one using endpoints.

Also if required, you can add CORS for each and every operation separately.

Select operation -> inbound processing -> add headers to policy as before

5. Configure authentication calls from application to API manager¶

Load discovery documentation from the Azure API Manager.
Add the following replacement in the outbound process.

Replace the issuer and token endpoint, then revoke endpoint.
Replace host address.

Note that the default host for external environments is set to internal host.

When authenticating using well known configuration, all the other link domains need to be same as host domain. Find and replace https://dlk1k8s302.corpnet.ifsworld.com to https://dlk1k8s302-ext-rnd-dev.corporate.ifs.com OR use skipIssuerCheck : true from the application.
Replace Token and Revoke end points

When authenticating using well known configuration, it refers to the links in the doc and authenticates, where https://dlk1k8s302-ext-rnd-dev.corporate.ifs.com/auth/realms/extensibility/protocol/openid-connect/token is the token link.

This gives a CORS error. To resolve this, the domains of this token and revoke endpoints need to be replaced as follows.
- Find and replace https://dlk1k8s302-ext-rnd-dev.corporate.ifs.com/auth/realms/extensibility/protocol/openid-connect/token to https://testingcorsissue.azure-api.net/apimanager/auth/realms/extensibility/protocol/openid-connect/token
- Find and replace https://dlk1k8s302-ext-rnd-dev.corporate.ifs.com/auth/realms/extensibility/protocol/openid-connect/revoke to https://testingcorsissue.azure-api.net/apimanager/auth/realms/extensibility/protocol/openid-connect/revoke
Below is the outcome.

Note: - If there are any other URLs consumed using well known configuration, replace the origin of those URLs too. - Some clients using third-party libraries for configurations. In such cases, these auth libraries validate issuer, host addresses etc. In our case, the Angular Oauth2-oidc library checks the issuer and validates the whole document. In order to bypass that: - Add skip issuer check header in the client side to skip validating issuer in well-known configuration (skipIssuerCheck : true;) - Add header to stop strict discovery documentation validation to skip validating all of the endpoints provided via the ID Provider discovery document sharing the same base URL as the issuer parameter. (strictDiscoveryDocumentValidation: false;) This is fully dependent on the libraries that are used to implement the integration client.

6. Allow CORS globally (i.e. for all the APIs at once)¶

Select all APIs -> Inbound processing -> policies -> select CORS

Added the following headers

<inbound>

   <cors allow-credentials="false">

      <allowed-origins>

         <origin>http://localhost:4200/</origin>

      </allowed-origins>

      <allowed-methods>

         <method>*</method>

      </allowed-methods>

      <allowed-headers>

         <header>authorization</header>

         <header>content-type</header>

      </allowed-headers>

   </cors>

   <base />

</inbound>

Other features available¶

Any headers can be allowed from here. For instance, to send the delete request, the if-match header must be allowed.

7. Allow CORS separately for APIs¶

Select API -> select All operations -> Inbound Processing -> Policies and add headers to policy as mentioned before

8. Call IFS backend through API manager¶

Instead of calling IFS backend directly, we need to call it through the API manager. All related information is in the API manager settings.

When sending request from the client, replace web service URL from the base URL. For example, consider a URL: https://dlk1k8s302-ext-rnd-dev.corporate.ifs.com/main/ifsapplications/projection/v1/UserGroupHandling.svc/UserGroups. This should be set in the format, https://testingcorsissue.azure-api.net/apimanager/main/ifsapplications/projection/v1/UserGroupHandling.svc/UserGroups.