Wie die Sicherheit im OnTime Gruppenkalender funktioniert

Bitte beachten Sie: Die folgenden Informationen beziehen sich auf den HTTP-basierten Zugriff auf die OnTime Gruppenkalender API für OnTime Gruppenkalender Web, Mobile und Social. Dies betrifft auch Notes und Team-At-A-Glance, wenn diese für den HTTP-Zugriff konfiguriert sind. Wenn für die letztgenannten beiden Clients der native IBM Notes API (NRPC)-Zugriff verwendet wird, wird kein OnTime Access Token verwendet.

Die Authentifizierung der Benutzer erfolgt ausschließlich über die OnTime Gruppenkalender API (der “Service”, der die Daten für die OnTime Gruppenkalender Benutzeroberflächen wie Web, Mobile, Notes usw. bereitstellt) mithilfe eines OnTime Access Tokens. Ein OnTime Access Token ist ein verschlüsseltes Text-Token, das den Benutzer identifiziert und einen Zeitpunkt enthält, an dem es abläuft (neben anderen Informationen). Um ein OnTime Access Token zu erhalten, muss der Benutzer bei IBM Domino auf die von der Organisation geforderte Weise authentifiziert sein, z. B. Basic Authentication, formularbasierte Authentifizierung (mit LtpaToken), zertifikatsbasierte Authentifizierung usw. Sobald ein OnTime Access Token erhalten wurde, wird es bei nachfolgenden Anfragen an die OnTime Gruppenkalender API verwendet und identifiziert den Benutzer gegenüber der OnTime Gruppenkalender API. Ein ausgestelltes OnTime Access Token ist bis zu seinem Ablauf gültig. Die Gültigkeitsdauer kann im/in den OnTime Gruppenkalender Server-Dokument(en) festgelegt werden und auf eine Dauer in Stunden eingestellt werden. Die OnTime Gruppenkalender API stellt bei jeder Anfrage ein neues OnTime Access Token aus, daher sollte die im/in den OnTime Gruppenkalender Server-Dokument(en) festgelegte Ablaufzeit als “Leerlaufzeit zwischen Anfragen” betrachtet werden.

Bitte beachten Sie: In der OnTime-Gruppenkalender-Konfigurationsdatenbank wird die Leerlaufzeit des OnTime Access Token als "HTTP Token Timeout" bezeichnet.

Sobald ein OnTime Gruppenkalender-Client einen OnTime Access Token erhält, wird dieser vom Client zwischengespeichert (für Mobile und Web wird er in einem Browser-Cookie gespeichert) und bei nachfolgenden Anfragen an die API verwendet. Dies bedeutet, dass ein Benutzer auf OnTime Gruppenkalender Web oder OnTime Gruppenkalender Mobile zugreifen kann, ohne sich erneut bei IBM Domino authentifizieren zu müssen, wenn ein gültiger OnTime Access Token verfügbar ist. Es bedeutet auch, dass eine angemessene Leerlaufzeit festgelegt werden sollte, die der Sicherheitsrichtlinie des Unternehmens entspricht. Wenn die Sicherheitsrichtlinie dies beispielsweise zulässt, ermöglicht eine Leerlaufzeit von 24 Stunden einem Benutzer, OnTime Gruppenkalender Mobile oder Web während des Tages zu nutzen und den Client am nächsten Tag wieder zu öffnen, ohne sich erneut bei IBM Domino authentifizieren zu müssen, da der OnTime Access Token noch gültig ist.

Daraus ergibt sich, dass alle API-Anfragen nach Erhalt eines OnTime Access Tokens aus IBM Domino-Sicht unauthentifiziert (“anonym”) sein können. Dies stellt keine Sicherheitslücke dar, sondern beruht lediglich darauf, dass Nicht-Token-Anfragen ausschließlich über den OnTime Access Token authentifiziert werden. Dies bedeutet auch, dass der IBM Domino HTTP-Server anonyme Anfragen zulassen muss, unabhängig davon, ob diese über HTTP oder HTTPS erfolgen.

