Integration von Okta mit der multilateralen InCommon-Föderation

Einführung in die Integration von Okta und InCommon

Für Hochschul- und Partner-Forschungseinrichtungen ist die Nutzung des InCommon-Frameworks unerlässlich. Traditionell unterstützt Okta das von InCommon verwendete bilaterale Föderationsmodell nicht – es gibt jedoch eine Lösung. Dieser Leitfaden bietet einen technischen Überblick und ein Architekturmuster für die Integration eines Okta-Tenants mit einem multilateralen Föderationsmodell wie InCommon oder eduGAIN, sodass Sie entweder als Identity-Anbieter (IdP) oder als Service Provider (SP) an der InCommon-Föderation teilnehmen können.

Zentrale Integrationsanwendungsfälle

Dieser Leitfaden richtet sich an Identity-Architekt:innen in Institutionen, die Okta als primäre Identity-Plattform nutzen, aber über InCommon Interoperabilität mit der breiteren Forschungs- und Bildungs-Community (R&E) benötigen – entweder als InCommon-IDP oder als InCommon-SP.

Wir werden zwei Hauptszenarien untersuchen: 

1. Okta als InCommon-IdP: Authentifizierten Student:innen an Einrichtungen mit Okta Zugriff auf InCommon-Ressourcen von Drittanbietern gewähren
2. Okta als InCommon-SP: Institutionelle Anwendungen mit Okta absichern und gleichzeitig der breiteren InCommon-Community den Zugriff darauf ermöglichen

Wir zeigen zwar Okta auf beiden Seiten der Transaktion, die Modelle lassen sich aber auch auf andere IAM-Unternehmenslösungen (Identity and Access Management) anwenden.

Kontextualisieren der Föderationsterminologie: IdP und SP im Vergleich

Die Verwendung der Begriffe Identity-Anbieter (IdP) und Service Provider (SP) ist zwar angemessen, kann jedoch kontextabhängig sein. 

• Im Architekturmuster 1 (Okta als InCommon-IdP): Okta ist der IdP für Anwendungen der Universität und der IdP für den Föderationsadapter Cirrus Bridge. Der Adapter fungiert als SP für Okta. In diesem Anwendungsfall fungiert Cirrus Bridge jedoch auch als InCommon-IdP, wodurch Student:innen und Dozent:innen SSO für Ressourcen von Drittanbietern erhalten, die als InCommon-SPs fungieren. In diesem Fall ist Okta ein IdP, Cirrus Bridge ist sowohl ein SP als auch ein IdP und die Drittanbieter-Ressourcen sind SPs.
• In Architekturmuster 2 (Okta als InCommon-SP): Okta ist der IdP für die Anwendungen der Forschungseinrichtung, die sowohl von Student:innen als auch Dozent:innen der Forschungseinrichtung genutzt werden. Gleichzeitig gewährt Okta externen InCommon-Benutzer:innen Zugang zur Anwendung. Für externe InCommon-Benutzer:innen ist Okta ein SP und der Cirrus Proxy der IdP. Der Cirrus Proxy ist jedoch ein InCommon-SP.

Bilaterales und multilaterales Föderationsmodell im Vergleich

Das bilaterale Föderationsmodell von Okta

Okta ist der führende IAM-Service auf dem Markt. Er wurde entwickelt, um Zugriff auf Security Assertion Markup Language (SAML), OpenID Connect (OIDC) und Header-basierte On-Premise-Anwendungen bereitzustellen. Viele Hochschul- und Forschungseinrichtungen nutzen Okta, und in einigen Fällen kann eine einzelne Einrichtung sowohl als IdP als auch als SP fungieren. Die Okta-Föderationsarchitektur basiert auf einer einzigartigen Point-to-Point-Vertrauensbeziehung, die zwischen einem einzelnen IdP und einem einzelnen SP konfiguriert ist. 

