Passerelles d’applications (existantes)

ℹ️

Cette rubrique fait référence à la syntaxe de configuration existante. Les passerelles d’applications sont désormais définies comme des applications Proxy.

AppGateways contrôle l’accès des utilisateurs aux applications en fournissant des outils déclaratifs pour les proxy et les connecteurs. AppGateways établit des proxy d’applications et peut déterminer quels systèmes d’accès doivent être utilisés pour authentifier et autoriser les utilisateurs. Ces passerelles peuvent également être utilisés pour étendre ces systèmes d’accès en gérant les sessions ou en mettant en correspondance des attributs ou des réclamations avec des en-têtes spécifiques dont les applications existantes ont besoin pour autoriser l’accès. AppGateways peut également utiliser attrProviders pour obtenir des données supplémentaires qui peuvent être utilisées pour évaluer la politique.

ℹ️

Par mesure de sécurité, l’orchestrateur ne transmet pas les cookies Maverics aux applications en amont.

Name

La valeur name correspond à un identifiant unique pour chaque AppGateway.

Base Path

basePath définit le préfixe du chemin sur lequel AppGateway recevra les requêtes. Par exemple, un basePath /foo signifie que l’AppGateway recevra toutes les requêtes dont le préfixe est /foo, par exemple /foo/index.html.

Host

host est un champ facultatif utilisé permettant d’acheminer les demandes vers la bonne AppGateway lorsque les basePaths d’une ou plusieurs AppGateways entrent en conflit. Par exemple, deux applications peuvent avoir un basePath correspondant à / et ont donc besoin d’une valeur host spécifiée pour permettre un routage correct.

appgateways:
  - name: alpha
    basePath: /
    host: alpha.com

  - name: beta
    basePath: /
    host: beta.com

Upstream

upstream correspond à l’URL de l’application protégée qui fait l’objet d’une transmission par proxy. Il peut s’agir d’une adresse IP ou d’un nom d’hôte, et d’un port sur lequel l’application est connectée.

Preserve Host

preserveHost est un champ booléen facultatif utilisé pour déterminer si l’en-tête Host doit être conservé dans les requêtes sortantes. Par défaut, l’orchestrateur définit l’en-tête pour qu’il corresponde à l’hôte en amont. Ce champ est souvent utilisé lorsque l’orchestrateur transfère le trafic vers un autre proxy inverse tel qu’Apache.

TLS

Le champ tls est utilisé pour spécifier la configuration TLS pour les requêtes sortantes en amont. La valeur doit faire référence à un objet TLS défini dans la configuration TLS de premier niveau. Ce champ est facultatif et est généralement utilisé lorsque la cible en amont utilise des certificats signés par une autorité de certification inconnue.

Rewrites

rewrites sont les réécritures utilisées pour remplacer les URL dans la requête et dans la réponse. Cela peut s’avérer pratique lors de l’accès par proxy à une application qui utilise des URL absolues. Cette fonctionnalité doit être utilisée avec prudence car elle aura un impact sur les performances d’une AppGateway.

appgateways:
  - name: rewritesExample
    basePath: /
    rewrites:
      # The URL on the left side of the colon is replaced with the URL on the right.
      https://app-internal.example.com: https://app.example.com

Attribute Providers

attrProviders représente le système d’accès ou le magasin de données à partir duquel une AppGateway récupère les attributs supplémentaires nécessaires à l’évaluation des politiques et à la construction des en-têtes.

appgateways:
  - name: exampleAttrProvider
    basePath: /
    attrProviders:
      - connector: ldap
        usernameMapping: azure.mail
      - connector: mysql
        usernameMapping: azure.mail

Connector

connector est une référence au connecteur utilisé pour charger les attributs.

Mappage des noms d’utilisateur

Définit l’attribut à utiliser en tant que clé de recherche afin de charger les attributs à partir du fournisseur d’attributs. La valeur provient généralement du fournisseur d’identité utilisé pour l’authentification primaire, par exemple azure.sub.

Headers

