Hallo, Entdecker! An dieser Seite wird aktiv gearbeitet, oder sie wird noch übersetzt. Die neuesten und genauesten Informationen finden Sie in unserer englischsprachigen Dokumentation.

Diese Version von GitHub Enterprise wird eingestellt am Diese Version von GitHub Enterprise wurde eingestellt am 2020-01-22. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nehmen Sie ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wenden Sie sich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

SAML verwenden

SAML ist ein XML-basierter Standard für die Authentifizierung und Autorisierung. GitHub Enterprise Server kann als ein Service Provider (SP) mit Ihrem internen SAML Identity Provider (IdP) funktionieren.

Inhalt dieses Artikels

If you want to authenticate users without adding them to your identity provider, you can configure built-in authentication. Weitere Informationen finden Sie unter „Integrierte Authentifizierung für Benutzer außerhalb Ihres Identity Providers zulassen“.

Unterstützte SAML-Dienste

We offer limited support for all identity providers that implement the SAML 2.0 standard. We officially support these identity providers that have been internally tested:

  • Active Directory Federation Services (AD FS)
  • Azure Active Directory (Azure AD)
  • Okta
  • OneLogin
  • PingOne
  • Shibboleth

GitHub Enterprise does not support SAML Single Logout. To terminate an active SAML session, users should log out directly on your SAML server.

Grundlegendes für Benutzernamen bei SAML

Jeder GitHub Enterprise Server-Benutzername wird nach Priorität geordnet durch eine der folgenden Assertions in der SAML-Antwort bestimmt:

  • das benutzerdefinierte Attribut für den Benutzernamen, sofern definiert und vorhanden
  • eine ggf. vorhandene Assertion http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
  • eine ggf. vorhandene Assertion http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  • das Element NameID

Das Element NameID ist selbst dann erforderlich, wenn andere Attribute vorhanden sind.

Zwischen NameID und dem GitHub Enterprise Server-Benutzernamen wird eine Zuordnung erstellt, daher sollte NameID persistent, eindeutig und für den Lebenszyklus des Benutzers nicht änderbar sein.

GitHub Enterprise Server-Benutzernamen dürfen nur alphanumerische Zeichen und Bindestriche (-) enthalten. GitHub Enterprise Server normalisiert nicht alphanumerische Zeichen im Benutzernamen Ihres Kontos zu einem Bindestrich. Beispielsweise wird der Benutzername gregory.st.john zu gregory-st-john normalisiert. Beachten Sie, dass die normalisierten Benutzernamen weder mit einem Bindestrich beginnen noch darauf enden können. Darüber hinaus können sie nicht zwei aufeinanderfolgende Bindestriche enthalten.

Anhand von E-Mail-Adressen erstellte Benutzernamen werden anhand der normalisierten Zeichen erstellt, die dem Zeichen @ vorangehen.

Wenn mehrere Konten zum selben GitHub Enterprise Server-Benutzernamen normalisiert werden, wird nur das erste Benutzerkonto erstellt. Nachfolgende Benutzer mit demselben Benutzernamen können sich nicht anmelden.

In dieser Tabelle finden Sie Beispiele dafür, wie Benutzernamen in GitHub Enterprise Server normalisiert werden:

Benutzername Normalisierter Benutzername Ergebnis
Ms.Bubbles ms-bubbles Dieser Benutzername wird erfolgreich erstellt.
!Ms.Bubbles -ms-bubbles Dieser Benutzername wird nicht erstellt, da er mit einem Bindestrich beginnt.
Ms.Bubbles! ms-bubbles- Dieser Benutzername wird nicht erstellt, da er mit einem Bindestrich endet.
Ms!!Bubbles ms--bubbles Dieser Benutzername wird nicht erstellt, da er zwei aufeinanderfolgende Bindestriche enthält.
Ms!Bubbles ms-bubbles Dieser Benutzername wird nicht erstellt. Obwohl der normalisierte Benutzername gültig ist, ist er bereits vorhanden.
Ms.Bubbles@example.com ms-bubbles Dieser Benutzername wird nicht erstellt. Obwohl der normalisierte Benutzername gültig ist, ist er bereits vorhanden.

Zwei-Faktor-Authentifizierung