Dieser Point-to-Point-Ansatz wird als bilaterale Föderation bezeichnet und ist das Standardmodell, das von allen großen kommerziellen IAM-Anbietern verwendet wird. Dieses Modell bietet granulare Kontrolle und ist Standard für Unternehmens- und kommerzielle Anwendungen.

Das multilaterale Föderationsmodell von InCommon

Im Gegensatz zum bilateralem Ansatz von Okta, der für jede Föderationspartnerschaft eine spezifische, vorkonfigurierte Verbindung erfordert, arbeitet InCommon mit einem multilateralen Föderationsmodell. Dabei handelt es sich um ein N-zu-N-Vertrauensframework, mit dem Tausende teilnehmende Institutionen zusammenarbeiten können, ohne individuelle bilaterale Beziehungen eingehen zu müssen. 

Ermöglicht wird dies durch ein zentrales Vertrauensregister, das einen Metadatenservice hostet, der die SAML-Metadaten für alle Mitglieder enthält. InCommon stellt dieses Vertrauensregister entweder als „Legacy SAML Metadata Aggregate“ oder als „Metadata Query (MDQ) Service“ bereit. Ein SP kann der gesamten InCommon-Föderation vertrauen und durch die Nutzung dieser Metadaten die Authentifizierung von jedem registrierten IdP akzeptieren. 

Obwohl die multilaterale Föderation und der Metadaten-Dienst die größten Unterscheidungsmerkmale zwischen einem kommerziellen Modell und dem R&E-Community-Modell darstellen, sind dies nicht die einzigen Unterschiede. InCommon definiert auch standardisierte Authentifizierungs- und Attributanforderungen:

• Angabe spezifischer Assertions für die Multi-Faktor-Authentifizierung (MFA) gemäß dem REFEDS MFA-Profil 
• Bereitstellung standardisierter Benutzerattribut-Pakete auf Basis vorgegebener Zustimmungs-Frameworks

Da Okta die erforderliche dynamische Verarbeitung von Metadaten für eine multilaterale Föderation nicht von sich aus unterstützt, müssen Sie einen Föderationsadapter als Vermittler verwenden.

Föderationsadapter-Architektur als Integrationsbedingung 

Um die Lücke zwischen dem bilateralen Modell von Okta und dem multilateralen Modell von InCommon zu schließen, müssen Sie sowohl auf der IdP- als auch auf der SP-Seite der Verbindung einen speziellen Adapter verwenden.  

• Als InCommon-IdP (Muster 1): Dieser Adapter verarbeitet den InCommon-Metadaten-Feed und kommuniziert mit Okta über eine bilaterale Standard-SAML-Verbindung. 
• Als InCommon-SP (Muster 2): Dieser Adapter fordert die Benutzer:innen auf, ihre Heimatinstitution anzugeben, ruft die Metadaten für diese Institution ab, generiert die korrekte Authentifizierungsanfrage für diese Institution und verarbeitet und validiert anschließend die eingehende SAML-Assertion. 

Auswahl eines Adapters: Shibboleth vs. Cirrus Identity

Die R&E-Community erkennt allgemein zwei primäre Adapterlösungen an: Cirrus Identity und Shibboleth.

• Cirrus Identity: Eine kommerzielle, SaaS-basierte Lösung, die speziell für diesen Zweck entwickelt wurde. Sie vereinfacht die Bereitstellung und Verwaltung. Cirrus bietet zwei verschiedene Lösungen: Cirrus Bridge, verwendet im Anwendungsfall 1 (InCommon-IDP) und Cirrus Proxy, verwendet im Anwendungsfall 2 (InCommon-SP). Cirrus stellt eine detaillierte Dokumentation für diese Integrationen als primäre Referenz bereit:

  • Cirrus Bridge-Dokumentation

  • Cirrus Proxy-Dokumentation

  • Okta-spezifischer Einrichtungsleitfaden für Cirrus Bridge

  • Okta-Integration mit Cirrus

