Informationen zur SAML-Konfiguration
Wenn Sie das einmalige Anmelden (Single Sign-On, SSO) mit SAML zur Authentifizierung bei verwenden möchten, müssen Sie sowohl Ihren externen SAML-Identitätsanbieter (Identity Provider, IdP) und Ihre GitHub Enterprise Server-Instance konfigurieren. In einer SAML-Konfiguration dient als SAML-Dienstanbieter (Service Provider, SP). Weitere Informationen zur Authentifizierung für dein Unternehmen findest du unter Informationen zur Identitäts- und Zugriffsverwaltung.
stellt die Integration gemäß der SAML 2.0-Spezifikation bereit. Weitere Informationen finden Sie im SAML-Wiki auf der OASIS-Website.
Sie müssen eindeutige Werte für Ihren SAML-IdP eingeben, wenn Sie SAML-SSO für konfigurieren, und Sie müssen auch eindeutige Werte aus bei Ihrem IdP eingeben.
SAML-Metadaten
Die Metadaten des Dienstanbieters für Ihre GitHub Enterprise Server-Instance sind unter http(s)://HOSTNAME/saml/metadata
verfügbar, wobei HOSTNAME der Name deiner Instanz ist. verwendet die Bindung urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
.
Wert | Andere Namen | BESCHREIBUNG | Beispiel |
---|---|---|---|
Entitäts-ID des SP | Dienstanbieter-URL, Einschränkung der Zielgruppe | Deine URL der obersten Ebene für | http(s)://HOSTNAME |
Assertionsverbraucherdienst-URL (ACS) des SP | Antwort-, Empfänger- oder Ziel-URL | URL, an die der IdP SAML-Antworten sendet | http(s)://HOSTNAME/saml/consume |
SSO-URL (einmaliges Anmelden) des SP | |||
URL, an der der IdP mit dem SSO-Prozess beginnt | http(s)://HOSTNAME/sso |
SAML-Attribute
Die folgenden SAML-Attribute sind für verfügbar. Du kannst die Attributnamen in der Verwaltungskonsole ändern (mit Ausnahme des administrator
-Attributs). Weitere Informationen findest du unter Verwalten Ihrer Instanz über die Web-Benutzeroberfläche.
Name | Erforderlich | BESCHREIBUNG |
---|---|---|
NameID | Ein persistenter Benutzerkennzeichner. Es kann ein beliebiges Format für persistente Namenskennzeichner verwendet werden. das NameID -Element, damit es als Benutzername verwendet wird, es sei denn, es wird eine der alternativen Assertionen angegeben. Weitere Informationen finden Sie unter Überlegungen zum Benutzernamen für die externe Authentifizierung.> [!NOTE] Es ist wichtig, einen visuell lesbaren, beständigen Bezeichner zu verwenden. Die Verwendung eines vorübergehenden Bezeichnerformats urn:oasis:names:tc:SAML:2.0:nameid-format:transient führt dazu, dass Konten bei jeder Anmeldung erneut verknüpft werden, was sich nachteilig auf die Autorisierungsverwaltung auswirken kann. | |
SessionNotOnOrAfter | Das Datum, an dem die zugehörige Sitzung ungültig macht. Nach der Invalidierung muss die Person sich erneut authentifizieren, um auf Ihre GitHub Enterprise Server-Instance zuzugreifen. Weitere Informationen findest du unter Sitzungsdauer und Timeout. | |
administrator | Wenn der Wert true ist, wird den Benutzer automatisch zum Websiteadministrator hochstufen. Wenn das Attribut auf alles außer true festgelegt wird, folgt eine Herabstufung, solange der Wert nicht leer ist. Wenn das Attribut ausgelassen wird oder der Wert leer bleibt, wird die Rolle des Benutzers bzw. der Benutzerin nicht geändert. | |
username | Der Benutzername für Ihre GitHub Enterprise Server-Instance. | |
full_name | Der vollständige Name des Benutzer bzw. der Benutzerin auf der Benutzerprofilseite angezeigt. | |
emails | Dies ist die E-Mail-Adresse des Benutzers bzw. der Benutzerin. Sie können mehr als eine Adresse angeben. Wenn Sie die Lizenznutzung zwischen GitHub Enterprise Server und GitHub Enterprise Cloud synchronisieren, verwendet GitHub Connect emails , um eindeutige Benutzer*innen in verschiedenen Produkten zu identifizieren. Weitere Informationen findest du unter Synchronisieren der Lizenzverwendung zwischen GitHub Enterprise Server und GitHub Enterprise Cloud. | |
public_keys | Die öffentlichen SSH-Schlüssel für dendie Benutzerin angezeigt. Du kannst mehr als einen Schlüssel angeben. | |
gpg_keys | Die GPG-Schlüssel für dendie Benutzerin angezeigt. Du kannst mehr als einen Schlüssel angeben. |
Verwende mehrere <saml2:AttributeValue>
-Elemente, um mehrere Werte für ein Attribut anzugeben.
<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>
SAML-Antwortanforderungen
Bei muss die Antwortnachricht von deinem IdP die folgenden Anforderungen erfüllen.
-
Dein IdP musst das Element
<Destination>
im Stammantwortdokument bereitstellen und nur dann mit der ACS-URL übereinstimmen, wenn das Stammantwortdokument signiert ist. Wenn dein IdP die Assertion signiert, ignoriert die Assertion. -
Dein IdP muss das
<Audience>
-Element immer als Teil des<AudienceRestriction>
-Elements bereitstellen. Der Wert muss mit IhrerEntityId
für übereinstimmen. Dieser Wert ist die URL, über die Sie auf GitHub zugreifen, z. B.http(s)://HOSTNAME
. -
Dein Identitätsanbieter (IdP) muss eine einzelne Assertion in der Antwort mit einer digitalen Signatur bereitstellen. Hierfür kannst du das
<Assertion>
-Element oder das<Response>
-Element signieren. -
Dein IdP muss ein
<NameID>
-Element als Teil des<Subject>
-Elements bereitstellen. Du kannst ein beliebiges Format für beständige Namensbezeichner verwenden. -
Dein IdP muss das
Recipient
-Attribut enthalten, das auf die ACS-URL festgelegt werden muss. Im folgenden Beispiel wird das Attribut veranschaulicht.<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>
SAML-Signaturzertifikat für AuthnRequests-Elemente
Wenn du GitHub Enterprise Server zum ersten Mal einrichtest und die Instanz startest, wird getrennt vom SAML-Zertifikat des IDP ein selbstsigniertes SAML-Signaturzertifikat generiert. Dieses Zertifikat wird zum Signieren von SAML-AuthnRequests
-Elementen verwendet, die an den IdP gesendet werden. Das Zertifikat ist für zehn Jahre gültig. Es wird unter /data/user/common/saml-sp.p12
gespeichert, und du kannst Details im Base64-codierten Format unter http(s)://HOSTNAME/saml/metadata
anzeigen.
Wenn dein IdP das SAML-Signaturzertifikat überprüft oder SAML-verschlüsselte Assertionen aktiviert sind, treten bei Benutzenden möglicherweise Authentifizierungsprobleme auf, wenn das Zertifikat abläuft. Um das Ablaufdatum zu überprüfen, können GitHub Enterprise Server-Administrierende über SSH eine Verbindung mit dem Server herstellen und den folgenden Befehl ausführen. Weitere Informationen findest du unter Herstellen einer Verbindung mit der Verwaltungsshell über SSH.
sudo openssl pkcs12 -in /data/user/common/saml-sp.p12 -clcerts -nokeys -password pass: | sudo openssl x509 -noout -enddate
GitHub Enterprise Server-Administrierende können die folgenden Befehle in einer GitHub Enterprise Server-SSH-Sitzung ausführen, um dieses SAML-SP-Signaturzertifikat erneut zu generieren, wenn es abgelaufen und für den IdP oder verschlüsselte Assertionen erforderlich ist.
Note
Die nomad
-Befehle sorgen für kurze Unterbrechungen bei den Benutzenden, da der github-unicorn
-Dienst neu gestartet wird.
# 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
Sitzungsdauer und Timeout
Um zu verhindern, dass eine Person sich bei deinem IdP authentifiziert und auf unbestimmte Zeit autorisiert bleibt, macht die Sitzung für jedes Benutzerkonto mit Zugriff auf Ihre GitHub Enterprise Server-Instance in regelmäßigen Abständen ungültig. Nach der Invalidierung muss die Person sich erneut bei Ihrem IdP authentifizieren.
Wenn Ihr IdP keinen Wert für das SessionNotOnOrAfter
-Attribut angibt, macht eine Sitzung eine Woche nach der erfolgreichen Authentifizierung bei Ihrem IdP standardmäßig ungültig.
unterstützt eine angepasste Sitzungsdauer, wenn Ihr IdP die Möglichkeit bietet, ein SessionNotOnOrAfter
-Attribut und einen Wert zu konfigurieren, und wenn dieses Attribut in SAML-Antworten enthalten ist. Wenn Ihr IdP kein SessionNotOnOrAfter
-Attribut zulässt, kann ein Websiteadministrator ein benutzerdefiniertes SAML-Sitzungstimeout für alle Benutzer in Ihrer Instanz konfigurieren, indem er den ghe-config saml.default-session-expiration [seconds]
-Befehl in der administrativen Shell verwendet.
Wenn Sie einen angepassten Sitzungsdauerwert von weniger als 24 Stunden angeben, könnte es sein, dass Personen dazu auffordert, sich jedes Mal zu authentifizieren, wenn eine Umleitung initiiert.
Unabhängig von der für Ihre Instanz verwendeten Authentifizierungsmethode werden nach zwei Wochen fortlaufender Inaktivität eine Benutzersitzung beendet.
Note
Für Microsoft Entra ID (früher bekannt als Azure AD) steuert die konfigurierbare Lebensdauerrichtlinie für SAML-Token nicht die Sitzungstimeouts für .