Wie man mehrere Domino Directories verwaltet, gehört zur Grundausbildung der Notes-Administration. Wie man jedoch ein sekundäres Domino Directory anlegt bzw. in eine "normale" Datenbank integriert, scheint weniger bekannt zu sein, wenn man sich im Internet auf die Suche begibt. Und das, obwohl es mit wenigen Anpassungen ganz einfach möglich ist!

Eine der Stärken von Notes/Domino ist die Regelung von Zugriffsrechten. Dies gilt nicht nur für klassische Notes-Client-Anwendungen, sondern genauso für die weiterhin steigende Anzahl an Web-Anwendungen, die auf den Domino-Server zur Datenhaltung setzen. Dabei ist die Nutzung von Webanwendungen nicht nur für Besitzer einer Notes-ID möglich. Zusätzlich lassen sich Nutzer ohne Notes-ID anlegen, sodass auch Externe bei Bedarf unproblematisch in Prozesse eingebunden werden können. Hier kommt das sekundäre Domino-Directory ins Spiel.

Grundsätzlich lässt sich jede Datenbank als sekundäres Domino Directory nutzen. Das einzige, was man braucht, sind eine Maske mit ein paar Feldern und bestimmte Ansichten, wie sie in der klassischen names.nsf vorkommen.

Jeder Nutzer benötigt (wie auch im Adressbuch) ein persönliches Dokument. Dazu legen wir eine Maske an. Der Name der Maske spielt keine Rolle. Darin werden folgende Felder benötigt:

• FullName: Ein Mehrfachwert-Feld vom Typ Namen. Mit den hierin hinterlegten Namen kann sich der Nutzer anmelden. Der erste Wert im Feld ist dabei der Name, unter dem der Nutzer am Ende im Web agiert. (Kleiner Tipp am Rande: Wenn das Feld berechnet ist, muss man darauf achten, dass der/ein Name in kanonischer Form eingetragen wird. Fiese Fehlerquelle...)
• HTTPPassword: Einfaches Textfeld. Mit dem hier hinterlegten Passwort authentifiziert sich der Benutzer beim Log-In. Man sollte das Passwort natürlich nicht im Klartext hinterlegen. Es bietet sich an, als Eingabeumsetzung die Formel @HashPassword(@ThisValue) (anstelle der unsichereren Funktion @Password) zu verwenden.
• Type: Einfaches Textfeld, das den Wert "Person" enthält. Naturgemäß bietet es sich an, dieses Feld als Berechnet beim Anlegen einzustellen.

Das genügt bereits. Wollen wir hingegen mehr als nur die notwendigen Log-In-Daten speichern, können wir die Maske problemlos erweitern und im Prinzip frei gestalten. Nehmen wir zum Beispiel an, dass wir externen Gutachtern ermöglichen möchten, Dateien hochzuladen. Dann können wir Anschrift, Geburtsdatum, Ausbildung, was auch immer wir in unserem Anwendungsfall an Informationen zum Gutachter sonst noch benötigen in der Maske mitspeichern. Es ist lediglich zu bedenken, dass die Lese- und Bearbeitungsrechte so eingestellt sein sollten, dass Unbefugte nicht aus Versehen die Anmeldedaten ändern oder gar auslesen können.

In der Anwendung muss die Ansicht "($Users)" vorhanden sein. Diese kann aus der Domino-Directory-Standard-Schablone (pubnames.ntf) übernommen werden. Sie dient dem Server zum Look-Up bei der Anmeldung. Wer weitere Funktionen nutzen möchte, benötigt je nach Anwendungsfall ggf. weitere Ansichten. Hier lohnt sich ein genauerer Blick in die Standard-Schablone auf die Ansichten, bei denen in der Selektionsformel Type = "Person" vorkommt.

Der Log-In funktioniert sogar wenn der Nutzer keinen Zugriff auf die Datenbank hat. Damit er jedoch (ohne eventuelle programmatische Umwege) selbst seine Daten oder sein Passwort ändern kann, ist in der Regel der Zugriff als Autor sinnvoll. Die detaillierte Konfiguration hängt vom Anwendungsfall ab. Dabei kann es sich anbieten, mit Wildcards zu arbeiten, wenn eine feste Namensstruktur bei ganzen Benutzergruppen zugrunde liegt. Dadurch muss nicht jeder Nutzer einzeln der ACL oder einer Gruppe im Domino Directory hinzugefügt werden.

Nun muss man die Datenbank nur noch mit dem Server bekannt machen.

Geschafft!