SAML verwenden

If you want to authenticate users without adding them to your identity provider, you can configure built-in authentication. For more information, see "Allowing built-in authentication for users outside your identity provider."

In diesem Handbuch:

• Unterstützte SAML-Dienste
• Grundlegendes für Benutzernamen bei SAML
• Zwei-Faktor-Authentifizierung
• SAML-Metadaten
• SAML-Attribute
• SAML-Einstellungen konfigurieren
• Zugriff auf Ihre GitHub Enterprise Server-Instanz widerrufen
• Anforderungen für die Antwortmeldung
• Fehlermeldungen

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:

Two-factor authentication

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.

SAML-Einstellungen konfigurieren

1. In the upper-right corner of any page, click .

   

2. In the left sidebar, click Managementkonsole.

   

3. In the left sidebar, click Authentication.

   

4. Wählen Sie SAML aus.

   

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.

   

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.

   

   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. Select Disable administrator demotion/promotion if you do not want your SAML provider to determine administrator rights for users on Ihre GitHub Enterprise Server-Instanz.

   

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.

   

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.

   

10. In the Signature Method and Digest Method drop-down menus, choose the hashing algorithm used by your SAML issuer to verify the integrity of the requests from Ihre GitHub Enterprise Server-Instanz. Geben Sie das Format mit dem Dropdownmenü Name Identifier Format (Format für Namenskennzeichner) an.

    

11. Under Verification certificate, click Choose File and choose a certificate to validate SAML responses from the IdP.

    

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

    

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.