Types de politiques

Access Gateway prend en charge les types de politiques suivants :

Politique protégée : cette politique requiert une session valide (utilisateur authentifié) pour accéder à la ressource associée.
Politique non protégée : cette politique permet à tout le monde d'accéder à la ressource associée.
Politique de règle protégée : cette politique requiert une session valide et une expression qui détermine qui peut accéder à la ressource.
Politique adaptative : cette politique étend la politique non protégée, mais transmet les informations d'en-tête à l'app sous-jacente.
Politique personnalisée : cette politique étend la politique Règle protégée, mais vous permet de saisir une expression régulière en tant qu'URI.

Politique protégée

Une politique protégée applique l'existence d'une session d'application Access Gateway valide avant d'autoriser l'accès des utilisateurs. Sauf indication contraire par une politique plus exclusive, toutes les ressources de l'app sont soumises à cette politique.

Politique non protégée

Une politique non protégée n'applique pas l'existence d'une session d'application Access Gateway valide. Ce type de politique est généralement réservé aux pages anonymes qui ne nécessitent pas l'identification de l'utilisateur ou qui sont approuvées pour la consommation publique.

Remarque :

Aucun attribut d'en-tête n'est envoyé à l'application en back-end lorsqu'une politique non protégée est appliquée.

Politique de règle protégée

Une politique de règle protégée étend le comportement d'une politique protégée et vous permet de définir de manière précise les règles d'accès (autoriser ou refuser) pour des ressources spécifiques. Ce type de politique évalue les attributs que vous définissez dans le menu Attributs de l'application. Généralement, ces attributs sont sourcés depuis votre org Okta. Il est donc important de comprendre quelles données du profil utilisateur vous devez utiliser.

Les règles sont des expressions régulières basées sur le guide d'expression régulière compatible avec Perl (PCRE). Consultez Expressions des règles de correspondance des ressources pour les règles protégées. Cette section fournit des informations sur les expressions de correspondance des règles dans lesquelles les définitions sont protégées. Consultez Exemple de politique Access Gateway pour obtenir des exemples de règles et d'expressions associées.

Remarque :

Les règles protégées utilisent des expressions régulières qui s'appuient sur les attributs de l'application. L'exemple suivant présente une règle qui utilise l'attribut Groupes. Lorsque vous définissez des expressions de correspondance pour les ressources de règles protégées, assurez-vous que tous les attributs requis ont été définis au préalable. Consultez Gérer les attributs d'application pour en savoir plus sur la manière d'ajouter des attributs d'application.

Politique adaptative

Une politique adaptative étend le comportement de la politique non protégée, mais fournit tous les en-têtes à l'application sous-jacente.

Politique personnalisée

Une politique personnalisée vous permet de saisir une expression régulière pour l'URI du chemin d'accès aux ressources.

La politique personnalisée n'utilise aucune instruction du modèle, sauf pour les étiquettes de politique. Assurez-vous que les instructions requises sont définies de manière à éviter les échecs.

Lorsque vous travaillez avec une politique personnalisée, vous pouvez trouver les en-têtes d'application dans le menu Avancé > Configuration personnalisée.

Remarque :

Les politiques personnalisées sont évaluées en premier, avant tous les autres types de politiques. Consultez Priorité des politiques des applications pour obtenir plus d'informations sur la priorité des types de politiques et l'impact de la sensibilité à la casse sur la correspondance des politiques.

Utiliser une expression régulière dans le chemin d'accès aux ressources

Vous pouvez utiliser les modificateurs répertoriés dans Module ngx_http_core_module.

Utilisez l'ID en amont dans une politique personnalisée

Connectez-vous à votre Console Access Gateway Admin UI.
Sélectionnez Applications dans le menu déroulant Applications.
Sélectionnez l'app Access Gateway à laquelle vous ajoutez la politique personnalisée.
Sélectionnez l'onglet Général.
Faites défiler jusqu'à la section Paramètres SAML.
Recherchez l'ID de l'émetteur SAML et copiez la chaîne représentée par l'espace réservé <upstream_id> dans cet exemple :
https://<IDP_domain>/<upstream_id>

Dans cet exemple de code, remplacez l'espace réservé <upstream> par la valeur du champ ID de l'émetteur SAML. Remplacez l'espace réservé <protected resource> par le nom d'hôte de la ressource Web protégée :

set $policy_type "<PROTECTED/ADAPTIVE/NO_AUTH/PROTECTED_REGEX>";
# process request policies
access_by_lua_file conf/authSession.lua;
# the app you're protecting
proxy_pass http(s)://<upstream>$request_uri;
# common managed directives
include /etc/nginx/conf/icsgw_location_common.conf;
# This sends the host header to the protected resource
proxy_set_header host <protected resource>;

Si vous souhaitez utiliser une politique Règle protégée, créez-la pour pouvoir recueillir le code généré :
1. Créez une politique Règle protégée et générez sa règle Ressource correspondante.
2. Copiez la syntaxe de la règle. Vous l'utiliserez lors d'une étape ultérieure.
3. Définissez le type de politique sur Personnalisé.
4. Dans la Configuration personnalisée, saisissez l'exemple de code affiché précédemment, avec le type de politique défini sur PROTECTED_REGEX.
5. Après la ligne :
```
set $policy_type "PROTECTED_REGEX";
```
  ajoutez la ligne suivante, où <rule_syntax> est la syntaxe de la règle que vous avez copiée lors d'une étape précédente :
```
set $policy_rule "<rule_syntax>";
```