Bitte beachten Sie, dass ein OnTime Access Token aus der OnTime Gruppenkalender-Konfigurationsdatenbank widerrufen werden kann. Das bedeutet, dass, selbst wenn ein Benutzer ein OnTime Access Token erhalten hat, das ein Jahr in der Zukunft gültig ist, der Administrator es widerrufen kann, wodurch der Benutzer sich erneut authentifizieren muss, um OnTime Gruppenkalender zu nutzen. Dies ist eine Sicherheitsmaßnahme.

Wie die Anmeldung bei der OnTime Gruppenkalender Webversion funktioniert

Im Folgenden gehen wir davon aus, dass Ihre OnTime Gruppenkalender Client-Datenbank („Client-Datenbank“) ”ontimegcclient.nsf“ heißt und sich im Verzeichnis „ontime“ befindet. Um OnTime Gruppenkalender Web zu öffnen, würden Sie Benutzer zu „/ontime/ontimegcclient.nsf/web“ umleiten.

Der Anmeldevorgang läuft wie folgt ab:

1. Der Benutzer navigiert zu "/ontime/ontimegcclient.nsf/web".
2. Der Code prüft, ob ein OnTime Access Token als Browser-Cookie vorhanden ist oder in der URL enthalten ist, wenn der Start über das Notes Workspace-Symbol erfolgt. Wenn dies der Fall ist, wird der Zugriff damit versucht.
3. Sollte dieser OnTime Access Token nicht funktionieren (z. B. abgelaufen sein), werden alle Browser-Cookies gelöscht und der Anmeldevorgang startet neu.
   1. Wenn kein OnTime Access Token gefunden wird, wird ein API-Aufruf durchgeführt, um ein OnTime Access Token zu erhalten. Wenn der Benutzer nicht bei IBM Domino authentifiziert ist, teilt die API dies dem Client mit, und der Benutzer wird zur IBM Domino-Anmeldeseite weitergeleitet (fest codiert, weshalb wir für diesen Prozess nur die formularbasierte Authentifizierung unterstützen).
   2. Wenn ein OnTime Access Token erhalten wurde, wird dieser in einem Browser-Cookie gespeichert und der Anmeldevorgang startet neu.

Wie die Anmeldung bei der mobilen Version von OnTime Gruppenkalender funktioniert

Im Folgenden gehen wir davon aus, dass Ihre OnTime Gruppenkalender Client-Datenbank („Client-Datenbank“) ”ontimegcclient.nsf“ heißt und sich im Verzeichnis ”ontime“ befindet. Um OnTime Gruppenkalender Mobile zu öffnen, würden Sie Benutzer zu „/ontime/ontimegcclient.nsf/mobile“ umleiten.

Abgesehen von der erforderlichen URL ist der Anmeldeprozess derselbe wie bei OnTime.

Einmalige Anmeldung (SSO)

Häufig suchen Kunden nach einer Single Sign-On-Lösung für OnTime Gruppenkalender und dessen Benutzeroberflächen. Die Wahl der richtigen Lösung hängt von der vorhandenen Sicherheitsinfrastruktur ab. Meistens wird der Benutzer jedoch von einem anderen System authentifiziert und/oder die Benutzeridentität lässt sich nicht auf IBM Domino abbilden. Es kann auch vorkommen, dass der Benutzer zwar an einem anderen System authentifiziert ist, die Anmeldedaten aber nicht für IBM Domino wiederverwendet werden können. Es gibt verschiedene Möglichkeiten, dies zu lösen, wie im Folgenden beschrieben.

Der unkomplizierte Ansatz

Nutzen Sie die OnTime Gruppenkalender-Sicherheit unverändert, legen Sie jedoch eine lange Leerlaufzeit für das OnTime Access Token fest. Obwohl dies im strengen Sinne kein Single Sign-On bietet, muss sich der Benutzer nur einmal authentifizieren, solange die Leerlaufzeit für das OnTime Access Token lang genug ist und der Benutzer innerhalb der festgelegten Leerlaufzeit auf OnTime Gruppenkalender zugreift. Diese Option ist standardmäßig verfügbar.