Bei Verwendung von SAML oder CAS wird die Zwei-Faktor-Authentifizierung auf der GitHub Enterprise Server-Appliance weder unterstützt noch verwaltet, jedoch möglicherweise vom externen Authentifizierungsanbieter unterstützt. Die Erzwingung der Zwei-Faktor-Authentifizierung für Organisationen ist nicht verfügbar. Weitere Informationen zum Erzwingen der Zwei-Faktor-Authentifizierung für Organisationen finden Sie unter „Zwei-Faktor-Authentifizierung in Ihrer Organisation vorschreiben“.

SAML-Metadaten

Die Service Provider-Metadaten Ihrer GitHub Enterprise Server-Instanzen sind unter http(s)://[hostname]/saml/metadata verfügbar.

Wenn Sie Ihren Identity Provider manuell konfigurieren möchten, lautet die Assertionsverbraucherdienst-URL (ACS) http(s)://[hostname]/saml/consume. Dafür wird die Bindung urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST verwendet.

SAML-Attribute

Die folgenden Attribute sind verfügbar. Mit Ausnahme der administrator-Attribute können Sie die Attributnamen in der Managementkonsole ändern.

Standardmäßiger Attributname Typ Beschreibung
NameID Erforderlich Ein persistenter Benutzerkennzeichner. Es kann ein beliebiges Format für persistente Namenskennzeichner verwendet werden. Das Element NameID wird für einen GitHub Enterprise Server-Benutzernamen verwendet, sofern keine der alternativen Assertions bereitgestellt wird.
administrator Optional Wenn der Wert „true“ lautet, wird der Benutzer automatisch zu einem Administrator hochgestuft. Bei anderen oder nicht vorhandenen Werten wird der Benutzer auf ein normales Benutzerkonto zurückgestuft.
Benutzername Optional Der GitHub Enterprise Server-Benutzername.
full_name Optional Der Name des Benutzers, der auf seiner Profilseite angezeigt wird. Nach der Bereitstellung können Benutzer ihre Namen ändern.
emails Optional Die E-Mail-Adressen für den Benutzer. Es können mehrere angegeben werden.
public_keys Optional Die öffentlichen SSH-Schlüssel für den Benutzer. Es können mehrere angegeben werden.
gpg_keys Optional Die GPG-Schlüssel für den Benutzer. Es können mehrere angegeben werden.

SAML-Einstellungen konfigurieren

  1. Klicken Sie in der oberen rechten Ecke einer beliebigen Seite auf .

    Raumschiffsymbol für den Zugriff auf die Einstellungen des Websiteadministrators

  2. Klicken Sie auf der linken Seitenleiste auf Managementkonsole.

    Managementkonsole tab in the left sidebar

  3. Klicken Sie auf der linken Seitenleiste auf Authentication (Authentifizierung).

    Registerkarte „Authentication“ (Authentifizierung) auf der Seitenleiste mit den Einstellungen

  4. Wählen Sie SAML aus.

    SAML-Authentifizierung

  5. Optionally, select Allow built-in authentication to invite users to use built-in authentication if they don’t belong to Ihre GitHub Enterprise Server-Instanz's identity provider.

    Aktivierung des Kontrollkästchens für integrierte SAML-Authentifizierung

  6. Wählen Sie optional zum Aktivieren des Unsolicited-Response-SSOs die Option IdP initiated SSO (IdP-initiiertes SSO) aus. GitHub Enterprise Server antwortet auf eine von einem Identity Provider (IdP) initiierte unaufgeforderte Anforderung standardmäßig durch das Zurücksenden einer AuthnRequest an den IdP.

    IdP-SSO über SAML

    Hinweis: Der Wert sollte bei unselected (Nicht ausgewählt) belassen werden. Sie sollten dieses Feature nur dann aktivieren, wenn Ihre SAML-Implementierung das vom Service Provider initiierte SSO nicht unterstützt und Sie vom GitHub Enterprise-Support dazu angewiesen werden.

  7. Wählen Sie Disable administrator demotion/promotion (Hochstufen/Zurücksetzen des Administrators deaktivieren) aus, wenn Sie nicht möchten, dass Ihr SAML-Anbieter die Administratorrechte für Benutzer auf Ihre GitHub Enterprise Server-Instanz bestimmen kann.

    SAML-Konfiguration zum Deaktivieren der Administratoroption

  8. Geben Sie im Feld Single sign-on URL (Single Sign-On-URL) den HTTP- oder HTTPS-Endpunkt für Ihren IdP für Single Sign-On-Anforderungen ein. Dieser Wert wird durch Ihre IdP-Konfiguration angegeben. Wenn der Host in Ihrem internen Netzwerk nicht verfügbar ist, müssen Sie Ihre GitHub Enterprise Server-Instanz ggf. zur Verwendung interner Nameserver konfigurieren.

    SAML-Authentifizierung

  9. Geben Sie optional im Feld Issuer (Aussteller) den Namen Ihres SAML-Ausstellers ein. Dadurch wird die Authentizität von Nachrichten verifiziert, die an Ihre GitHub Enterprise Server-Instanz gesendet werden.

    SAML-Aussteller

  10. Wählen Sie in den Dropdownmenüs Signature Method (Signaturmethode) und Digest Method (Digest-Methode) den von Ihrem SAML-Aussteller verwendeten Hashalgorithmus aus, um die Integrität der Anforderungen von Ihre GitHub Enterprise Server-Instanz zu verifizieren. Geben Sie das Format mit dem Dropdownmenü Name Identifier Format (Format für Namenskennzeichner) an.

    SAML-Methode

  11. Klicken Sie unter Verification certificate (Verifizierungszertifikat) auf Choose File (Datei auswählen), und wählen Sie ein Zertifikat aus, um Ihre SAML-Antworten vom IdP zu validieren.

    SAML-Authentifizierung

  12. Ändern Sie die SAML-Attributnamen bei Bedarf so, dass sie mit Ihrem IdP übereinstimmen, oder akzeptieren Sie die Standardnamen.

    SAML-Attributnamen