Les AppGateways protègent souvent des applications qui nécessitent un fournisseur d’identité externe pour authentifier l’utilisateur et définir des valeurs dans les headers (en-têtes) HTTP avant d’autoriser l’accès. Les en-têtes sont configurés sous forme de paires clé-valeur où la clé correspond au nom de l’en-tête et la valeur correspond à la valeur de l’en-tête. Les valeurs sont déclarées à l’aide d’un espace de noms, par exemple, azure.sub.

appgateways:
  - name: exampleHeaders
    basePath: /
    headers:
      SM_USER: azure.sub
      firstName: ldap.givenName
      lastName: ldap.sn

Extension de services Create Header

Des en-têtes personnalisés peuvent être créés en utilisant l’extension de services createHeader. Pour plus d’informations, veuillez consulter les documents relatifs à l’extension de services Create Header.

Policies

policies correspond aux politiques qui déterminent si une demande donnée doit être autorisée, et qui définissent en bout de ligne les utilisateurs autorisés à accéder à l’application. Si aucune politique n’est définie dans la configuration de l’AppGateway, celle-ci refusera toutes les requêtes.

Les AppGateways utilisent l’authentification et l’autorisation pour évaluer si un utilisateur doit être autorisé à accéder à un emplacement d’application. Ces politiques étendent les politiques d’authentification et d’autorisation natives du ou des systèmes d’accès connectés. L’utilisateur obtient le droit d’accès s’il remplit les conditions établies : avoir été authentifié par le fournisseur d’identité, ou comporter des attributs qui peuvent indiquer l’appartenance à un groupe ou tout autre aspect de l’utilisateur évalué dans le cadre de la politique.

Location

location correspond à l’emplacement de la politique utilisé pour faire correspondre une ressource d’application à une politique. L’AppGateway établit une correspondance entre une requête et l’emplacement le plus spécifique. L’ordre dans la configuration des emplacements de politique n’a pas d’importance.

appgateways:
  - name: examplePolicy
    basePath: /
    policies:
      - location: /index.html
        authentication:
          allowUnauthenticated: true
        authorization:
          allowAll: true

Pour appliquer la correspondance d’expression rationnelle au chemin d’accès à la ressource, ajoutez ~ (notez l’espace) à l’avant de l’emplacement. Vous pouvez utiliser des outils tels que regex101 (sélectionnez Golang) pour tester votre expression rationnelle avec les chemins URL que vous aimeriez faire correspondre. Par exemple, pour faire correspondre une ressource commençant par myresource :

appgateways:
  - name: examplePolicyWithRegex
    basePath: /
    policies:
      - location: ~ ^/myresource.*
        authentication:
          allowUnauthenticated: true
        authorization:
          allowAll: true

Veuillez prendre note du caractère ^ pour vous assurer que l’expression rationnelle ne correspond qu’au début du chemin d’accès à la ressource. L’orchestrateur ajoute automatiquement les caractères d’échappement / dans le chemin d’accès à l’URL, il n’est donc pas nécessaire de les ajouter manuellement (par exemple, .^\/).

Des expressions rationnelles mal construites peuvent affecter les performances de l’orchestrateur. Utilisez des ancres (^ ou $) si possible, et des compteurs ou des plages (.{0,15}) au lieu de métacaractères « gourmands » (.*).

Query Param Matching

useQueryParamsForMatchingPolicy est utilisé pour faire correspondre les requêtes comportant des paramètres à la politique appropriée. La correspondance des paramètres de requête ne fonctionne qu’avec les emplacements qui utilisent des expressions rationnelles (c’est-à-dire précédés de ~).

Pour faire correspondre les URL qui incluent des paramètres de requête tels que l’URL https://mydomain.com/myresource/?param=abcd, vous devez définir une politique similaire à la suivante :

appgateways:
  - name: examplePolicyWithQueryParams
    basePath: /
    policies:
      - location: ~ ^/myresource/\?param=abcd
        useQueryParamsForMatchingPolicy: true
        authentication:
          allowUnauthenticated: true
        authorization:
          allowAll: true

Dans le cas de paramètres d’interrogation multiples avec un ordre cohérent :

appgateways:
  - name: examplePolicyWithQueryParams
    basePath: /
    policies:
      - location: ~ ^/myresource/\?param=abc&code=def
        useQueryParamsForMatchingPolicy: true
        authentication:
          allowUnauthenticated: true
        authorization:
          allowAll: true

