Shibboleth Single Sign-On-Architektur - Shibboleth Single Sign-on architecture

Shibboleth-Logo

Shibboleth ist ein Single-Sign-On- Login-System für Computernetzwerke und das Internet . Es ermöglicht Benutzern, sich mit nur einer Identität bei verschiedenen Systemen anzumelden, die von Verbänden verschiedener Organisationen oder Institutionen betrieben werden. Die Verbände sind oft Universitäten oder Organisationen des öffentlichen Dienstes.

Die Shibboleth Internet2 Middleware Initiative erstellt eine Architektur und Open-Source - Implementierung für das Identitätsmanagement und Federated Identity basierte Authentifizierung und Autorisierung (oder Zugriffskontrolle ) Infrastruktur auf Basis von Security Assertion Markup Language (SAML). Die föderierte Identität ermöglicht die gemeinsame Nutzung von Informationen über Benutzer aus einer Sicherheitsdomäne für die anderen Organisationen in einem Verbund. Dies ermöglicht ein domänenübergreifendes Single Sign-On und macht es den Inhaltsanbietern überflüssig, Benutzernamen und Kennwörter zu verwalten. Identitätsanbieter (IdPs) liefern Benutzerinformationen, während Dienstanbieter (SPs) diese Informationen verbrauchen und Zugriff auf sichere Inhalte gewähren.

Geschichte

Das Shibboleth-Projekt ist aus Internet2 hervorgegangen. Heute wird das Projekt vom Shibboleth-Konsortium verwaltet. Zwei der beliebtesten Softwarekomponenten, die vom Shibboleth Consortium verwaltet werden, sind der Shibboleth Identity Provider und der Shibboleth Service Provider, die beide Implementierungen von SAML sind .

Das Projekt wurde nach einer identifizierenden Passphrase benannt, die in der Bibel verwendet wird ( Richter 12:4–6 ), weil Ephraimiter nicht in der Lage waren, "sh" auszusprechen.

Das Shibboleth-Projekt wurde im Jahr 2000 gestartet, um die gemeinsame Nutzung von Ressourcen zwischen Organisationen mit inkompatiblen Authentifizierungs- und Autorisierungsinfrastrukturen zu erleichtern . Vor jeder Softwareentwicklung wurden über ein Jahr Architekturarbeiten durchgeführt. Nach Entwicklung und Tests wurde Shibboleth IdP 1.0 im Juli 2003 veröffentlicht. Es folgte die Veröffentlichung von Shibboleth IdP 1.3 im August 2005.

Version 2.0 der Shibboleth-Software war ein wichtiges Upgrade, das im März 2008 veröffentlicht wurde. Sie enthielt sowohl IdP- als auch SP-Komponenten, aber was noch wichtiger ist, Shibboleth 2.0 unterstützte SAML 2.0.

Die Protokolle Shibboleth und SAML wurden im gleichen Zeitraum entwickelt. Von Anfang an basierte Shibboleth auf SAML, aber wo SAML fehlte, improvisierte Shibboleth, und die Shibboleth-Entwickler implementierten Funktionen, die fehlende Funktionen in SAML 1.1 ausgleichen . Einige dieser Funktionen wurden später in SAML 2.0 integriert , und in diesem Sinne trug Shibboleth zur Entwicklung des SAML-Protokolls bei.

Das vielleicht wichtigste dazu beigetragene Feature war das alte Shibboleth AuthnRequest-Protokoll. Da das SAML 1.1-Protokoll von Natur aus ein IdP-First-Protokoll war, erfand Shibboleth ein einfaches HTTP-basiertes Authentifizierungsanforderungsprotokoll, das SAML 1.1 in ein SP-First-Protokoll verwandelte. Dieses Protokoll wurde zuerst in Shibboleth IdP 1.0 implementiert und später in Shibboleth IdP 1.3 verfeinert.

Aufbauend auf dieser frühen Arbeit führte die Liberty Alliance ein vollständig erweitertes AuthnRequest-Protokoll in das Liberty Identity Federation Framework ein. Schließlich wurde Liberty ID-FF 1.2 zu OASIS beigetragen, das die Grundlage für den OASIS SAML 2.0-Standard bildete.

Die Architektur

Shibboleth ist eine webbasierte Technologie, die die HTTP/POST-Artefakt- und Attribut-Push-Profile von SAML implementiert , einschließlich der Komponenten des Identitätsanbieters (IdP) und des Dienstanbieters (SP). Shibboleth 1.3 verfügt über eine eigene technische Übersicht, ein Architekturdokument und ein Konformitätsdokument, die auf den SAML 1.1-Spezifikationen aufbauen.

Shibboleth 1.3

