{"id":3730,"date":"2025-01-24T10:00:36","date_gmt":"2025-01-24T09:00:36","guid":{"rendered":"https:\/\/informatik.htwk-leipzig.de\/seminar\/?p=3730"},"modified":"2025-03-24T23:53:29","modified_gmt":"2025-03-24T22:53:29","slug":"shibboleth","status":"publish","type":"post","link":"https:\/\/informatik.htwk-leipzig.de\/seminar\/lehrveranstaltungen\/betriebliche-informationssysteme\/2025\/shibboleth\/","title":{"rendered":"Shibboleth"},"content":{"rendered":"

1<\/span> Einf\u00fchrung<\/h1>\n

Heutzutage ist der Zugriff auf eine Vielzahl von Online-Diensten und -Ressourcen erforderlich. Vor allem in f\u00f6derierten Systemen sind Single-Sign-On<\/em>-Systeme (SSO) weit verbreitet. Diese erm\u00f6glichen es, dass Benutzer:innen nach einmaliger Authentifizierung Zugriff auf verschiedene Anwendungen und Dienste haben, d.h. ohne sich mehrfach anmelden zu m\u00fcssen [1]<\/a><\/span>.<\/p>\n

Shibboleth<\/em> ist ein Open-Source-Softwareprojekt f\u00fcr Web-basiertes SSO und Identit\u00e4tsmanagement f\u00fcr f\u00f6derierte Systeme, wie beispielsweise akademische Institute, Identit\u00e4tsverb\u00e4nde oder kommerzielle Organisationen. Verschiedene Komponenten verwalten die Authentifizierung sowie den Zugriff auf gesch\u00fctzte Ressourcen [2]<\/a>, [3]<\/a>, [4]<\/a><\/span>.<\/p>\n

Vor allem an akademischen Institutionen, wie der Hochschule f\u00fcr Technik, Wirtschaft und Kultur Leipzig (HTWK), wird Shibboleth eingesetzt. Bei der HTWK erm\u00f6glicht Shibboleth im Verbund des Deutschen Forschungsnetzes<\/em> (DFN) beispielsweise ein sicheres Identit\u00e4tsmanagement sowie ein Login mit nur einem Benutzernamen und Passwort bei verschiedenen Web-Diensten [1]<\/a>, [4]<\/a>, [5]<\/a><\/span>.<\/p>\n

So ist es an der HTWK m\u00f6glich, sich unter anderem bei den E-Learning Plattformen OPAL<\/em><\/a> und AutoTool<\/em><\/a>, der HTWK-Webseite, den verschiedenen GitLab-Instanzen, der Hochschulbibliothek oder verschiedenen wissenschaftliche Ressourcen wie IEEE Xplore<\/em> und SpringerLink<\/em> mit denselben Logindaten anzumelden [1]<\/a>, [5]<\/a><\/span>. Die Authentifizierung wird \u00fcber einen zentralen Identity Provider<\/em> durchgef\u00fchrt und vereinfacht die Nutzung der Services durch Studierende und Mitarbeitende. Ebenso ist eine einfachere und sicherere Administration des Identit\u00e4tsmanagements m\u00f6glich [1]<\/a><\/span>.<\/p>\n

Der folgende Artikel gibt einen \u00dcberblick \u00fcber Shibboleth. Zun\u00e4chst werden die grundlegenden Begriffe erl\u00e4utert, gefolgt von einer detaillierten Darstellung des Prozessablaufs anhand eines Beispielszenarios. Weiterhin werden die Vor- und Nachteile im Vergleich zu \u00e4hnlichen Softwarel\u00f6sungen diskutiert. Abschlie\u00dfend wird ein Fazit gezogen.<\/p>\n

2<\/span> Grundlegende Begriffe<\/h1>\n

Im folgenden Abschnitt werden verschiedene theoretische Grundlagen gelegt und zentrale Begriffe erl\u00e4utert. Zun\u00e4chst werden die zentralen Komponenten sowie der grundlegende Prozessablauf des Shibboleth-Systems erl\u00e4utert. Anschlie\u00dfend wird ein Beispiel-Szenario skizziert, auf welchem die Erkl\u00e4rung in Abschnitt\u00a01.3<\/a> basiert.<\/p>\n

2.1<\/span> Komponenten<\/h2>\n

Das Shibboleth-System verwendet insgesamt drei Hautkomponenten w\u00e4hrend des Login-Prozesses:<\/p>\n

    \n
  1. Identity Provider<\/em> (IdP) sind f\u00fcr die Authentifizierung der Benutzer:innen zust\u00e4ndig. Sie geben die Informationen \u00fcber diese an den jeweiligen Service Provider weiter. IdPs werden dabei in der Home-Organisation der jeweiligen Benutzer:innen verwaltet, d.h. dort, wo das entsprechende Benutzerkonto befindet, wie beispielsweise Bildungs- und Forschungseinrichtungen [6]<\/a>, [7]<\/a><\/span>.<\/li>\n
  2. Service Provider<\/em> (SP) dienen dem Schutz der eigentlich angefragten gesch\u00fctzten Online-Ressourcen und werden innerhalb der sogenannten Ressource Organisation<\/em> verwaltet. Sie pr\u00fcfen die Authentifizierung vom IdP, autorisieren die Benutzer:innen basierend auf den erhaltenen Informationen und stellen schlie\u00dflich den Zugriff auf die angefragte Ressource bereit [6]<\/a>, [8]<\/a>, [9]<\/a><\/span>. Service Provider k\u00f6nnen beispielsweise Content-Provider, E-Learning-Plattformen, oder Bibliotheken sein [7]<\/a><\/span>.<\/li>\n
  3. Discovery Services<\/em> (DS) unterst\u00fctzen Service Provider bei der Ermittlung des Identity Providers der Benutzer:innen, da die Ressource keine Information \u00fcber die Home-Organisation hat. Sie stellen einen Service zur Pr\u00e4sentation eines Standard-Interfaces dar, mit welchem die Benutzer:innen ihre Home-Organisation (und damit IdP) ausw\u00e4hlen k\u00f6nnen. Somit stellen sie einen Where Are You From Service<\/em> (WAYF) dar. DS k\u00f6nnen mit der Ressource verbunden oder als zentraler, geteilter Service betrieben werden [6]<\/a>, [10]<\/a>, [11]<\/a><\/span>.<\/li>\n<\/ol>\n

    2.2<\/span> Grundlegender Ablauf<\/h2>\n

    Der grundlegende Ablauf zum Zugriff auf eine gesch\u00fctzte Ressource verl\u00e4uft wie folgt: Zun\u00e4chst fragt ein:e Benutzer:in den Zugriff auf eine bestimmte gesch\u00fctzte Ressource bei einem Service Provider an. Dieser leitet zum Discovery Service weiter, mit welchem der zust\u00e4ndige Identity Provider des oder der Benutzer:in ermittelt wird. Anschlie\u00dfend generiert der SP eine Authentifizierungsanfrage und sendet diese an den ermittelten IdP. Bei diesem findet die Authentifizierung statt. Der SP verifiziert die Authentifizierungsantwort vom IdP und sendet eine Anfrage an die Ressource, welche den urspr\u00fcnglich angefragten Inhalt zur\u00fcckgibt [6]<\/a>, [12]<\/a>, [13]<\/a><\/span>. Der Ablauf ist in Abbildung\u00a01<\/a> skizziert.<\/p>\n

    \"Abbildung
    Abbildung 1: Grundlegender Ablauf (nach Beschreibungen aus [6]<\/a>, [12]<\/a>, [13]<\/a><\/span>)<\/figcaption><\/figure>\n

    2.3<\/span> Szenario<\/h2>\n

    In den weiterf\u00fchrenden Abschnitten soll das folgende Szenario genauer beleuchtet werden. Eine Benutzerin der Universit\u00e4t A (uni-a.example<\/code>) m\u00f6chte auf eine gesch\u00fctzte \u201cRessource B\u201d zugreifen. Diese wird auf der Seite pool.example\/resource-b<\/code> angeboten. Der Discovery Service ist dabei unter discovery.pool.example<\/code> und der Identity Provider der Home Organisation (hier Universit\u00e4t A) unter idp.uni-a.example<\/code> erreichbar.<\/p>\n


    \n
    \n
    \n<\/p>\n

    3<\/span> Prozessablauf im Detail<\/h1>\n

    In diesem Abschnitt wird der vereinfachte Prozessablauf, welcher in Abschnitt\u00a01.2.3<\/a> dargestellt wurde, vertiefend erkl\u00e4rt. Dabei soll das dort eingef\u00fchrte Szenario verfolgt werden. Der Prozess erfolgt in drei \u00fcbergeordneten Phasen:<\/p>\n

      \n
    1. Erster Zugriff auf den Service Provider und Identity Provider Discovery (siehe Abbildung\u00a02<\/a>)<\/li>\n
    2. Session Initialisierung und Authentifizierungsanfrage (siehe Abbildung\u00a03<\/a>)<\/li>\n
    3. Authentifizierung, Autorisierung und Ressourcenzugriff (siehe Abbildung\u00a04<\/a>) [12]<\/a>, [14]<\/a><\/span>.<\/li>\n<\/ol>\n

      Die einzelnen Phasen werden im Folgenden genauer erl\u00e4utert und als Business Process Model and Notation<\/em> (BPMN) Diagrammen dargestellt. Die erste Phase ist dabei in gr\u00fcn, die zweite in orange und die dritte in lila markiert. Ein BPMN-Diagramm, welches alle drei Phasen enth\u00e4lt, kann online<\/a>1<\/sup><\/a> eingesehen werden.<\/p>\n

      3.1<\/span> Phase 1: Identity Provider Discovery<\/h2>\n

      Im folgenden Abschnitt wird die erste Phase des Login-Prozesses mittels Shibboleth erl\u00e4utert. Dabei handelt es sich um den ersten Zugriff einer Benutzerin oder eines Benutzers auf eine gesch\u00fctzte Ressource, d.h. auf den Service Provider. Dabei ist diese Person noch nicht<\/em> beim jeweiligen Identity Provider angemeldet, sodass die Identity Provider Discovery<\/em> stattfinden muss. Der Prozess ist als BPMN-Diagramm in Abbildung\u00a02<\/a> dargestellt.<\/p>\n

      \"Abbildung
      Abbildung 2: BPMN-Diagramm zu Phase 1 des Login-Prozesses mittels Shibboleth (nach Beschreibung aus [12]<\/a><\/span>)<\/figcaption><\/figure>\n

      Zun\u00e4chst greift die Benutzerin erstmalig auf die gesch\u00fctzte Ressource zu. Dabei wird folgende GET<\/code>-Request gestellt:<\/p>\n

      GET https:\/\/www.pool.example\/resource-b<\/code><\/pre>\n
      Da die angefragte Ressource \u00fcber das Shibboleth-System, insbesondere den Service Provider, gesch\u00fctzt ist, wird die Anfrage vom Service Provider gepr\u00fcft. Dabei wird kontrolliert, ob bereits eine aktive Shibboleth-Session vorliegt, d.h. ob die Nutzerin bereits authentifiziert ist. Diese Information w\u00e4re im _shibsession<\/code>-Cookie enthalten. Falls dieser aktuell und g\u00fcltig ist, wird die Benutzerin schlussendlich an die Ressource weitergeleitet. Dieses Szenario wird in Abschnitt\u00a01.3.3<\/a> genauer erl\u00e4utert [12]<\/a>, [14]<\/a><\/span>.<\/p>\n
      Falls jedoch noch keine aktive Shibboleth-Session vorliegt, wird die Benutzerin zum Discovery Service weitergeleitet. Da die Information, wohin die Benutzenden nach Auswahl der Home Organisation geschickt werden sollen, nicht verloren gehen darf, wird der _shibstate<\/code>-Cookie gesetzt und Parameter mitgesendet. In neueren Shibboleth-Versionen wird dies mittels Relay State<\/em>-Mechanismen gespeichert [12]<\/a>, [14]<\/a><\/span>. <\/p>\n
      302 FOUND (REDIRECT)\r\n  Set-Cookie: _shibstate_64656661756c7468747470733a2f2...\r\n    value=https:\/\/pool.example\/resource-b\r\n    path=\/\r\n\r\n  Location: https:\/\/discovery.pool.example\/WAYF\r\n  ?entityID=https:\/\/pool.example\/shibboleth\r\n  &return=https:\/\/pool.example\/Shibboleth.sso\/Login?SAMLDS=1&target=ss:mem\r\n\r\nGET https:\/\/discovery.pool.example\/WAYF\r\n  ?entityID=https:\/\/pool.example\/shibboleth\r\n  &return=https:\/\/pool.example\/Shibboleth.sso\/Login?SAMLDS=1&target=ss:mem<\/code><\/pre>\n
      Der Discovery Service ermittelt nun die Liste der verf\u00fcgbaren bzw. unterst\u00fctzten Identity Provider, welche im folgenden der Nutzerin pr\u00e4sentiert werden. Diese w\u00e4hlt ihren zutreffenden Identity Provider aus \u2013 in diesem Szenario entsprechend Universit\u00e4t A (idp.uni-a.example<\/code>). Daher wird die Nutzerin im Anschluss an den ausgew\u00e4hlten Identity Provider der Home Organisation weitergeleitet [12]<\/a><\/span>.<\/p>\n
      POST https:\/\/discovery.pool.example\/WAYF\r\n  ?entityID=https:\/\/pool.example\/shibboleth\r\n  &return=https:\/\/pool.example\/Shibboleth.sso\/Login?SAMLDS=1&target=ss:mem\r\n\r\nPOSTDATA\r\n  user_idp=https:\/\/idp.uni-a.example\/shibboleth\r\n\r\n302 FOUND (REDIRECT)\r\nLocation: https:\/\/pool.example\/shibboleth\/Login\r\n  ?SAMLDS=1\r\n  &target=ss:mem\r\n  &entityID=https:\/\/idp.uni-a.example\/shibboleth<\/code><\/pre>\n
      3.2<\/span> Phase 2: Session Initialisierung und Authentifizierungsanfrage<\/h2>\n
      In Phase 2 wird die Session initialisiert und eine Authentifizierungsanfrage gestellt. Der Prozess ist als BPMN-Diagramm in Abbildung\u00a03<\/a> dargestellt.<\/p>\n
      \"Abbildung
      Abbildung 3: BPMN-Diagramm zu Phase 2 des Login-Prozesses mittels Shibboleth (nach Beschreibung aus [12]<\/a><\/span>)<\/figcaption><\/figure>\n
      Aufgrund des vorherigen Redirects zum Identity Provider der Home Organisation der Benutzerin, sendet der Browser nun eine GET<\/code>-Request an den IdP. Der Session Initiator<\/em> erstellt weiterhin eine Authentifizierungsanfrage (AuthN), welche automatisch mittels JavaScript abgesendet wird [12]<\/a><\/span>.<\/p>\n
      GET https:\/\/pool.example\/shibboleth\/Login\r\n  ?SAMLDS=1\r\n  &target=ss:mem\r\n  &entityID=https:\/\/idp.uni-a.example\/shibboleth\r\n\r\nPOST https:\/\/idp.uni-a.example\/profile\/SAML2\/POST\/SSO\r\n  POSTDATA\r\n    RelayState=ss:mem:23e3a3b1268acd89dc226bb1ce0d0c6ba7ecf773\r\n    SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCB4bWxuczp...<\/code><\/pre>\n
      Der IdP pr\u00fcft anschlie\u00dfend die Authentifizierungsanfrage. Wenn diese g\u00fcltig ist, wird zun\u00e4chst festgestellt, ob die Nutzerin bereits authentifiziert ist. Dies wird anhand des _idp_session<\/code>-Cookies \u00fcberpr\u00fcft. Falls dem nicht so ist, wird eine geeignete Authentifizierungsmethode f\u00fcr die Benutzerin, basierend auf dem Protokoll des Service Providers, ausgew\u00e4hlt. Die Benutzerin wird anschlie\u00dfend an einen kompatiblen Login-Handler weitergeleitet [12]<\/a>, [14]<\/a><\/span>. Dieses Szenario wird in Abschnitt\u00a01.3.3<\/a> genauer beschrieben.<\/p>\n
      In diesem Beispiel soll ein Nutzername und Passwort zur Authentifizierung verwendet werden. Bei diesem Redirect wird vom IdP ein AuthN-Cookie gesetzt, welcher Informationen zur Ressource und einen Authentifizierungstoken enth\u00e4lt. Anschlie\u00dfend wird die Nutzerin zur tats\u00e4chlichen, spezifischen Anmeldeseite weitergeleitet [12]<\/a><\/span>.<\/p>\n
      302 MOVED TEMPORARILY (REDIRECT)\r\n  Set-Cookie: _idp_authn_lc_key\r\n    value=C22C16A197CB9606067A1A577EF5D996\r\n    Path=\/idp\r\n    Secure\r\n\r\n  Location: https:\/\/idp.uni-a.example:443\/AuthnEngine\r\n\r\nGET https:\/\/idp.uni-a.example\/AuthnEngine\r\n  Cookie: _idp_authn_lc_key\r\n    value=C22C16A197CB9606067A1A577EF5D996\r\n\r\n302 MOVED TEMPORARILY (REDIRECT)\r\n  Location: https:\/\/idp.uni-a.example:443\/Authn\/UserPassword\r\n\r\nGET https:\/\/idp.uni-a.example\/Authn\/UserPassword\r\n  Cookie: _idp_authn_lc_key\r\n    value=C22C16A197CB9606067A1A577EF5D996<\/code><\/pre>\n
      3.3<\/span> Phase 3: Ressourcenzugriff<\/h2>\n
      In der letzten Phase kommt es schlie\u00dflich zum Ressourcenzugriff. Der Ablauf wird im folgenden beschrieben und ist als BPMN-Diagramm in Abbildung\u00a04<\/a> dargestellt.<\/p>\n
      \"Abbildung
      Abbildung 4: BPMN-Diagramm zu Phase 3 des Login-Prozesses mittels Shibboleth (nach Beschreibung aus [12]<\/a><\/span>)<\/figcaption><\/figure>\n
      Auf der Anmeldeseite des Identity Providers gibt die Benutzerin anschlie\u00dfend ihre Anmeldedaten ein. Diese werden mittels POST<\/code>-Request an den IdP geschickt, welche den AuthN-Cookie enth\u00e4lt [12]<\/a><\/span>.<\/p>\n
      POST https:\/\/idp.uni-a.example\/Authn\/UserPassword\r\n  POSTDATA\r\n    j_username=demouser\r\n    j_password=demo\r\n\r\n  Cookie: _idp_authn_lc_key\r\n    value=C22C16A197CB9606067A1A577EF5D996<\/code><\/pre>\n
      Nach erfolgreicher Verifikation der Anmeldedaten durch den IdP, findet das Attribute Resolving<\/em> und Filtering<\/em> statt. Die erhaltenen Daten werden basierend auf den Protokollen und der Konfiguration des Service Providers durch einen Attribut-Filter auf die unbedingt notwendigen Daten reduziert, um ein Ma\u00df von Datenschutz zu gew\u00e4hrleisten. Anschlie\u00dfend wird eine HTML-Seite generiert, welche eine SAML Assertion<\/em> beinhaltet. Letztere umfasst das Authentifizierungsstatement sowie das Attribute-Statement<\/em>, welches die Nutzerattribute enth\u00e4lt. Die Daten werden in eine geeignete Form transformiert und ggf. verschl\u00fcsselt sowie signiert. Die Assertion wird daraufhin automatisch abgesendet. Zudem wird nun der _idp_session<\/code>-Cookie gesetzt, der bei einer erneuten Authentifizierung durch denselben IdP ausgewertet wird. Direkt im Anschluss sendet der Browser eine POST<\/code>-Request an den Service Provider, die sowohl die SAML-Response<\/em> als auch den _shibstate<\/code>-Cookie enth\u00e4lt [12]<\/a>, [14]<\/a><\/span>.<\/p>\n
      200 OK\r\nSet-Cookie: _idp_session\r\n  value=4m2ETlKYtvbNEmBzVNo3UHLuKSdo3HqTUqAmeZiar94=\r\n  Path=\/idp\r\n\r\n[ASSERTION POST FORM HTML PAGE] \r\n\r\nPOST https:\/\/uni-a.example\/Shibboleth.sso\/SAML2\/POST\r\n  POSTDATA\r\n    RelayState=cookie\r\n    SAMLResponse=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGl...\r\n\r\n  Cookie: _shibstate_64656661756c7468747470733a2f2...\r\n    value=https:\/\/pool.example\/resource-b<\/code><\/pre>\n
      Anschlie\u00dfend verarbeitet der Service Provider die SAML-Assertion sowie die Authentifizierungs- und Attribut-Statements. Dabei werden die Attribute sowie andere Informationen aus der Nachricht extrahiert und eine neue User-Session erstellt. Schlie\u00dflich wird die Nutzerin zur angefragten Ressource weitergeleitet, wobei ein Verweis auf die Ressource im _shibstate<\/code>-Cookie bzw. Relay-State hinterlegt wird. Weiterhin wird der _shibsession<\/code>-Cookie gesetzt, wodurch ein erneuter Zugriff auf den Service Provider (innerhalb einer bestimmten Zeit) direkt als authentifiziert gilt [12]<\/a>, [14]<\/a><\/span>.<\/p>\n
      302 FOUND (REDIRECT)\r\n  Set-Cookie: _shibstate_64656661756c7468747470733a2f2...\r\n    value=\r\n    path=\/\r\n\r\n  Set-Cookie: _shibsession_64656661756c7468747470733a2f2...\r\n    value=_0b6d4e89d2e9c4481738094f2a2c9de0\r\n    path=\/\r\n\r\n  Location: https:\/\/pool.example\/resource-b<\/code><\/pre>\n
      Schlussendlich findet eine erneute Anfrage an die gesch\u00fctzte Ressource (pool.example\/resource-b<\/code>) durch den Browser statt, welcher den _shibsession<\/code>-Cookie enth\u00e4lt. [14]<\/a><\/span>.<\/p>\n
      GET https:\/\/pool.example\/resource-b\r\n  Cookie: _shibsession_64656661756c7468747470733a2f2...\r\n    value=_0b6d4e89d2e9c4481738094f2a2c9de0<\/code><\/pre>\n
      Erneut wird der _shibsession<\/code>-Cookie \u00fcberpr\u00fcft, wodurch diesmal eine aktive Shibboleth-Session erkannt wird. Somit kann die Autorisierung stattfinden, d.h. die \u00dcberpr\u00fcfung, ob die Benutzerin \u00fcber die notwendigen Rechte zum Zugriff auf die gew\u00fcnschte Ressource verf\u00fcgt. Die Rechte werden \u00fcber alle anwendbaren Access-Control<\/em>-Plugins, bspw. Shibboleth Access Rules<\/em>, ermittelt, wobei unter anderem die Benutzer-Attribute abgeglichen werden. Da die Benutzerin in dem Fall \u00fcber die notwendigen Rechte verf\u00fcgt, wird der Zugriff schlussendlich auf die initial angefragte, gesch\u00fctzte Ressource gew\u00e4hrt [12]<\/a><\/span>.<\/p>\n
      200 OK\r\n  [RESOURCE HTML PAGE]<\/code><\/pre>\n
      4<\/span> Diskussion<\/h1>\n
      Im folgenden Abschnitt wird Shibboleth diskutiert. Dabei wird auf die Vorteile und Nachteile eingegangen und verschiedene Alternativen beleuchtet. Abschlie\u00dfend wird ein kurzer Einblick in die Agenda der nahen Zukunft gegeben.<\/p>\n
      Shibboleth ist seit 2000 in Verwendung und hat sich seitdem zu einem etablierten SSO-System entwickelt [2]<\/a><\/span>. Grunds\u00e4tzlich fallen als Open Source Software keine Kosten an. Das Shibboleth Consortium<\/em> bietet allerdings kostenpflichtige Mitgliedschaften an, die das Projekt finanzieren und den Mitgliedern Hilfestellungen (Support<\/em>) sowie weitere Partizipationsm\u00f6glichkeiten bieten [2]<\/a>, [15]<\/a><\/span>. Dabei wird ein j\u00e4hrlicher Beitrag erhoben, der auf der Art und Gr\u00f6\u00dfe der Institution basiert [16]<\/a><\/span>. Gr\u00f6\u00dfere Mitglieder sind unter anderem der Verein zur F\u00f6rderung eines Deutschen Forschungsnetzes (DFN-Verein), die Stanford University, die University of Oxford oder das Massachusetts Institute of Technology (MIT) [4]<\/a><\/span>. Shibboleth unterst\u00fctzt verschiedene Standardprotokolle wie beispielsweise SAML, OpenID Connect und LDAP [3]<\/a>, [17]<\/a><\/span>. Au\u00dferdem ist es Windows-unabh\u00e4ngig und dezentral [17]<\/a><\/span>.<\/p>\n
      Shibboleth ist nicht f\u00fcr Unternehmen gedacht, welche haupts\u00e4chlich interne Zugriffsverwaltung und Authentifizierung ben\u00f6tigen. Vielmehr unterst\u00fctzt es den Austausch von Authentifizierungsdaten zwischen verschiedenen, teils externen Organisationen (f\u00f6derierte Identit\u00e4ten). Weiterhin ist eine eigenverantwortliche Administration notwendig [3]<\/a><\/span>.<\/p>\n
      4.1<\/span> Alternativen<\/h2>\n
      Eine Alternative zu Shibboleth ist Active Directory<\/em> (AD), bei der es sich um ein On-Premise Identit\u00e4tsmanagementsystem handelt[18]<\/a><\/span>, welches sich besonders gut f\u00fcr Windows-Umgebungen eignet. Die Einrichtung und Verwaltung ist jedoch komplex und es wird kein Web-basiertes SSO angeboten.<\/p>\n
      Ein alternatives Identit\u00e4tsmanagementsystem mit SSO ist Azure Active Directory<\/em> (AAD) bzw. Microsoft Entra ID<\/em> [19]<\/a>, [20]<\/a><\/span>, welches im Vergleich zu AD Cloud-basiert ist und Microsoft Abh\u00e4ngigkeiten besitzt [18]<\/a><\/span>. Dadurch eignet sich Microsoft Entra ID besonders f\u00fcr Unternehmen, die vollst\u00e4ndig in Microsoft 365 und Azure integriert sind.<\/p>\n
      Dar\u00fcber hinaus gibt es weitere kostenpflichtige Alternativen wie Okta<\/em>, OneLogin<\/em> oder Ping Identity<\/em>, welche ebenfalls Cloud-basierte L\u00f6sungen sind und den Fokus auf unterschiedliche Aspekte wie Sicherheit oder Benutzerfreundlichkeit legen [21]<\/a>, [22]<\/a>, [23]<\/a><\/span>.<\/p>\n
      4.2<\/span> Zukunft<\/h2>\n
      Die Agenda von Shibboleth sieht vor, bis 2027 die passwortlose Authentifikation zu erm\u00f6glichen, sodass Nutzer:innen beispielsweise mit FIDO, WebAuthn und Passkeys vom Login-Handler authentifiziert werden k\u00f6nnen. Zudem sollen Digital Wallets<\/em> und verifizierte Anmeldedaten angegangen werden, wobei die Hauptrolle darin gesehen wird, ein Aussteller dieser zu werden oder sie zu verifizieren [24]<\/a><\/span>.<\/p>\n
      Verbessert werden soll die Produktdokumentation und Konfiguration der IdPs, um einen Fokus auf Konzepte, einleitendes Material und Beispiele zu legen. Dies geht einher mit der Neukonzeption der SPs, welche zuk\u00fcnftig als Plugin f\u00fcr IdPs eingef\u00fchrt werden sollen [24]<\/a><\/span>.<\/p>\n
      Dar\u00fcber hinaus soll die OpenID Federation<\/em> unterst\u00fctzt werden, um die Harmonie zwischen den SAML und OpenID Metadaten zu verst\u00e4rken. Au\u00dferdem sollen weitere UI-Komponenten zum IdP hinzugef\u00fcgt werden, welche sich unter anderem mit dem Management von Login-Aktivit\u00e4ten sowie einer passwortlosen Authentifikation befassen [24]<\/a><\/span>.<\/p>\n
      5<\/span> Zusammenfassung<\/h1>\n
      Shibboleth ist ein sich weiterentwickelndes Web-basiertes SSO und Identit\u00e4tsmanagementsystem, bestehend aus drei Komponenten: Identity Provider (IdP), Service Provider (SP) und Discovery Service (DS).<\/p>\n
      Zust\u00e4ndig f\u00fcr die Verwaltung der gesch\u00fctzten Ressourcen ist der SP, welcher bei einer Zugriffsanfrage nach einer aktiven Session und Autorisierung pr\u00fcft. Besteht keine aktive Session, stellt der DS zur Ermittlung des zust\u00e4ndigen IdPs der oder dem Benutzer:in eine Auswahl von Home-Organisations. Der ausgew\u00e4hlte IdP authentifiziert anschlie\u00dfend die oder den Benutzer:in und schickt erneut eine Zugriffsanfrage an den SP.<\/p>\n
      Dieses Verfahren erm\u00f6glicht den Austausch von Authentifizierungsdaten auch zwischen verschiedenen externen Organisationen und wird dadurch vor allem von f\u00f6derierten Institutionen eingesetzt. Als Open Source Software fallen keine Kosten an, es gibt aber die M\u00f6glichkeit einer kostenpflichtigen Mitgliedschaft, welche unter anderem Support f\u00fcr die ansonsten eigenverantwortliche Administration anbietet.<\/p>\n
      6<\/span> Literatur<\/h1>\n
      \n
      \n
      [1]<\/div>\n
      SWITCH, \u201eIntroduction – About – SWITCHaai\u201c. Zugegriffen: 17. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/help.switch.ch\/aai\/about\/introduction\/<\/a><\/div>\n<\/div>\n
      \n
      [2]<\/div>\n
      Shibboleth, \u201eShibboleth Consortium\u201c. Zugegriffen: 29. Oktober 2024. [Online]. Verf\u00fcgbar unter: https:\/\/www.shibboleth.net\/<\/a><\/div>\n<\/div>\n
      \n
      [3]<\/div>\n
      S. Cantor, \u201eConsortium FAQ – Shibboleth Consortium\u201c. Zugegriffen: 29. Oktober 2024. [Online]. Verf\u00fcgbar unter: https:\/\/shibboleth.atlassian.net\/wiki\/spaces\/consort\/pages\/2913075221<\/a><\/div>\n<\/div>\n
      \n
      [4]<\/div>\n
      Shibboleth, \u201eOur Members\u201c. Zugegriffen: 29. Oktober 2024. [Online]. Verf\u00fcgbar unter: https:\/\/www.shibboleth.net\/about-us\/members\/<\/a><\/div>\n<\/div>\n
      \n
      [5]<\/div>\n
      Hochschule f\u00fcr Technik, Wirtschaft und Kultur Leipzig, \u201eMedien online nutzen\u201c. Zugegriffen: 14. Januar 2025. [Online]. Verf\u00fcgbar unter: https:\/\/bibliothek.htwk-leipzig.de\/ausleihe-und-nutzung\/medien-online-nutzen<\/a><\/div>\n<\/div>\n
      \n
      [6]<\/div>\n
      Shibboleth, \u201eShibboleth Concepts\u201c. Zugegriffen: 29. Oktober 2024. [Online]. Verf\u00fcgbar unter: https:\/\/shibboleth.atlassian.net\/wiki\/spaces\/CONCEPT\/overview<\/a><\/div>\n<\/div>\n
      \n
      [7]<\/div>\n
      DFN, \u201eDFN-AAIDokumentation Einf\u00fchrung\u201c. Zugegriffen: 24. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/doku.tid.dfn.de\/de:aai:about<\/a><\/div>\n<\/div>\n
      \n
      [8]<\/div>\n
      Shibboleth, \u201eService Provider – Application Model\u201c. Zugegriffen: 24. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/shibboleth.atlassian.net\/wiki\/spaces\/SP3\/pages\/2065334314\/ApplicationModel<\/a><\/div>\n<\/div>\n
      \n
      [9]<\/div>\n
      Shibboleth, \u201eService Provider – ProtectContent\u201c. Zugegriffen: 24. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/shibboleth.atlassian.net\/wiki\/spaces\/SP3\/pages\/2065335066\/ProtectContent<\/a><\/div>\n<\/div>\n
      \n
      [10]<\/div>\n
      Shibboleth, \u201eIdPDiscovery – Shibboleth Concepts\u201c. Zugegriffen: 17. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/shibboleth.atlassian.net\/wiki\/spaces\/CONCEPT\/pages\/928645263<\/a><\/div>\n<\/div>\n
      \n
      [11]<\/div>\n
      SWITCH, \u201eSimple Demo – SwitchAAI\u201c. Zugegriffen: 24. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/help.switch.ch\/aai\/demo\/simple\/<\/a><\/div>\n<\/div>\n
      \n
      [12]<\/div>\n
      SWITCH, \u201eExpert Demo – SWITCHaai\u201c. Zugegriffen: 24. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/help.switch.ch\/aai\/demo\/expert\/<\/a><\/div>\n<\/div>\n
      \n
      [13]<\/div>\n
      T. Michels, \u201eIdentity Management und Shibboleth: Ein \u00dcberblick\u201c.<\/div>\n<\/div>\n
      \n
      [14]<\/div>\n
      Shibboleth, \u201eFlowsAndConfig – Shibboleth Concepts\u201c. Zugegriffen: 6. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/shibboleth.atlassian.net\/wiki\/spaces\/CONCEPT\/pages\/928645290\/FlowsAndConfig<\/a><\/div>\n<\/div>\n
      \n
      [15]<\/div>\n
      Shibboleth, \u201eMembership\u201c. Zugegriffen: 17. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/www.shibboleth.net\/membership\/<\/a><\/div>\n<\/div>\n
      \n
      [16]<\/div>\n
      Shibboleth, \u201eConsortium Membership Fees\u201c. Zugegriffen: 17. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/www.shibboleth.net\/membership\/consortium-membership-fees\/<\/a><\/div>\n<\/div>\n
      \n
      [17]<\/div>\n
      Overt Software, \u201eAzure AD\/ADFS vs Shibboleth IDP\u201c. Zugegriffen: 17. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/www.overtsoftware.com\/azure-ad-adfs-vs-shibboleth-idp-which-is-better-for-your-organisation\/<\/a><\/div>\n<\/div>\n
      \n
      [18]<\/div>\n
      W. Sommergut, \u201eWas Sind Die Unterschiede Zwischen Active Directory Und Azure AD? | WindowsPro\u201c. Zugegriffen: 17. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/www.windowspro.de\/wolfgang-sommergut\/was-sind-unterschiede-zwischen-active-directory-azure-ad<\/a><\/div>\n<\/div>\n
      \n
      [19]<\/div>\n
      J. Chik, \u201eMicrosoft Entra Expands into Security Service Edge and Azure AD Becomes Microsoft Entra ID\u201c. Zugegriffen: 17. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/www.microsoft.com\/en-us\/security\/blog\/2023\/07\/11\/microsoft-entra-expands-into-security-service-edge-and-azure-ad-becomes-microsoft-entra-id\/<\/a><\/div>\n<\/div>\n
      \n
      [20]<\/div>\n
      CelesteDG, \u201eNew Name for Azure Active Directory – Microsoft Entra\u201c. Zugegriffen: 17. November 2024. [Online]. Verf\u00fcgbar unter: https:\/\/learn.microsoft.com\/en-us\/entra\/fundamentals\/new-name<\/a><\/div>\n<\/div>\n
      \n
      [21]<\/div>\n
      Okta, \u201eSecure Single Sign-On Solutions\u201c. Zugegriffen: 2. Januar 2025. [Online]. Verf\u00fcgbar unter: https:\/\/www.okta.com\/de-de\/products\/single-sign-on-customer-identity\/<\/a><\/div>\n<\/div>\n
      \n
      [22]<\/div>\n
      OneLogin, \u201eErweiterte Authentifizierung\u201c. Zugegriffen: 2. Januar 2025. [Online]. Verf\u00fcgbar unter: https:\/\/www.oneidentity.com\/<\/a><\/div>\n<\/div>\n
      \n
      [23]<\/div>\n
      Ping Identity, \u201eFunktionen der Ping Identity-Plattform\u201c. Zugegriffen: 2. Januar 2025. [Online]. Verf\u00fcgbar unter: https:\/\/www.pingidentity.com\/de\/platform\/capabilities.html<\/a><\/div>\n<\/div>\n
      \n
      [24]<\/div>\n
      Shibboleth, \u201eDevelopment Center – Project Roadmap\u201c. Zugegriffen: 12. Januar 2025. [Online]. Verf\u00fcgbar unter: https:\/\/shibboleth.atlassian.net\/wiki\/spaces\/DEV\/pages\/3503423489\/Project+Roadmap<\/a><\/div>\n<\/div>\n<\/div>\n
      \n
      \n
        \n
      1. https:\/\/raw.githubusercontent.com\/nicosrm\/24-bis-shibboleth\/refs\/heads\/main\/assets\/bis_bpmn.drawio.pdf<\/a>\u21a9\ufe0e<\/a><\/li>\n<\/ol>\n<\/section>\n","protected":false},"excerpt":{"rendered":"
        1 Einf\u00fchrung Heutzutage ist der Zugriff auf eine Vielzahl von Online-Diensten und -Ressourcen erforderlich. Vor allem in f\u00f6derierten Systemen sind<\/p>\n","protected":false},"author":177,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,3],"tags":[],"class_list":["post-3730","post","type-post","status-publish","format-standard","hentry","category-betriebliche-informationssysteme","category-lehrveranstaltungen"],"_links":{"self":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/users\/177"}],"replies":[{"embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/comments?post=3730"}],"version-history":[{"count":5,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3730\/revisions"}],"predecessor-version":[{"id":3886,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/posts\/3730\/revisions\/3886"}],"wp:attachment":[{"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/media?parent=3730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/categories?post=3730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/informatik.htwk-leipzig.de\/seminar\/wp-json\/wp\/v2\/tags?post=3730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}