• Shibboleth: Ein in der R&E-Community weit verbreitetes Open-Source-Softwareprojekt. Sie können es on-premise oder in einer Private Cloud bereitstellen. Die Shibboleth-IdP-Software fungiert als Adapterkomponente. Zu den wichtigsten Ressourcen zählen: 

  • Die Homepage des Shibboleth-Projekts

  • Shibboleth-Dokumentation für Identity-Anbieter

  • Shibboleth-Leitfaden von InCommon

Sowohl Cirrus Identity als auch Shibboleth funktionieren, wenn Okta und ein InCommon-Adapter verwendet werden. Die Wahl Ihrer Lösung richtet sich nach Ihren organisatorischen Präferenzen.

Architekturmuster 1: Okta als InCommon-Identity-Anbieter

In diesem Szenario nutzt eine Universität Okta für ihre Student:innen, Dozent:innen und Mitarbeiter:innen. Die Universität speist Okta aus ihren Studenten- und/oder Personalsystemen und bietet Provisionierung, Single Sign-On (SSO) und MFA für verschiedene Anwendungen, darunter Google Workspace, Microsoft Entra ID, Canvas und Blackboard. Okta provisioniert auch Benutzer:innen in Active Directory. Ziel ist es, Universitätsbenutzer:innen den Zugriff auf externe InCommon-föderierte Dienste wie wissenschaftliche Fachzeitschriften, Bibliotheksdienste von Drittanbietern und NSF-Anwendungen zu ermöglichen. 

Architektur-Setup

1. Die Universität registriert Cirrus Bridge als ihren offiziellen IdP im InCommon-Vertrauensregister.
2. Cirrus Bridge ist so konfiguriert, dass es auf den Upstream-Okta-Tenant der Universität als seinen maßgeblichen SAML-IdP verweist.
3. Okta übernimmt die primäre Benutzerauthentifizierung, die Durchsetzung von MFA und die zentrale Lebenszyklusverwaltung für Identitäten.

So funktionieren Authentifizierungsabläufe für Okta als IdP

Für einen IdP-initiierten Flow beginnen Sie mit dem optionalen Login: 

1. Nicht authentifizierte Benutzer:innen melden sich direkt im Okta-Endbenutzer-Dashboard an.
2. Die Benutzer:innen klicken auf einen Link zur externen InCommon-Zielanwendung.
3. Okta generiert eine SAML-Assertion und sendet sie an Cirrus Bridge.
4. Cirrus Bridge übersetzt die Assertion in ein multilaterales Format und leitet sie an die Zielressource weiter.

Verwenden Sie bei einem SP-initiierten Flow nicht den optionalen Login. Melden Sie sich erst an, wenn es erforderlich ist:

1. Benutzer:innen navigieren direkt zur InCommon-Zielressource des Drittanbieters.
2. Die Ressource leitet die Benutzer:innen mithilfe des InCommon-Metadaten-Lookups zu Cirrus Bridge um.
3. Cirrus Bridge leitet Benutzer:innen zur Überprüfung der primären Anmeldedaten an Okta weiter.
4. Nach erfolgreicher Authentifizierung stellt Okta ein Token für Cirrus Bridge aus, die Benutzer:innen zurück zur Ressource weiterleiten.

Architekturmuster 2: Okta als InCommon-Service-Provider

In diesem Szenario nutzt eine Forschungseinrichtung Okta, um den Zugriff auf ihre Anwendungen abzusichern. Anstatt für alle Benutzer:innen separate Anmeldedaten auszustellen, möchte die Einrichtung Benutzer:innen aus der InCommon-Föderation akzeptieren. Dadurch können diese Benutzer:innen mit ihren eigenen Universitätsanmeldedaten auf die Anwendungen der Forschungseinrichtung zugreifen, ohne einen neuen Account zu erstellen. Die Forschungseinrichtung möchte ihren Forschungsmitarbeiter:innen auch direkte Logins ermöglichen.

Architektur-Setup

1. Cirrus Proxy ist als InCommon SP im multilateralen Register registriert.
2. Okta ist so konfiguriert, dass es mithilfe eines bilateralen SAML-Setups Cirrus Proxy als eingehendem IdP vertraut.
3. Die Zielanwendungen bleiben direkt in Okta als Standard-SSO für Anwendungen integriert.

Identity-Erkennung und Authentifizierungsabläufe

Eine wichtiger Schritt bei der Aktivierung des InCommon-Zugriffs auf Okta besteht darin, sicherzustellen, dass sich Benutzer:innen über die richtigen Pfade anmelden.

Direkter Anmeldevorgang für interne Mitarbeiter:innen

1. Interne Forschungsmitarbeiter:innen greifen direkt über ihren Okta-Account auf die Anwendung zu.
2. Okta authentifiziert interne Benutzer:innen direkt, ohne die externe Erkennungs-Pipeline aufzurufen.

SP-initiierter Anmeldevorgang für externe InCommon-Benutzer:innen

Externe Benutzer:innen navigieren direkt oder vom Dashboard der Heimatuniversität zur Anwendung. An dieser Stelle können Benutzer:innen mit einem der beiden folgenden Ansätze zur Eingabe ihrer Anmeldedaten aufgefordert werden. Der Ansatz wird auf den Anforderungen der Institution basieren.  

1. „User > Access Resource > Okta“ (Benutzer:in > Zugriff auf Ressource > Okta) zeigt das Anmelde-Widget mit einem Link zum Erkennungsbildschirm auf dem Cirrus Proxy an: 

   • Benutzer:innen können sich direkt über das Okta-Widget anmelden oder „Login with InCommon“ (Mit InCommon anmelden) auswählen, um zum Bildschirm für die IdP-Erkennung auf dem Cirrus Proxy zu gelangen.

2. „User > Access Resource > Cirrus Proxy“ (Benutzer > Zugriff auf Ressource > Cirrus Proxy) zeigt eine Login-Seite mit einem Link zum Okta-Widget an:

   • Den Benutzer:innen wird sofort der Bildschirm zur IdP-Erkennung des Cirrus-Proxys angezeigt.

   • Mitarbeiter:innen können sich direkt über das Okta-Widget anmelden.

In diesem Beispiel entscheiden sich Benutzer:innen dafür, InCommon für die Authentifizierung zu verwenden.

1. Die Benutzer:innen werden zur Cirrus-Proxy-Erkennungsoberfläche weitergeleitet, um die eigene Heimatinstitution auszuwählen.
2. Cirrus Proxy fragt den MDQ-Dienst ab, ruft die SAML-Metadaten der Heimatinstitution ab und leitet die Benutzer:innen zur lokalen Login-Seite ihrer Universität weiter.
3. Nach erfolgreicher Anmeldung bei der Heimatuniversität sendet der Heimat-IdP eine SAML-Assertion an Cirrus Proxy.
4. Cirrus Proxy validiert die Assertion und sendet eine formatierte Assertion an Okta. Daraufhin wird den Benutzer:innen Zugriff auf die Anwendung gewährt.

Optimieren der multilateralen Föderation mit Okta

Die Integration von Okta in multilaterale Föderationen muss nicht komplex sein. Unsere Cirrus Federation Bridge-Integration ermöglicht die Authentifizierung und Provisionierung von Endbenutzer:innen bei Hochschul- und Forschungseinrichtungen. 

Im Gegensatz zu anderen Identity-Management-Toolkits müssen Sie bei Okta keine Zeit und Ressourcen aufwenden, um Web-Anwendungen manuell mit Ihren Benutzer-Directories zu verbinden. Stattdessen integrieren wir Anwendungen direkt in unseren Dienst, sodass Sie sie einfach für Ihre Benutzer:innen bereitstellen können.

Laden Sie das Whitepaper zu Anwendungsintegrationen herunter, um mehr darüber zu erfahren, wie wir Anwendungsverbindungen in Ihrem gesamten Ökosystem vereinfachen.