Im kanonischen Anwendungsfall:

  1. Ein Benutzer greift zuerst auf eine Ressource zu, die von einem Webserver (dem Dienstanbieter) gehostet wird, bei dem der Shibboleth-Inhaltsschutz aktiviert ist.
  2. Der SP erstellt eine proprietäre Authentifizierungsanforderung, die unter Verwendung von URL-Abfrageparametern durch den Browser geleitet wird, um die SAML-Entitäts-ID des Anforderers, den Standort des Assertion-Verbrauchs und optional die Endseite bereitzustellen, zu der der Benutzer zurückkehren soll.
  3. Der Benutzer wird entweder zu seinem Heimat-IdP oder einem WAYF-Dienst (Where Are You From) weitergeleitet, wo er seinen Heimat-IdP für die weitere Umleitung auswählt.
  4. Der Benutzer authentifiziert sich bei einem Zugangskontrollmechanismus außerhalb von Shibboleth.
  5. Shibboleth generiert eine SAML 1.1-Authentifizierungs-Assertion mit einem darin enthaltenen temporären "Handle". Dieses Handle ermöglicht es dem IdP, eine Anfrage zu einem bestimmten Browserbenutzer als dem Prinzipal entsprechend zu erkennen, das sich zuvor authentifiziert hat.
  6. Der Benutzer wird an den Assertion Consumer Service des SP gesendet. Der SP konsumiert die Assertion und gibt eine AttributeQuery an den Attributdienst des IdP für Attribute über diesen Benutzer aus, die die Identität des Benutzers enthalten können oder nicht.
  7. Der IdP sendet eine Attributzusicherung mit vertrauenswürdigen Informationen über den Benutzer an den SP.
  8. Der SP trifft entweder eine Zugriffskontrollentscheidung basierend auf den Attributen oder liefert Informationen an Anwendungen, um selbst Entscheidungen zu treffen.

Shibboleth unterstützt eine Reihe von Variationen dieses Basisfalls, einschließlich Portal-Style-Flows, bei denen der IdP eine unaufgeforderte Assertion erstellt, die beim ersten Zugriff auf den SP zuzustellen ist, und Lazy-Session-Initiierung, die es einer Anwendung ermöglicht, den Inhaltsschutz durch eine Methode auszulösen seiner Wahl nach Bedarf.

Shibboleth 1.3 und früher bieten keinen integrierten Authentifizierungsmechanismus , aber jeder webbasierte Authentifizierungsmechanismus kann verwendet werden, um Benutzerdaten für Shibboleth bereitzustellen . Gängige Systeme für diesen Zweck sind CAS oder Pubcookie . Auch die Authentifizierungs- und Single-Sign-On-Funktionen des Java-Containers, in dem der IdP läuft (zB Tomcat), können genutzt werden.

Shibboleth 2.0

Shibboleth 2.0 baut auf SAML 2.0- Standards auf. Der IdP in Shibboleth 2.0 muss zusätzliche Verarbeitungen durchführen, um passive und erzwungene Authentifizierungsanforderungen in SAML 2.0 zu unterstützen. Der SP kann eine bestimmte Authentifizierungsmethode vom IdP anfordern. Shibboleth 2.0 unterstützt zusätzliche Verschlüsselungskapazität.

Attribute

Die Zugriffskontrolle von Shibboleth wird durchgeführt, indem von IdPs bereitgestellte Attribute mit von SPs definierten Regeln abgeglichen werden. Ein Attribut ist eine beliebige Information über einen Benutzer, z. B. „Mitglied dieser Community“, „Alice Smith“ oder „lizenziert gemäß Vertrag A“. Die Benutzeridentität wird als Attribut betrachtet und nur weitergegeben, wenn dies ausdrücklich erforderlich ist, wodurch die Privatsphäre des Benutzers gewahrt wird. Attribute können in Java geschrieben oder aus Verzeichnissen und Datenbanken abgerufen werden. Standard- X.520- Attribute werden am häufigsten verwendet, aber neue Attribute können beliebig definiert werden, solange sie von IdP und SP in einer Transaktion ähnlich verstanden und interpretiert werden.

Vertrauen

Vertrauen zwischen Domänen wird mithilfe von Kryptografie mit öffentlichen Schlüsseln (oft einfach TLS- Serverzertifikaten) und Metadaten, die Anbieter beschreiben, implementiert . Die Verwendung der weitergegebenen Informationen wird durch Vereinbarungen gesteuert. Föderationen werden häufig verwendet, um diese Beziehungen zu vereinfachen, indem eine große Anzahl von Anbietern zusammengefasst wird, die sich bereit erklären, gemeinsame Regeln und Verträge zu verwenden.

Entwicklung

Shibboleth ist Open Source und wird unter der Apache 2-Lizenz bereitgestellt. Viele Erweiterungen wurden von anderen Gruppen beigesteuert.

Annahme

In vielen Ländern der Welt wurden Föderationen gegründet, um Vertrauensstrukturen für den Informationsaustausch mit SAML- und Shibboleth-Software aufzubauen . Viele große Inhaltsanbieter unterstützen den Shibboleth-basierten Zugriff.

Im Februar 2006 gab das Joint Information Systems Committee (JISC) der Higher Education Funding Councils von England, Schottland, Wales und Nordirland bekannt, dass es vom Athener Authentifizierungssystem zu einem Zugangsverwaltungssystem auf Basis der Shibboleth-Technologie übergehen wird. Seitdem hat es seine Position aktualisiert und unterstützt eine föderierte Zugriffsverwaltungslösung anstelle von Shibboleth selbst.

Siehe auch

Verweise

Externe Links