Le partage des ressources entre origines (CORS) est un mécanisme d'en-tête HTTP qui permet à un serveur de spécifier les origines externes autorisées à accéder à ses ressources. CORS utilise une requête préalable dans laquelle le navigateur demande au serveur s'il autorisera la requête proprement dite, y compris la méthode HTTP et les en-têtes à utiliser.
Les navigateurs envoient une requête OPTIONS avant d'initier une requête CORS, qui ne peut pas inclure de cookies d'authentification. La fonction d'accès par navigateur est conçue pour imposer l'authentification pour toutes les demandes entrantes. Par conséquent, toute demande non authentifiée est automatiquement redirigée vers un fournisseur d'identité (IdP) pour authentification.
Cette mesure de sécurité peut avoir un impact sur les applications privées qui s'appuient sur des demandes d'options de partage de ressources entre origines (CORS). Lorsque ces demandes sont acheminées via la solution d'accès par navigateur, elles ne peuvent pas contenir de cookies d'authentification en raison de la nature du protocole CORS. Par conséquent, ces demandes sont traitées comme non authentifiées et sont redirigées vers l'IdP pour authentification.
Si CORS est un cas d'utilisation, Netskope recommande d'activer la fonctionnalité CORS OPTIONS Request Support (un drapeau au niveau du locataire), qui permettra d'autoriser les requêtes OPTIONS non authentifiées.
Enablement
Pour utiliser cette fonctionnalité, activez la case à cocher Autoriser CORS non authentifié afin d'autoriser les demandes OPTIONS de partage de ressources inter-origines (CORS) dans la définition de l'application d'accès basée sur le navigateur. Cette fonctionnalité est prise en charge à la fois pour les applications Any Browser et les applications Enterprise Browser.
Comment cela fonctionne-t-il ?
Voici un exemple de demande de contrôle préalable CORS :
OPTIONS /doc HTTP/1.1 Host: bar.company.com Origin: https://foo.company.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type <..> HTTP/1.1 204 No Content Access-Control-Allow-Origin: https://foo.company.com Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type <..>
Dans l'exemple ci-dessus, le domaine primaire (origine) est foo.company.com, et le domaine secondaire est bar.company.com. Ce cas d'utilisation implique que foo.company.com demande une ressource à bar.company.com. Au cours de ce processus, il y a une demande OPTIONS avant le vol, suivie d'une demande GET pour la ressource voulue à partir de bar.company.com.
La séquence des opérations est la suivante :
- Demande #0 : GET foo.company.com (pas de cookie d'authentification)
Cette demande est dirigée vers l'IdP et, après l'authentification, Browser Access installe un cookie pour le domaine company.com. - Request #1: GET foo.company.com (with authentication cookie set for the domain company.com)
This request returns a javascript with the fetch API to fetch a resource from bar.company.com. - Demande #2 : OPTIONS bar.company.com. (Pas de cookie d’authentification.)
Origine : foo.company.com.
Avec la fonction Autoriser le CORS non authentifié activée sur le domaine secondaire (comme bar.company.com) définition de l’application, la requête OPTIONS est transférée à la destination même sans cookie d’authentification.
- Request #3 : GET bar.company.com (with authentication cookie set for the domain company.com).
Conditions préalables
- Les requêtes foo.company.com (primaire) et bar.company.com (secondaire) doivent toutes deux provenir de la même IP de sortie (publique).
- Si les domaines primaire (origine) et secondaire (ressource CORS) sont identiques (par exemple, foo.company.com et bar.company.com), Il est attendu que la requête de récupération contienne les informations d'identification : option « include » . Un exemple de requête JavaScript avec cet en-tête est présenté ci-dessous :
fetch('https://app-api.subdomain.domain.com/api/data', { method: 'GET' credentials: 'include', // Include cookies headers: { 'Content-Type': 'application/json', // Other headers if needed }, }) - Dans la réponse HTTP à la ressource CORS, cet en-tête HTTP doit être inclus : Access-Control-Allow-Credentials : true (Contrôle d'accès - Autoriser les informations d'identification)
Cet en-tête permet au navigateur d'ajouter le cookie d'authentification de la demande GET à la demande de ressource CORS (une fois que la demande de contrôle préalable OPTIONS a abouti).
Important à noter
- Il est prévu que foo.company.com (primaire) et bar.company.com (secondaire) soient définis comme des applications d'accès par navigateur et autorisés par une politique. Seul le domaine secondaire(bar.company.com), le domaine de ressources CORS, il faudrait que la fonction Allow Unauthenticated CORS soit activée.
- Il est attendu que le domaine foo.company.com (origine) soit authentifié et dispose d'un cookie d'authentification valide via l'accès par navigateur pour la ressource CORS(bar.company.com). OPTIONS à autoriser sans authentification.