Was eine SAML-Session auf GitHub technisch ist
Mit aktivem SAML SSO meldest du dich nicht direkt bei GitHub an, sondern bei deinem Identity Provider (IdP). Nach erfolgreicher Authentifizierung entsteht eine SAML-Session auf GitHub. Solange diese Session gültig ist, musst du dich beim Zugriff auf die meisten Organisationsressourcen nicht erneut anmelden. GitHub leitet dich nur dann zum IdP um, wenn eine erneute Authentifizierung fällig wird.
Wie lange eine Session gültig bleibt
Die Gültigkeit einer SAML-Session ist zeitbasiert, nicht ereignisbasiert. Setzt dein IdP kein SessionNotOnOrAfter-Attribut, invalidiert GitHub die Session standardmäßig 24 Stunden nach der erfolgreichen Authentifizierung. Du kannst über dieses Attribut eine kürzere Dauer konfigurieren, GitHub empfiehlt dafür aber mindestens 4 Stunden, kürzere Werte führen sonst dazu, dass GitHub bei praktisch jeder Weiterleitung erneut zur Anmeldung auffordert. Microsoft Entra ID unterstützt das Attribut laut GitHub nicht, dort greift deshalb in jedem Fall der 24-Stunden-Standard.
Warum eine Deaktivierung am IdP die laufende Session nicht sofort beendet
GitHub unterstützt kein SAML Single Logout. Das dokumentiert GitHub so: eine aktive Session endet nur, wenn sich die Person direkt beim IdP abmeldet. Daraus folgt eine naheliegende Schlussfolgerung, die GitHub selbst so nicht ausformuliert: ohne Single Logout gibt es keinen dokumentierten Push-Mechanismus, über den ein IdP eine bereits bestehende GitHub-Session von sich aus beendet, auch nicht beim Deaktivieren eines Kontos am IdP. Was genau in diesem konkreten Fall technisch passiert, dokumentiert GitHub nicht, dazu mehr im Abschnitt weiter unten. Belegt ist nur das Grundprinzip: eine Session endet laut Dokumentation durch aktiven Logout am IdP oder durch Ablauf ihres Zeitfensters, nicht durch ein drittes, separat dokumentiertes Ereignis. Das ist etwas anderes als die Zwei-Faktor-Pflicht in der GitHub-Organisation: 2FA wirkt beim nächsten Login-Versuch, die SAML-Session-Gültigkeit ist ein davon unabhängiges Zeitfenster, das schon vor diesem Login-Versuch läuft.
Die Ausnahme: SCIM-Provisioning
Es gibt einen Weg, auf dem eine IdP-seitige Änderung tatsächlich sofort durchschlägt: Unterstützt dein IdP die Provisionierung per SCIM, entfernt GitHub ein Mitglied automatisch aus der Organisation, sobald du ihm am IdP den Zugriff entziehst. Das betrifft laut GitHub-Dokumentation die Organisationsmitgliedschaft. Ob dabei auch eine zu diesem Zeitpunkt noch offene SAML-Session sofort invalidiert wird oder nur die Mitgliedschaft entfernt wird und die Session separat bis zum Ende ihres Zeitfensters weiterläuft, sagt die Dokumentation nicht.
Was GitHubs Dokumentation an dieser Stelle offen lässt
Zu einem Punkt liegt keine öffentliche Aussage von GitHub vor: was mit einer bereits aktiven Session passiert, wenn ein Konto ohne SCIM-Anbindung am IdP deaktiviert wird, und ob der nächste fällige Re-Authentifizierungsversuch dann sofort fehlschlägt oder erst beim IdP selbst geprüft wird. Beide hier zitierten Quellen beschreiben nur die beiden Bausteine, aus denen sich diese Lücke ergibt (kein Single Logout, zeitbasierte statt ereignisbasierte Invalidierung), nicht das IdP-seitige Deaktivierungsverhalten selbst. Wer das für den eigenen IdP sicher wissen will, muss es dort testen.
Was das für den Zugangsentzug beim Ausscheiden bedeutet
Diese Mechanik ist der technische Unterbau für einen Teilschritt im Offboarding in GitHub, nicht der Prozess selbst. Wer sich beim Zugangsentzug allein darauf verlässt, dass eine IdP-Deaktivierung die GitHub-Session sofort beendet, baut auf eine Eigenschaft, die so nicht dokumentiert ist. Ohne SCIM bleibt eine bereits offene Session bis zu ihrem Zeitfenster gültig, und PAT- oder SSH-Zugriffe laufen ohnehin über ihre eigene Gültigkeit, unabhängig von der SAML-Session.
Wo Unterstützung ansetzt
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen