Domino 12 – Worauf wir uns freuen können (Teil 2)

Vorab der notwendige Disclaimer

Das Domino 12 Release steht vor der Tür und die Beta 3 wird intensiv von uns und auch unseren Kunden und Partnern bereits eingesetzt und auf Herz und Nieren geprüft. Normalerweise sollten nun keine Features mehr aus dieser Version entfallen oder grundsätzlich anders ausgestaltet sein. Dennoch hiermit mein Hinweis: Dieser Artikel bezieht sich auf eine zukünftige Version von Domino 12 – dementsprechend können die Schilderungen hier von der finalen Version noch abweichen. Dafür übernehmen HCL und ich keine Garantie.

Ein weiterer Disclaimer: Ich bin kein Techniker. Ich habe mich zu diesem Thema informiert – bin aber kein Experte, wie unsere Technical Advisors. Legen Sie also bitte nicht jedes Wort auf die Goldwaage und wenn Sie noch tiefer einsteigen wollen, dann haben wir viele Spezialisten hier, die Ihnen dabei helfen können. Jedoch finde ich, der durchaus auch schon mal Server administrieren musste und zudem programmieren konnte, einfach sehr cool zu sehen, was wir hier als HCL abliefern.

Mit synchronisierten Passwörtern sicher arbeiten

Sie kennen sicherlich den Stress an einem Montagmorgen: Erstmal alle Anwendungen hochfahren und überall anmelden. Viele Anwendungen verwenden dazu mittlerweile eine Anmeldung mit dem Windows-Kennwort, mit dem man sich ja sowieso am PC anmelden muss oder verschiedene andere, zentrale Verzeichnisse.

Hierfür fallen mir verschiedene Verfahren ein:

• Anmeldung über Single-Sign-On (SSO) mit einer Web-Anmeldung über OAUTH2 und ähnliche Protokolle/Methoden wie OpenID
• Anmeldung mit einem serverseitigen Passwortabgleich, dem sogenannten Identity Provider (ähnlich dem SSO, nur eben zwischen Servern ausgehandelt)
• Anmeldungen in verschiedenen Systemen mit dem gleichen Passwort, welches im Hintergrund synchronisiert wird

Alle diese Mittel erfüllen ihren Zweck und haben Vor- und Nachteile. Da der HCL Domino Server alle davon unterstützt, haben wir hier die optimale Plattform für eine Integration – auch zum Wohle der Anwender/-innen: Niemand muss sich nun ein zusätzliches Passwort merken, wenn es doch eine einzige vertrauenswürdige Quelle im Unternehmen gibt.

Single-Sign-On mit der Web-Anmeldung

Das kennen wir wohl alle: Die Anmeldung im Web-Browser, bei der beim ersten Mal an einer zentralen Stelle Passwort und gegebenenfalls noch der zweite Faktor abgefragt wird. Jede Anwendung, die nun die gleiche Anmeldung nutzt, läuft über diese Anmeldeseite, die im Idealfall merkt, dass man schon dort war und die User gleich wieder angemeldet zurückführt.

Da erkennt man schon, wo aber die Probleme liegen:

• Üblicherweise funktioniert das nur im Browser – auf mobilen Endgeräten oder in anderen klassischen Anwendungen öffnet sich dann eventuell etwas unbeholfen ein Browser-Fenster für die Anmeldung.
• Das Ziel nach der Anmeldung muss wieder eine Webseite sein. Wenn also eine klassische Anwendung genutzt wird (beispielsweise eine lokale Notes-Datenbank), dann funktioniert das nicht wirklich gut.
• Dieser Anmeldedienst kennt ALLE diese Anwendungen, die auf ihn zurückgreifen und das Nutzungsverhalten ALLER User, die sich darüber anmelden.

Der letztere Punkt wird weniger problematisch, wenn man selbst den SSO-Dienst betreibt. Wenn man dies aber externen Anbietern überlässt, sollte man sich der Konsequenzen (auch und besonders im Sinne des Datenschutzes) bewusst sein.

Anmeldung mit serverseitigem Passwortabgleich

Hier hat jede Anwendung einen eigenen Anmeldedialog, der auch immer angezeigt wird. Jedoch erfolgt die Passwort-Prüfung nicht in der jeweiligen Applikation, sondern diese fragt bei einem zentralen Server nach, ob dieser etwas mit der eingegebenen User-/Passwort-Kombination anfangen kann. Da diese Abfrage zwischen den Servern erfolgt, bekommt die Person, die sich anmelden will, nichts davon mit. Zudem ist diese Variante auch für klassische und mobile Apps geeignet.

Ein gutes Beispiel hierfür sind viele WLAN-Anmeldeverfahren (egal ob mit Zertifikaten oder tatsächlich mit User/Passwort-Anmeldung). Hierbei fragt der Access Point oft über Kerberos oder ähnliche Methoden bei einem zentralen Verzeichnisserver an, ob sich diese Person im WLAN anmelden darf.

Auch hier besteht natürlich die Gefahr, dass der zentrale Dienst ebenfalls jedes Mal von einer Anmeldung an den verbundenen Diensten erfährt. Allerdings sind gerade die Legacy-Anwendungsfälle üblicherweise In-House – und damit unter der Kontrolle der eigenen IT.

Synchronisation der Passwörter mit Domino 12

Also gut – kommen wir nun zur letzten Variante, die ich heute betrachten will – und die mit Domino 12 eine weitere Option im Arsenal der Admins wird: Die Passwort-Synchronisation mit Active Directory. Warum sollte man diese nutzen wollen? Ein guter Grund ist auf jeden Fall, dass sie auch ohne einen SAML Identity Provider funktioniert – also anders als im ersten SSO-Verfahren keinen zusätzlichen Dienst oder den Browser erfordert. Zudem erfährt auf diese Art der Betreiber des Active Directories nichts über das Nutzungsverhalten anderer Anwendungen, da sich diese nur gegen den eigenen Passwortspeicher – in unserem Fall das Domino Namensverzeichnis (names.nsf) und den ID-Vault ausweisen müssen. In der in der Beta 3 vorgestellten Fassung dieser Funktion zeigen meine Kolleginnen und Kollegen, wie schnell und einfach diese Synchronisation verläuft: Egal ob ein Admin (beispielsweise in der Server-Konsole des Active Directory Servers) oder ein User (z.B. im Passwort-ändern-Dialog seines Windows-PCs) die Passwort-Änderung anstößt, das neue Passwort wird fast augenblicklich sowohl in das Personendokument des Adressbuchs als auch im ID Vault eingetragen. Mit diesem Transfer ist dann auch umgehend die Anmeldung mit dem neuen Passwort sowohl in Webanwendungen als auch in den übrigen Domino-Datenbanken möglich.

Die Passwortsynchronisation wird damit unterstützt für:

• Registrierte HCL Notes-, HCL Nomad-, HCL Verse- und HCL iNotes-Benutzer, die mit HTTP-Passwörtern oder Notes-IDs auf Domino-Server zugreifen.
• HCL Traveler-Benutzer, die auf ihre Mails über den Webbrowser auf ihren mobilen Geräten zugreifen.
• Web-Benutzer, die nicht in Domino registriert sind, aber Personendokumente im Domino-Verzeichnis haben und mit HTTP-Passwörtern auf Domino-Webanwendungen zugreifen.

Damit sind wohl alle Anwendungsfälle in einer modernen Domino-Umgebung abgedeckt. Wer mehr über die Einrichtung erfahren möchte, findet die nötigen Informationen in der bereits verfügbaren Domino 12 Dokumentation.

Ich freue mich auf das Launch Event!

Ich finde, dass unsere Kolleginnen und Kollegen aus der Entwicklungsabteilung einen wirklich guten Job machen. Wie oft erzählen mir Kunden, dass ihre größte Sorge bei der Digitalisierung die mögliche Überforderung ihrer Mitarbeitenden durch immer neue Tools – und eben durch immer neue Anmeldungen – sei. Hier haben wir wieder einmal mit HCL Domino die Hemmschwelle so niedrig wie möglich gesetzt: Auch wer kein SSO mit einer Web-Anmeldung nutzen kann oder will, kann dennoch den leidigen Umgang mit einer Vielzahl von Kennwörtern vermeiden. Mit dieser positiven Vorfreude auf Domino 12 (übrigens ist die Registrierung zum Launch-Event noch immer offen) entlasse ich Sie in eine hoffentlich erfolgreiche Woche. Bleiben Sie gesund,

Ihr
Tom Zeizel
^{Associate Vice President & Head of HCL Software DACH}