doc-locale/fr-fr/administration/settings/external_authorization.md
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Dans les environnements hautement contrôlés, il peut être nécessaire que la politique d'accès soit contrôlée par un service externe qui autorise l'accès en fonction de la classification du projet et de l'accès utilisateur. GitLab fournit un moyen de vérifier l'autorisation de projet avec votre propre service défini.
Une fois le service externe configuré et activé, lorsqu'un projet est consulté, une requête est envoyée au service externe avec les informations de l'utilisateur et le label de classification du projet attribué au projet. Lorsque le service répond avec une réponse connue, le résultat est mis en cache pendant six heures.
Si l'autorisation externe est activée, GitLab bloque en outre les pages et les fonctionnalités qui affichent des données inter-projets. Cela inclut :
Cela permet d'éviter d'envoyer trop de requêtes simultanées au service d'autorisation externe.
Chaque fois que l'accès est accordé ou refusé, cela est consigné dans un fichier journal appelé external-policy-access-control.log. Apprenez-en davantage sur les journaux que GitLab conserve dans la documentation du paquet Linux.
Lorsque vous utilisez l'authentification TLS avec un certificat auto-signé, le certificat CA doit être approuvé par l'installation OpenSSL. Si vous utilisez GitLab installé avec le paquet Linux, apprenez à installer un CA personnalisé dans la documentation du paquet Linux. Vous pouvez également savoir où installer des certificats personnalisés en utilisant openssl version -d.
Le service d'autorisation externe peut être activé par un administrateur :
{{< history >}}
{{< /history >}}
Vous pouvez configurer votre instance pour autoriser l'autorisation externe pour les opérations Git avec les jetons de déploiement ou les clés de déploiement.
Prérequis :
Pour autoriser l'autorisation avec les jetons et clés de déploiement :
[!warning] Si vous activez l'autorisation externe, les jetons de déploiement ne peuvent pas accéder aux registres de conteneurs ou de paquets. Si vous utilisez des jetons de déploiement pour accéder à ces registres, cette mesure interrompt cette utilisation de ces jetons. Désactivez l'autorisation externe pour utiliser les jetons avec les registres de conteneurs ou de paquets.
Lorsque GitLab demande un accès, il envoie une requête POST JSON au service externe avec ce corps :
{
"user_identifier": "[email protected]",
"project_classification_label": "project-label",
"user_ldap_dn": "CN=Jane Doe,CN=admin,DC=acme",
"identities": [
{ "provider": "ldap", "extern_uid": "CN=Jane Doe,CN=admin,DC=acme" },
{ "provider": "bitbucket", "extern_uid": "2435223452345" }
]
}
Le user_ldap_dn est facultatif et n'est envoyé que lorsque l'utilisateur est connecté via LDAP.
identities contient les détails de toutes les identités associées à l'utilisateur. Il s'agit d'un tableau vide s'il n'y a aucune identité associée à l'utilisateur.
Lorsque le service d'autorisation externe répond avec un code de statut 200, l'accès est accordé à l'utilisateur. Lorsque le service externe répond avec un code de statut 401 ou 403, l'accès est refusé à l'utilisateur. Dans tous les cas, la requête est mise en cache pendant six heures.
Lors du refus d'accès, un reason peut être optionnellement spécifié dans le corps JSON :
{
"reason": "You are not allowed access to this project."
}
Tout code de statut autre que 200, 401 ou 403 refuse également l'accès à l'utilisateur, mais la réponse n'est pas mise en cache.
Si le service expire (après 500 ms), le message « External Policy Server did not respond » s'affiche.
Vous pouvez utiliser votre propre label de classification dans la page Paramètres > Général > General project settings dans le champ « Classification label ». Lorsqu'aucun label de classification n'est spécifié pour un projet, le label par défaut défini dans les paramètres globaux est utilisé.
Sur toutes les pages du projet, dans le coin supérieur droit, le label apparaît.