Übersicht über die Baselinearchitektur

Microsoft spricht häufig mit Forschungsuniversitäten, die in Hybridumgebungen arbeiten, in denen Anwendungen entweder cloudbasiert oder lokal gehostet werden. In beiden Fällen können Anwendungen unterschiedliche Authentifizierungsprotokolle verwenden. In einigen Fällen erreichen diese Protokolle das Ende ihrer Lebensdauer oder bieten nicht das erforderliche Maß an Sicherheit.

Der Bedarf an unterschiedlichen Authentifizierungsprotokollen und Identitätsverwaltungsmechanismen (IdM) wird hauptsächlich durch Anwendungen bestimmt.

In Umgebungen von Forschungsuniversitäten werden IdM-Anforderungen häufig von Forschungs-Apps bestimmt. Eine Universität verwendet möglicherweise einen Verbundanbieter wie Shibboleth als primären Identitätsanbieter (IdP). Ist dies der Fall, wird Microsoft Entra ID häufig für den Verbund mit Shibboleth konfiguriert. Wenn Microsoft 365 Apps ebenfalls verwendet werden, können Sie mit der Microsoft Entra-ID die Integration konfigurieren.

Anwendungen, die an Forschungsuniversitäten verwendet werden, laufen in verschiedenen Teilen der gesamten IT-Umgebung:

• Forschungs- und multilaterale Verbundanwendungen werden über InCommon und eduGAIN zur Verfügung gestellt.

• Bibliotheksanwendungen ermöglichen den Zugriff auf elektronische Zeitschriften und andere Anbieter von E-Inhalten.

• Einige Anwendungen verwenden ältere Authentifizierungsprotokolle wie z. B. den zentralen Authentifizierungsdienst (Central Authentication Service), um einmaliges Anmelden zu aktivieren.

• Lernenden- und Lehrkräfteanwendungen verwenden häufig mehrere Authentifizierungsmechanismen. Einige sind beispielsweise in Shibboleth oder andere Verbundanbieter integriert, während andere in Microsoft Entra ID integriert sind.

• Microsoft 365-Anwendungen sind in Microsoft Entra ID integriert.

• Windows Server Active Directory wird möglicherweise verwendet und mit Microsoft Entra ID synchronisiert.

• Das Lightweight Directory Access Protocol (LDAP) wird an vielen Universitäten verwendet, die möglicherweise über ein externes LDAP-Verzeichnis oder eine Identitätsregistrierung verfügen. Diese Registrierungen werden häufig verwendet, um vertrauliche Attribute, Rollenhierarchieinformationen und sogar bestimmte Arten von Benutzern, z. B. Bewerber, zu speichern.

• Ein lokales Active Directory oder ein externes LDAP-Verzeichnis wird häufig verwendet, um die Anmeldung mit einzelnen Anmeldeinformationen für Nicht-Webanwendungen und verschiedene Nicht-Microsoft-Betriebssystemanmeldungen zu ermöglichen.

Herausforderungen der Baselinearchitektur

Baselinearchitekturen entwickeln sich häufig im Laufe der Zeit weiter, wodurch der Entwurf und die Fähigkeit zur Aktualisierung komplexer und starrer werden. Einige der Herausforderungen bei der Verwendung der Baselinearchitektur sind:

• Schwer zu reagieren auf neue Anforderungen: Wenn Sie eine komplexe Umgebung haben, ist es schwierig, sich schnell anzupassen und mit den neuesten Vorschriften und Anforderungen schritt zu halten. Wenn Sie beispielsweise Über Apps an vielen Standorten verfügen und diese Apps auf unterschiedliche Weise mit verschiedenen IDMs verbunden sind, müssen Sie entscheiden, wo sie mehrstufige Authentifizierungsdienste suchen und wie die mehrstufige Authentifizierung erzwungen wird.

  Die Hochschulbildung ist außerdem geprägt von einer fragmentierten Eigentümerschaft der Dienstleistungen. Mitarbeiter, die für wichtige Dienste wie Enterprise Resource Planning, Learning Management-Systeme, Fachbereichs- und Abteilungslösungen verantwortlich sind, könnten sich gegen Änderungen der von ihnen betriebenen Systeme wehren.

• Es können nicht alle Microsoft 365-Funktionen für alle Apps genutzt werden (z. B. Intune, bedingter Zugriff, kennwortlos usw.): Viele Universitäten möchten zur Cloud wechseln und ihre bisherigen Investitionen in Microsoft Entra ID nutzen. Mit einem anderen Verbundanbieter als primärem IdP können Universitäten jedoch nicht alle Microsoft 365-Funktionen für den Rest ihrer Apps nutzen.

• Komplexität einer Lösung: Es gibt viele Zu verwaltende Komponenten. Einige Komponenten befinden sich in der Cloud, andere sind lokal oder in IaaS-Instanzen (Infrastructure-as-a-Service). Apps werden an vielen Stellen betrieben. Aus der Perspektive der Benutzer kann dies zu einer unzusammenhängenden Erfahrung führen. Beispielsweise sehen Benutzer manchmal eine Shibboleth- und ein anderes Mal eine Microsoft Entra-Anmeldeseite.

Wir stellen drei Lösungen vor, die diese Herausforderungen meistern und gleichzeitig die folgenden Anforderungen erfüllen:

• Teilnahme an multilateralen Verbunden wie InCommon und eduGAIN

• Möglichkeit, alle Arten von Apps zu unterstützen (sogar solche, die Legacy-Protokolle erfordern)

• Unterstützung externer Verzeichnisse und Attributspeicher

Diese drei Lösungen werden in der Reihenfolge von am meisten bis am wenigsten bevorzugt dargestellt. Jede erfüllt die Anforderungen, erfordert aber Kompromissentscheidungen, die in einer komplexen Architektur zu erwarten sind. Wählen Sie basierend auf Ihren Anforderungen und Ihrem Ausgangspunkt die Lösung aus, die am besten zu Ihrer Umgebung passt. Wir stellen auch eine Entscheidungsstruktur bereit, die Ihnen bei dieser Entscheidung helfen kann.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln zu multilateralen Verbunden:

Multilateraler Verbund – Einführung

Multilateraler Verbund, Lösung 1: Microsoft Entra ID mit Cirrus Bridge

Multilaterale Verbundlösung 2: Microsoft Entra ID mit Shibboleth als SAML-Proxy (Security Assertion Markup Language)

Multilateraler Verbund, Lösung 3: Microsoft Entra ID mit AD FS und Shibboleth

Entscheidungsstruktur eines multilateralen Verbunds