À propos de la configuration SAML
Pour utiliser l'authentification unique SAML (SSO) pour l'authentification à GitHub, vous devez configurer à la fois votre fournisseur d'identité SAML externe (IdP) et votre instance GitHub Enterprise Server. Dans une configuration SAML, GitHub fonctionne comme un fournisseur de services SAML (SP). Pour plus d'informations sur l'authentification pour votre entreprise, consultez « À propos de la gestion de l'identité et de l'accès ».
GitHub fournit une intégration conforme à la spécification SAML 2.0. Pour plus d'informations, consultez le Wiki SAML sur le site web OASIS.
Vous devez saisir des valeurs uniques de votre IdP SAML lorsque vous configurez SAML SSO pour GitHub, et vous devez également saisir des valeurs uniques de GitHub sur votre IdP.
Métadonnées SAML
Les métadonnées du fournisseur de services pour votre instance GitHub Enterprise Server sont disponibles sur http(s)://HOSTNAME/saml/metadata
, où HOSTNAME est le nom d'hôte de votre instance. GitHub Enterprise Server utilise la urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
contrainte.
Valeur | Autres noms | Description | Exemple |
---|---|---|---|
ID d'entité de fournisseur de services | URL du fournisseur de services, restriction d'audience | L'URL de premier niveau pour votre instance GitHub Enterprise Server | http(s)://HOSTNAME |
URL Assertion Consumer Service (ACS) du fournisseur de service | URL de réponse, de destinataire ou de destination | URL où l'IdP envoie des réponses SAML | http(s)://HOSTNAME/saml/consume |
URL d'authentification unique du fournisseur de services | |||
URL à laquelle le fournisseur d'identité commence l'authentification unique | http(s)://HOSTNAME/sso |
Attributs SAML
Les attributs SAML suivants sont disponibles pour GitHub. Vous pouvez modifier les noms des attributs dans la Management Console, à l'exception de Management Console. administrator
l’attribut. Pour plus d’informations, consultez « Géstion de votre instance à partir de l’IU WEB. ».
Nom | Obligatoire | Description |
---|---|---|
NameID | Identificateur d'utilisateur persistant. Il est possible d'utiliser n'importe quel format d'identificateur de nom persistant. GitHub normalisera le’élément. NameID à utiliser comme nom d'utilisateur, sauf si l'une des assertions alternatives est fournie. Pour plus d’informations, consultez « Considérations relatives au nom d'utilisateur pour une authentification externe ».> [!NOTE] Il est important d’utiliser un identificateur explicite et persistant. L’utilisation d’un format d’identificateur temporaire comme urn:oasis:names:tc:SAML:2.0:nameid-format:transient entraîne une nouvelle liaison des comptes à chaque connexion, ce qui peut nuire à la gestion des autorisations. | |
SessionNotOnOrAfter | La date à laquelle GitHub invalide la session associée. Après l'invalidation, la personne doit s'authentifier une fois de plus pour accéder à votre instance GitHub Enterprise Server. Pour plus d’informations, consultez « Durée et délai d’expiration de session ». | |
administrator | Lorsque la valeur est true , GitHub promouvra automatiquement l'utilisateur en tant qu'administrateur du site . La définition de cet attribut sur autre chose que true entraîne une rétrogradation, dans la mesure où la valeur n'est pas vide. Si cet attribut est omis ou que sa valeur reste vide, le rôle de l'utilisateur est inchangé. | |
username | Nom d’utilisateur pour votre instance GitHub Enterprise Server. | |
full_name | Le nom complet de l’utilisateur à afficher sur la page de profil de l’utilisateur. | |
emails | Adresses e-mail de l’utilisateur. Vous pouvez spécifier plusieurs adresses. Si vous synchronisez l’utilisation des licences entre GitHub Enterprise Server et GitHub Enterprise Cloud, GitHub Connect utilise emails pour identifier des utilisateurs uniques entre les produits. Pour plus d’informations, consultez « Synchronisation de l’utilisation des licences entre GitHub Enterprise Server et GitHub Enterprise Cloud ». | |
public_keys | Les clés SSH publiques pour l’utilisateur. Vous pouvez spécifier plus d'une clé. | |
gpg_keys | Les clés GPG pour l’utilisateur. Vous pouvez spécifier plus d'une clé. |
Pour spécifier plusieurs valeurs pour un même attribut, utilisez plusieurs éléments <saml2:AttributeValue>
.
<saml2:Attribute FriendlyName="public_keys" Name="urn:oid:1.2.840.113549.1.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue>ssh-rsa LONG KEY</saml2:AttributeValue>
<saml2:AttributeValue>ssh-rsa LONG KEY 2</saml2:AttributeValue>
</saml2:Attribute>
Exigences en matière de réponse SAML
GitHub exige que le message de réponse de votre IdP remplisse les conditions suivantes.
-
Votre IdP doit fournir l'élément
<Destination>
dans le document de réponse racine et correspondre à l'URL ACS uniquement lorsque le document de réponse racine est signé. Si votre IdP signe l'assertion, GitHub ignorera l'assertion. -
Votre fournisseur d'identité doit toujours fournir l'élément
<Audience>
dans le cadre de l'élément<AudienceRestriction>
. La valeur doit correspondre à votreEntityId
for GitHub. Cette valeur est l'URL où vous accédez à GitHub, par exemplehttp(s)://HOSTNAME
. -
Votre fournisseur d'identité doit fournir une seule assertion dans la réponse avec une signature numérique. Pour ce faire, vous pouvez signer chaque élément
<Assertion>
individuel ou l’élément<Response>
. -
Votre fournisseur d'identité doit fournir un élément
<NameID>
dans le cadre de l'élément<Subject>
. Vous pouvez utiliser n'importe quel format d'identificateur de nom persistant. -
Votre fournisseur d'identité doit inclure l'attribut
Recipient
, qui doit être défini sur l'URL ACS. L'exemple suivant illustre l'attribut.<samlp:Response ...> <saml:Assertion ...> <saml:Subject> <saml:NameID ...>...</saml:NameID> <saml:SubjectConfirmation ...> <saml:SubjectConfirmationData Recipient="https://HOSTNAME/saml/consume" .../> </saml:SubjectConfirmation> </saml:Subject> <saml:AttributeStatement> <saml:Attribute FriendlyName="USERNAME-ATTRIBUTE" ...> <saml:AttributeValue>monalisa</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response>
Certificat de signature SAML pour AuthnRequests
Lorsque vous configurez GitHub Enterprise Server et démarrez l'instance, un certificat de signature SAML auto-signé est généré, séparément du certificat SAML de l'IdP. Ce certificat est utilisé pour signer le AuthnRequests
SAML envoyé au fournisseur d’identité et est valide pendant dix ans. Il est stocké à /data/user/common/saml-sp.p12
et vous pouvez consulter les détails au format encodé en base64 à l'adresse suivante http(s)://HOSTNAME/saml/metadata
.
Si votre fournisseur d'identité valide le certificat de signature SAML, ou si les assertions chiffrées SAML sont activées, les utilisateurs peuvent rencontrer des problèmes d'authentification lorsque le certificat expire. Pour vérifier la date d'expiration, un administrateur GitHub Enterprise Server peut se connecter au serveur via SSH et exécuter la commande ci-dessous. Voir Connexion au shell administratif via SSH.
sudo openssl pkcs12 -in /data/user/common/saml-sp.p12 -clcerts -nokeys -password pass: | sudo openssl x509 -noout -enddate
Pour générer à nouveau ce certificat de signature SAML SP s'il a expiré et s'il est requis par le fournisseur d'identité ou les assertions cryptées, un administrateur GitHub Enterprise Server peut exécuter les commandes ci-dessous dans une GitHub Enterprise Server session SSH.
Note
Les commandes nomad
seront brièvement perturbantes pour les utilisateurs au fur et à mesure que le service github-unicorn
redémarre.
# Backup the old certificate
sudo cp /data/user/common/saml-sp.p12 /data/user/common/saml-sp.p12-$(date +%d%m%Y_%H%M%S)
saml_tempdir=$(sudo mktemp -d)
sudo openssl req -new -newkey rsa:4096 -days 3650 -nodes -x509 -sha256 -subj "/CN=github_enterprise" -keyout $saml_tempdir/saml.key -out $saml_tempdir/saml.crt
sudo openssl pkcs12 -export -inkey $saml_tempdir/saml.key -in $saml_tempdir/saml.crt -nodes -password pass: -out /data/user/common/saml-sp.p12
sudo rm -rf $saml_tempdir
sudo nomad stop github-unicorn
sudo nomad run -hcl1 /etc/nomad-jobs/github/unicorn.hcl
Durée et délai d'expiration de session
Pour empêcher une personne de s'authentifier auprès de votre IdP et de rester autorisée indéfiniment, GitHub invalide périodiquement la session pour chaque compte d'utilisateur ayant accès aux ressources de votre instance GitHub Enterprise Server. Après l'invalidation, la personne doit s'authentifier à nouveau auprès de votre fournisseur d'identité.
Par défaut, si votre IdP n'affirme pas de valeur pour le paramètre SessionNotOnOrAfter
, GitHub invalide une session une semaine après une authentification réussie avec votre IdP.
GitHub supportera une durée de session personnalisée si votre IdP offre l'option de configurer un SessionNotOnOrAfter
attribut et la valeur, et si cet attribut est inclus dans les réponses SAML. Si votre fournisseur d'identité n'autorise pas d'attribut SessionNotOnOrAfter
, un administrateur de site peut configurer un délai d'expiration de session SAML personnalisé pour tous les utilisateurs de votre instance à l'aide de la commande ghe-config saml.default-session-expiration [seconds]
dans le Shell d'administration .
Si vous définissez une durée de session personnalisée inférieure à 24 heures, GitHub peut demander aux utilisateurs de s'authentifier chaque fois que GitHub lance une redirection.
Quelle que soit la méthode d’authentification utilisée sur votre instance, GitHub Enterprise Server termine une session utilisateur après deux semaines continues d’inactivité.
Note
Pour Microsoft Entra ID (anciennement Azure AD), la politique de durée de vie configurable pour les jetons SAML ne contrôle pas le délai de session pour GitHub.