Der API-Ansatz

Wenn Sie die Option OnTime Gruppenkalender Open API (separat erhältlich) erworben haben, können Sie die OnTime Gruppenkalender API auch verwenden, um Token an Benutzer auszugeben. Über die OnTime Gruppenkalender API kann ein Systembenutzer im Namen anderer Benutzer einen OnTime Access Token beziehen und so den Zugriff auf OnTime Gruppenkalender unter Verwendung einer Identität ermöglichen, die von einem anderen System wie Microsoft SharePoint, einem CRM-System oder einem MDM-Anbieter verifiziert wurde. Wir haben bereits Single Sign-On (SSO)-Lösungen für Kunden erstellt, die SSO von Nicht-IBM Domino-Plattformen zu OnTime Group Calendar unter IBM Domino bereitstellen möchten.

Wir haben beispielsweise einen Kunden mit einem Intranet, das auf Microsoft-Technologien basiert, bei dem der Benutzer automatisch per Windows Integrated Authentication (IWA) am Intranet authentifiziert wird. Der Kunde wünschte sich, dass Benutzer den OnTime Gruppenkalender Web öffnen können, ohne sich erneut authentifizieren zu müssen, was schwierig war, da der Benutzer nur am Microsoft-Intranet und nicht an IBM Domino authentifiziert war. Um dies zu lösen, haben wir die OnTime Gruppenkalender API eingesetzt.

Wir haben das Problem gelöst, indem das Intranet, sobald sich der Benutzer angemeldet hatte, den verifizierten Benutzernamen verwendete, um im Namen des Benutzers ein OnTime Access Token zu beziehen (unter Verwendung der OnTime Gruppenkalender API). Nachdem der Intranet-Server ein OnTime Access Token für den Benutzer erhalten hatte, setzte er das korrekte Browser-Cookie, um das Problem zu lösen. Wenn der Benutzer nun versucht, auf OnTime Gruppenkalender zuzugreifen, stellt der Browser automatisch das erhaltene OnTime Access Token bereit, und der Benutzer kann auf OnTime Gruppenkalender zugreifen, ohne sich erneut authentifizieren zu müssen, wodurch Single Sign-On erreicht wird.

SPNEGO / Kerberos (oder falls formularbasierte Authentifizierung nicht verwendet werden kann)

Für Kunden, die SPNEGO mit IBM Domino verwenden, kann die Standard-Zugriffskontrollliste (ACL) der OnTime Gruppenkalender Client-Datenbank Probleme verursachen. Dies liegt daran, dass die Client-Datenbank standardmäßig anonymen Zugriff erlaubt und somit der erforderliche HTTP 401-Antwortcode, der das Betriebssystem zur Initialisierung des Autorisierungs-Handshakes veranlasst, nie gesendet wird. Um dies zu beheben, verfügt die Client-Datenbank über eine spezielle Seite, die eine Authentifizierung des Benutzers erfordert. Anstatt die Seite ”Web” zu verwenden, verwenden Sie einfach die Seite ”WebSSO”.

Wenn Ihre Kundendatenbank beispielsweise ”ontimegcclient.nsf” heißt und sich im Verzeichnis ”ontime” befindet, würden Sie Benutzer normalerweise zu ”/ontime/ontimegcclient.nsf/web” umleiten, um die Web-Benutzeroberfläche von OnTime Gruppenkalender zu öffnen. Wenn Sie SPNEGO verwenden, ersetzen Sie einfach ”/web” durch ”/websso” und leiten Sie Benutzer zu /ontime/ontimegcclient.nsf/websso” um. Mehr ist nicht erforderlich.

Bitte beachten Sie: Es ist sehr wichtig, dass die ACL korrekt konfiguriert ist, wie in der Dokumentation beschrieben, damit dies funktioniert.