Zugriff auf Ihre GitHub Enterprise Server-Instanz widerrufen

Wenn Sie einen Benutzer von Ihrem Identity Provider entfernen, müssen Sie ihn zudem manuell sperren. Andernfalls kann er sich weiterhin mithilfe der Zugriffstoken oder SSH-Schlüssel authentifizieren. Weitere Informationen finden Sie unter „Benutzer sperren und entsperren“.

Anforderungen für die Antwortmeldung

Die Antwortmeldung muss die folgenden Anforderungen erfüllen:

  • Das Element <Destination> muss nur dann im Dokument mit der Root-Antwort bereitgestellt werden und mit der Assertionsverbraucherdienst-URL.
  • Wenn ein <Audience>-Element als Bestandteil des <AudienceRestriction> bereitgestellt wird, wird es mit der GitHub Enterprise Server-Entitäts-ID abgeglichen. Hierbei handelt es sich um die URL zur GitHub Enterprise Server-Instanz, beispielsweise https://ghe.corp.example.com.
  • Jede Assertion in der Antwort muss durch eine digitale Signatur geschützt sein. Dies kann erfolgen, indem jedes einzelne <Assertion>-Element signiert wird oder indem das <Response>-Element signiert wird.
  • Ein <NameID>-Element muss als Bestandteil des <Subject>-Elements bereitgestellt werden. Es kann ein beliebiges Format für persistente Namenskennzeichner verwendet werden.
  • Ein Recipient-Attribut muss vorhanden und auf die Assertionsverbraucherdienst-URL festgelegt sein. Ein Beispiel:
<samlp:Response ...>
  <saml:Assertion ...>
    <saml:Subject>
      <saml:NameID ...>...</saml:NameID>
      <saml:SubjectConfirmation ...>
        <saml:SubjectConfirmationData Recipient="https://ghe.corp.example.com/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>

Fehlermeldungen

Wenn der Empfänger nicht mit der Assertionsverbraucherdienst-URL übereinstimmt, wird im Authentifizierungsprotokoll die folgende Fehlermeldung angezeigt:

Recipient in the SAML response was not valid.

Wenn Recipient kein Bestandteil der Antwortmeldung ist, wird im Authentifizierungsprotokoll die folgende Fehlermeldung angezeigt:

Recipient in the SAML response must not be blank.

Wenn die SAML-Antwort nicht signiert ist oder die Signatur nicht mit dem Inhalt übereinstimmt, wird im Authentifizierungsprotokoll die folgende Fehlermeldung angezeigt:

SAML Response is not signed or has been modified.

Menschliche Unterstützung einholen

Sie können das Gesuchte nicht finden?

Kontakt