Dans le cas où les paramètres de la requête peuvent apparaître dans n’importe quel ordre, avec d’autres paramètres entre eux :

appgateways:
  - name: examplePolicyWithQueryParams
    basePath: /
    policies:
      - location: ~ ^/myresource/\?.{0,15}(param=abc|code=def){1}.{0,15}\&(param=abc|code=def){1}
        useQueryParamsForMatchingPolicy: true
        authentication:
          allowUnauthenticated: true
        authorization:
          allowAll: true

Authentication

authentification déclare la politique d’authentification d’un emplacement. Lorsqu’une requête non authentifiée est reçue pour une ressource, une politique d’authentification par défaut traite la requête non authentifiée et redirige l’utilisateur vers un fournisseur d’identité ou un fournisseur d’autentification multifacteur pour qu’il se connecte si nécessaire.

Exemple d’utilisation d’Azure pour l’authentification :

appgateways:
  - name: exampleAuthnPolicy
    basePath: /
    policies:
      - location: /sonar
        authentication:
          idps:
            - azure
        authorization:
          allowAll: true

Exemple d’utilisation d’Azure pour l’authentification primaire et de PingOne pour l’authentification multifacteur :

include:
  - "/etc/maverics/configs/connectors/azure.yaml"
  - "/etc/maverics/configs/connectors/pingone.yaml"

appgateways:
  - name: exampleAuthnMFAPolicy
    basePath: /
    policies:
      - location: /sonar
        authentication:
          idps:
              - azure
          mfa:
            - pingone:
                mapping:
                  - email: azure.email

IDPs

idps contient une liste d’un ou de plusieurs noms de fournisseurs d’identité à utiliser pour l’authentification.

MFA

mfa contient une liste d’un ou de plusieurs noms de connecteurs MFA (authentification multifacteur). Sous chaque connecteur, une section de mappage est nécessaire pour définir comment une identité MFA est mappée à l’identité de fournisseur d’identité correspondante.

Le champ mapping prend en charge les mots-clés and, or et not pour exprimer des évaluations complexes. Si les noms correspondent à une liste YAML sans mots-clés, ils seront évalués à l’aide d’un and implicite.

Allow Unauthenticated Access

allowUnauthenticated peut être utilisé pour permettre un accès libre à une ressource. Si la valeur est « true », la ressource correspondant à cette politique ne nécessite pas d’authentification. Cet opérateur est généralement utilisé pour des ressources telles que les pages d’erreur ou de connexion.

Authorization

L’opérateur authorization déclare la politique d’autorisation d’un emplacement et permet la formation de politiques arbitrairement complexes. L’opérateur d’autorisation peut être utilisé en conjonction avec les opérateurs all, any, equal et contains. S’il n’est pas spécifié, l’accès à l’emplacement est refusé. La section authorization peut utiliser les évaluateurs décrits ci-dessous
pour établir une politique d’autorisation.

Exemple avec une politique d’autorisation simple :

appgateways:
  - name: exampleAuthzPolicy
    basePath: /

    policies:
      - location: /
        authentication:
          idps:
            - azure
        authorization:
          - or:
            - contains: ["{{azure.groups}}", "admins"]
            - contains: ["{{azure.groups}}", "executives"]

Allow All

L’opérateur allowAll (allowAll: true) autorise tous les utilisateurs d’un emplacement. Ce paramètre doit être défini explicitement pour que chaque emplacement soit accessible à tous les utilisateurs et ne doit pas être utilisé en combinaison avec d’autres règles de politique pour un emplacement.

And

Toutes les conditions et tous les opérateurs définis dans un bloc and doivent être évalués à la valeur true pour que la politique soit évaluée à la valeur true.

Or

Toutes les conditions et tous les opérateurs définis dans un bloc or doivent être évalués à la valeur true pour que la politique soit évaluée à la valeur true.

Not

Toute condition ou opérateur défini dans un bloc not s’évalue à l’inverse. Si la condition de la politique not est true, la politique sera évaluée à false et vice-versa. Pour évaluer une liste de conditions avec not, vous devez imbriquer les conditions dans un bloc or ou and.

