Jeden Tag verbinden sich Menschen, IT-Systeme und zunehmend auch Produkte mit Web-Anwendungen, die auf einem Server oder in der Cloud gehostet werden. Herkömmliche Login- und Single-Sign-on-Verfahren reichen hier nicht mehr aus.
Passworte allein gelten als zu unsicher. Sicherheitsrichtlinien verlangen konzernweite Authentifizierungsverfahren, Compliance-Vorgaben die bessere Dokumentation von Benutzeridentifikation und ihrer Aktionen. Und die neue EU-Datenschutzverordnung DSGVO fordert den restriktiven Umgang mit personenbezogenen Daten.
Zudem werden Systemnutzer mobiler und wechseln Endgeräte und Arbeitsorte. Virtuelle Organisationen, kurzfristige Zusammenarbeit und Kooperationen machen es für Unternehmen immer schwieriger zu bestimmen, wer (oder was) zu einem bestimmten Zeitpunkt berechtigt ist eine Anwendung zu nutzen.
Diese Themen treiben die Entwicklung neuer, verbesserter Authentifizierungsverfahren voran.
Identitätsprüfung als zentraler Service
„Wer bist du und was darfst du?“ lautet die Fragestellung, die im Rahmen der Anmeldung zu klären ist. Die Identität von Personen, Software-Agenten oder IoT-Devices wird dazu mit einer Berechtigung verknüpft, die systemseitig aus Rollen, Gruppen, Rechteprofilen und ähnlichem abgeleitet wird. Dabei gilt, zum Beispiel für eine Produktionsfreigabe: je gewichtiger die Berechtigung, desto strenger die Regeln für die sichere Feststellung der Identität.
Heute wird das Identitätsmanagement oft an externe Anbieter ausgelagert. So konzentrieren sich viele Apps auf die Anwendungslogik und überlassen die Benutzerverwaltung anderen. Im Consumer-Bereich sind dies vor allem Facebook, Google & Co., das Business-Umfeld dominieren Lösungen wie AccessManager von NetIQ (ehemals Novell), Microsoft Active Directory oder auch Cloud-Systeme wie MS Azure und andere.
Dieses Identity-as-a-Service Konzept (IDaaS) bietet Unternehmen mit komplexen IT-Landschaften viele Vorteile. Compliance-Vorgaben, beispielsweise eine Multi-Faktor-Authentifizierung mit Chipkarten, lassen sich zentral umsetzen, statt aufwendig für jede einzelne Anwendung. Die Daten der Benutzer werden an einer Stelle verwaltet und je nach Integrationsgrad auch ihre Berechtigungen in den einzelnen Systemen. Sicherheitsthemen wie die Verschlüsselung oder das Patch-Management werden fokussiert und mit der nötigen Kompetenz behandelt, oft sogar mit entsprechenden Zertifizierungen.
OpenID Connect
Single Sign-on (SSO) und eine zentrale Benutzerverwaltung über LDAP-Verzeichnisdienste sind nichts Neues für Unternehmen. Doch haben die älteren Verfahren gravierende Nachteile in der komplexen und dynamischen Umgebung von Hybrid-Clouds und mobilen Endgeräten.
OpenID Connect hingegen berücksichtigt die Notwendigkeit feingranularer Zugriffsmethoden und Privacy-by-Design, wie sie zum Beispiel die DSGVO fordert, und ist – auch von seiner Benutzerschnittstelle her - auf die Verwendung mit Webbrowser-basierten Systemen zugeschnitten. Das Protokoll baut auf dem bewährten OAuth2 Autorisierungskonzept auf und ergänzt dieses um die notwendigen Komponenten für eine Authentifizierung.
Im Unterschied zu älteren Verfahren kommuniziert der Benutzer dabei direkt mit dem Identitätsprovider. Das hat mehrere Vorteile: Eine Anwendung kann keine Zugangsdaten verlieren, weil sie diese nicht sieht. Zusätzliche Schulungen entfallen, da Benutzer sich wie gewohnt am Firmenportal oder bei einem anderen Identitätsprovider anmelden. Ein Portal kann auch SSO anbieten, solange die letzte Authentifizierung des Benutzers noch gültig ist und er nicht explizit zu einer erneuten Anmeldung aufgefordert wird.
Implementierung in CONTACT Elements
CONTACT Software stellt Unternehmen mit seiner Technologieplattform Elements drei Optionen für die Nutzung von OpenID Connect bereit.
Client-Anwendung
Unternehmen nutzen einen Client, der sich in eine OpenID Connect Infrastruktur einbindet und Authentifizierungsdienste von einem externen Identitätsprovider bezieht. So kann sich ein Benutzer beispielsweise über ein Login bei einer Microsoft Azure Cloud auch bei CIM Database PLM oder Project Office anmelden.
Dieses Modell entspricht weitgehend dem klassischen auf Kerberos und LDAP basierten Anmeldeverfahren, nur mit den neuen Möglichkeiten von OpenID Connect in einem für Cloud und Web-basierte Dienste angepassten Prozess.
Identitätsprovider
CONTACT Elements wird selbst zum Identitätsprovider für alle Lösungen, die OpenID Connect beherrschen. Eine On-Premise laufende Web-Anwendung wie beispielsweise GitLab nutzt diesen zentralen Service dann für die Authentifizierung, aber nicht für weitere Funktionen.
Diese Option ist für vor allem in kleineren Installationen interessant, wo CONTACT Elements bereits Benutzerdaten, Passworte und Berechtigungen verwaltet. Unternehmen können die Anmeldung bei anderen In-House Anwendungen an unsere Plattform delegieren und ersparen sich den aufwendigen Aufbau eines eigenen OpenID Connect Providers.
Autorisierungssystem
Die dritte Option unserer Implementierung von OpenID Connect betrifft die „Maschine-zu-Maschine-Kommunikation“. Hiermit kann ein Benutzer externen Anwendungen den Zugriff auf die REST-Schnittstellen in CONTACT Elements gewähren. Dadurch können andere Systeme oder Dienste via Webbrowser integriert werden, die im Auftrag und Namen des Benutzers bestimmte Aktionen in unseren Softwarelösungen ausführen.
Nur zwei Beispiele aus einer Vielzahl von möglichen Szenarien:
- Das Abschließen einer Codeänderung in GitLab stößt automatisch einen Statuswechsel für eine zugehörige Aufgabe in CIM Database PLM an.
- Ein spezialisiertes Tool analysiert die neu eingestellten Dokumente eines Projektmanagers, erstellt automatisch eine Zusammenfassung und legt diese wiederum in der zentralen Datenbank ab, ohne dass der Anwender dazu online sein muss.
Alle, die mehr über die Möglichkeiten und Funktionsweise von OpenID Connect wissen möchten, finden unten weiterführende Links. Kunden und Partner haben zudem die Option, sich mit unseren Sicherheitsexperten auszutauschen.