Contains
contains requiert deux chaînes de caractères, généralement un attribut de la session et une valeur à laquelle le comparer, et renvoie la valeur true si la deuxième chaîne correspond à une partie de la première (c’est-à-dire une correspondance de sous-chaîne). Les valeurs de la session de l’utilisateur peuvent être incluses dans l’évaluation de la politique en les entourant de doubles accolades. Par exemple, contains: ["{{azure.name}}", "@example.com"].

Equals
S’évalue à true si les deux valeurs sont equal au moment de l’exécution de la politique.

Headers

headers définit l’ensemble des en-têtes pour un emplacement spécifique. Ces en-têtes remplacent les en-têtes du même nom définis au niveau de l’AppGateway. L’extension de services createHeader peut également être utilisée à ce niveau.

Cet exemple de configuration définit des en-têtes au niveau de la politique afin d’inclure des en-têtes pour un emplacement spécifique. Il remplace également les en-têtes au niveau de l’AppGateway.

appgateways:
  - name: Sonar
    basePath: /

    headers:
      SM_USER: azure.username
      firstname: azure.givenName
      lastname: azure.surname

    policies:
      - location: /
        authentication:
          idps:
            - azure
        headers:
          # Override 'firstname' header defined in 'headers'.
          firstname: azure.preferred_username

      - location: /admin
        authentication:
          idps:
            - azure
        headers:
          # Add new header for /admin location.
          IS_ADMIN: azure.isAdmin

Error Page

errorPage correspond à l’URL vers laquelle l’utilisateur est redirigé en cas d’erreur.

Unauthorized Page

unauthorizedPage est l’URL vers laquelle l’utilisateur est redirigé lorsque l’évaluation de la politique conduit à un refus d’accès à l’application.

Extensions de services

Les AppGateways utilisent des extensions de services pour permettre une logique personnalisée qui n’est pas prise en charge de manière native. Les extensions de services peuvent être utilisées pour charger des attributs, étendre les évaluations des politiques d’authentification et d’autorisation et créer des en-têtes.

Authentification

Bien que Maverics fournisse un grand nombre de connecteurs à utiliser pour l’authentification des utilisateurs, certaines organisations souhaitent personnaliser l’expérience d’authentification ou peuvent avoir des besoins qui ne sont pas pris en compte dans les connecteurs existants. L’extension de services Authentication permet aux administrateurs de définir le processus d’authentification précisément de la manière dont ils en ont besoin.

Pour plus de détails, reportez-vous à la section [Extension de services Authentication](service-extension-authentication.

Chargement des attributs

Le chargement des attributs de la session d’un utilisateur est également personnalisable via les extensions de services.

Pour plus de détails, reportez-vous à la section Chargement des attributs via l’extension de services.

Autorisation

Les extensions de services permettent également un contrôle complet de l’accès aux ressources protégées par le biais d’une autorisation.

Pour plus de détails, reportez-vous à la section Autorisation via l’extension de services.

Connexion en amont

Il peut être utile de déterminer si une requête adressée à une application en amont est authentifiée et de pouvoir se connecter à une application en amont.

Pour plus de détails, reportez à la section Connexion à l’application en amont.

Modification des requêtes et des réponses

Certaines situations requièrent la possibilité de modifier chaque requête et réponse qui passe par le proxy de l’AppGateway.

Pour plus de détails, reportez-vous à la section Extension de services Request & Response Modification

Remplacer le flux de requêtes par défaut de l’AppGateway

Obtenez un contrôle plus précis sur la façon dont une requête est traitée dans une AppGateway.

Pour plus de détails, reportez-vous à la section Extension de services Serve

Exemples

Base

Cet exemple de configuration YAML de base déclare :

Une application appelée « Sonar »
Un emplacement protégé sur l’application
Qu’une session doit être présente et validée pour que l’utilisateur puisse accéder à l’application
Un locataire Azure AD connecté en tant que fournisseur d’identité pour l’utilisateur
Les mappages d’attributs des réclamations Azure AD vers les en-têtes HTTP
Une politique qui autorise l’accès à l’application lorsque l’utilisateur est authentifié auprès d’Azure
Une politique qui n’autorise l’accès à un emplacement spécifique que si les données de l’utilisateur répondent à des critères spécifiques

version: 0.1

tls:
  maverics:
    certFile: certs/example-strata.crt
    keyFile: certs/example-strata.key

http:
  address: :443
  tls: maverics

include:
  - "/etc/maverics/configs/connectors/azure.yaml"

appgateways:
  - name: Sonar
    basePath: /
    host: app.sonarsystems.com
    upstream: https://example.com:8443
    errorPage: https://app.sonarsystems.com/sonar/error
    unauthorizedPage: https://app.sonarsystems.com/sonar/accessdenied

    headers:
      SM_USER: azure.username
      firstname: azure.givenName
      lastname: azure.surname

    policies:
      - location: /
        authentication:
          idps:
            - azure
      - location: /sonar/accessdenied
        authentication:
          allowUnauthenticated: true
        authorization:
          allowAll: true
      - location: /sonar/execs
        authentication:
          idps:
            - azure
        authorization:
          - or:
              - contains: ["{{azure.email}}", "@sonarsystems.com"]
              - contains: ["{{azure.email}}", "@example.com"]

Politique d’authentification

Flux d’authentification avec mappage de l’authentification multifacteur à l’aide d’opérateurs logiques

Dans la section authentication , vous trouverez un fournisseur d’identité et une authentification multifacteur prédéfinis. Dans le flux d’authentification par défaut, l’utilisateur s’authentifie auprès du connecteur Azure, puis auprès du fournisseur d’authentification multifacteur spécifié dans la section MFA. Dans cet exemple, la configuration présentée utilise pingone en tant que connecteur pour le fournisseur d’authentification multifacteur. Le mappage est ici exprimé sous la forme de deux conditions différentes dans un cas où certains utilisateurs sont mappés avec l’attribut email et d’autres avec l’attribut userid pour un même connecteur pingone. Si la session de l’utilisateur ne contient pas l’attribut email, le flux d’authentification par défaut tentera d’authentifier l’utilisateur auprès du connecteur pingone à l’aide de l’attribut userid.

...
include:
  - "/etc/maverics/configs/connectors/azure.yaml"
  - "/etc/maverics/configs/connectors/pingone.yaml"

appgateways:
  - name: Sonar
    # ...
    policies:
      - location: /sonar
        authentication:
          idps:
            - azure
          mfa:
            - pingone:
                mapping:
                  - or:
                      - email: azure.email
                      - userid: azure.userid

Dans la configuration ci-dessous, l’opérateur and est utilisé pour indiquer qu’un mappage de deux champs est souhaité.

...
include:
  - "/etc/maverics/configs/connectors/azure.yaml"
  - "/etc/maverics/configs/connectors/pingone.yaml"

appgateways:
  - name: Sonar
    # ...
    policies:
      - location: /sonar
        authentication:
          idps:
            - azure
          mfa:
            - pingone:
                mapping:
                  - and:
                      - email: azure.email
                      - tenantID: azure.group

Cette configuration présente un scénario plus avancé et plus complexe, permettant une expression à l’aide de plusieurs opérateurs.

...
include:
  - "/etc/maverics/configs/connectors/azure.yaml"
  - "/etc/maverics/configs/connectors/pingone.yaml"

appgateways:
  - name: Sonar
    # ...
    policies:
      - location: /sonar
        authentication:
          idps:
            - azure
          mfa:
            - pingone:
                mapping:
                  - or:
                      - and:
                          - email: azure.email
                          - tenantID: azure.group
                      - email: azure.email

Cette configuration démontre un mappage exprimé avec l’opérateur not dans lequel, en présence de l’attribut azure.custom dans la session, le mappage de l’utilisateur vers pingone se fait à l’aide de l’e-mail secondaire.

...
include:
  - "/etc/maverics/configs/connectors/azure.yaml"
  - "/etc/maverics/configs/connectors/pingone.yaml"

appgateways:
  - name: Sonar
    # ...
    policies:
      - location: /sonar
        authentication:
          idps:
            - azure
          mfa:
            - pingone:
                mapping:
                  - or:
                      - and:
                          - email: azure.verified_primary_email
                          - not:
                              custom: azure.custom
                      - email: azure.verified_secondary_email

Politique d’autorisation

L’AppGateway utilise authorization pour protéger les ressources, renvoyant 403 Forbidden lors d’une tentative d’accès à la ressource si la politique n’est pas évaluée à true.

Politique utilisant `authorization` avec des conditions imbriquées

Dans cet exemple de configuration, l’AppGateway utilise authorization pour permettre à certains utilisateurs d’accéder à /sonar/reports. Si le courriel de l’utilisateur contient le domaine strata.io, l’accès est autorisé pour les utilisateurs portant les noms Marie, Ivan et Ludwig. Si l’adresse électronique de l’utilisateur contient le domaine sonarsystems.com, l’accès est autorisé pour les utilisateurs portant les noms Donna, Jacob et Rufus.

...
include:
  - "/etc/maverics/configs/connectors/azure.yaml"

appgateways:
  - name: Sonar
    # ...

    policies:
      - location: /sonar
        authentication:
          idps:
            - azure
        authorization:
          allowAll: true
      - location: /sonar/reports
        authentication:
          idps:
            - azure
        authorization:
          - and:
              - equal: [ "{{azure.custom}}", "expected" ]
              - or:
                  - and:
                      - contains: [ "{{azure.name}}", "@strata.io" ]
                      - or:
                          - equal: [ "{{azure.givenname}}", "Marie" ]
                          - equal: [ "{{azure.givenname}}", "Ivan" ]
                          - equal: [ "{{azure.givenname}}", "Ludwig" ]
                  - and:
                      - contains: [ "{{azure.name}}", "@sonarsystems.com" ]
                      - or:
                          - equal: [ "{{azure.givenname}}", "Donna" ]
                          - equal: [ "{{azure.givenname}}", "Jacob" ]
                          - equal: [ "{{azure.givenname}}", "Rufus" ]

Politique utilisant des attributs LDAP

Cet exemple de configuration utilise une instance de connecteur LDAP pour obtenir des informations supplémentaires sur les utilisateurs. Lorsque les attributs supplémentaires sont chargés, Maverics effectue un contrôle d’autorisation par rapport aux attributs chargés avant d’autoriser l’accès à l’utilisateur.

include:
  - "/etc/maverics/configs/connectors/azure.yaml"

connectors:
  - name: ldap
    type: ldap
    url: "ldap://ldap.example.com:389"
    serviceAccountPassword: <PASSWORD>
    serviceAccountUsername: cn=admin,dc=example,dc=com
    baseDN: ou=People,dc=example,dc=com
    usernameSearchKey: mail

appgateways:
  - name: Sonar
    # ...
    attrProviders:
      - connector: ldap
        usernameMapping: azure.emailaddress

    policies:
      - location: /sonar
        loadAttrsSE:
          funcName: LoadAttrs
          file: /etc/maverics/extensions/loadAttrs.go

        authentication:
          idps:
            - azure
        authorization:
          - equal: [ "{{ldap.department}}", "Accounting" ]

Passerelles d’applications (existantes)

Name

Base Path

Host

Upstream

Preserve Host

TLS

Rewrites

Attribute Providers

Connector

Mappage des noms d’utilisateur

Headers

Extension de services Create Header

Policies

Location

Query Param Matching

Authentication

IDPs

MFA

Allow Unauthenticated Access

Authorization

Allow All

And

Or

Not

Contains

Equals

Headers

Error Page

Unauthorized Page

Extensions de services

Authentification

Chargement des attributs

Autorisation

Connexion en amont

Modification des requêtes et des réponses

Remplacer le flux de requêtes par défaut de l’AppGateway

Exemples

Base

Politique d’authentification

Flux d’authentification avec mappage de l’authentification multifacteur à l’aide d’opérateurs logiques

Politique d’autorisation

Politique utilisant authorization avec des conditions imbriquées

Politique utilisant des attributs LDAP

Politique utilisant `authorization` avec des conditions imbriquées