Szenario 3: Kundenzugriff auf interne Benutzerdatenbanken über den Ordner 'Public Queries'

Der Zweck dieses Szenarios besteht darin, Kunden den Zugriff auf eine interne ClearQuest-Datenbank zu erlauben, die Datensätze zu ihren Problemen anzuzeigen, neue Probleme einzureichen und andere relevante allgemein zugängliche Informationen anzuzeigen.

Es ist häufig nützlich, Kunden den Zugriff auf eine interne ClearQuest-Datenbank zu erlauben, um ihnen die Möglichkeit zu geben, die Datensätze anzuzeigen, die sich auf ihre Probleme beziehen, neue Probleme einzureichen und unter Umständen weitere allgemein zugängliche Informationen anzuzeigen, die nicht speziell für einen bestimmten Kunden gelten.

Kontext des Szenarios 3

Ein Schlüsselaspekt dieser Funktionalität ist der, dass einem Kunden nicht erlaubt werden darf, Informationen anderer Kunden einzusehen oder zu ermitteln. Außerdem darf ihnen nicht erlaubt werden, interne Benutzer oder interne Informationen anzuzeigen bzw. zu ermitteln.

Es muss unbedingt erwähnt werden, dass die Berechtigungen für Arbeitsbereichsordner nur dazu dienen, das genannte Ziel zu erreichen. Viele ClearQuest-Schemata beinhalten Datensätze mit Daten, die ein Kunde nicht sehen sollte.

Sie müssen das Feature 'Sicherheitskontext' von Rational ClearQuest verwenden, wenn Sie die Sichtbarkeit der Datensätze, die von einer Abfrage zurückgegeben werden, einschränken möchten. Mit den Berechtigungen für Arbeitsbereichsordner kann nicht eingeschränkt werden, welche Daten von einer Abfrage zurückgegeben werden. Außerdem ist es nicht möglich, mit den Berechtigungen für Arbeitsbereichsordner die Möglichkeiten eines Benutzers zum Absetzen privater Abfragen einzuschränken. Einzig allein das Feature 'Sicherheitskontext' von Rational ClearQuest ist in der Lage, die Datensätze einzuschränken, die von einer Abfrage zurückgegeben werden.

Der Schemaentwickler muss die vom Schema unterstützten Satztypen ändern, indem er Referenzen auf Sicherheitskontextsätze hinzufügt und unter Umständen logische Satztypen auf mehrere Datensätze verteilt, deren logischer Inhalt jeweils gesondert kontrolliert werden kann, um dem Kunden wirklich zu ermöglichen, auf eine interne Benutzerdatenbank zuzugreifen. Wenn ein Produktdatensatz beispielsweise die Produktbeschreibung, den Preis und die Produktionskosten im logischen Datensatz enthält, kann das Feature 'Sicherheitskontext' nur den Zugriff auf den gesamten Datensatz und nicht auf einzelne Teile des Datensatzes einschränken. Darf ein Kunde aber die Produktionskosten für das Produkt nicht wissen, müssen diese Informationen in einem separaten Datensatz verwaltet werden. Eine solche Aufteilung von Datensätzen kann ziemlich komplex sein und zu anderen Problemen führen und wird deshalb nicht empfohlen.

Workflow des Szenarios 3

Der Sicherheitsadministrator führt die folgenden Schritte aus:

  1. Er erstellt eine Gruppe für die Kundenbenutzer (CustUsers).
  2. Er ordnet alle für den Kunden erstellten Benutzer ausschließlich der Kundengruppe 'CustUsers' zu.
  3. Er erteilt der Gruppe 'CustUsers' die Berechtigung 'Read-Limited' für den Ordner 'Public Queries'.
  4. Er erstellt im Ordner 'Public Queries' einen Ordner für den Kunden, z. B. CustFolder.
  5. Er erteilt 'CustUsers' die Berechtigung 'Read-Only' oder 'Read-Write' für 'CustFolder'.

Die Kundenbenutzer können nur ihren eigenen Ordner 'Personal Queries' und den Ordner 'CustFolder' inklusive Inhalt sehen. Wenn dem Ordner 'CustFolder' die Berechtigung 'Read-Only' erteilt wird, können die Kundenbenutzer Ordnerinhalt weder erstellen noch modifizieren, d. h., der Ordner müsste von einer anderen Gruppe, die die Berechtigung 'Read-Write' für den Ordner besitzt, verwaltet werden.

Wenn die Kundenbenutzer auch die Berechtigung 'Read-Write' für den Ordner 'CustFolder' besitzen, können sie Elemente in diesem Ordner erstellen und modifizieren, z. B. Unterordner erstellen, und somit eigene Verwaltungsaufgaben innerhalb des Ordners übernehmen.

Alternatives Szenario 3a: Verwaltung eigener Ordner durch den Kunden

Eine Variante des vorherigen Szenarios ist die Aufteilung der Kundenbenutzer in zwei Gruppen: eine Gruppe für normale Benutzer und eine Gruppe für Benutzer, die den Inhalt des Kundenordners verwalten dürfen. Auf diese Weise kann der Ordner 'CustFolder' auf ähnliche Weise verwendet werden, wie es standardmäßig für den Ordner 'Public Queries' üblich ist, d. h., die meisten Benutzer haben Schreibzugriff, und ausgewählte Benutzer haben Lese-/Schreibzugriff.

Um dies zu erreichen, führt der Sicherheitsadministrator zusätzlich zu den zuvor beschriebenen Aufgaben die folgenden Schritte aus:

  1. Er erstellt eine Gruppe für Kundenadministratoren (CustAdmin). Für den Kunden erstellte Benutzer sind dann je nach ihrer Rolle entweder Mitglied der Gruppe 'CustUsers' oder der Gruppe 'CustAdmin'. Darüberhinaus kann es sich empfehlen, einige Benutzer beiden Gruppen zuzuordnen.
  2. Er erteilt den Gruppen 'CustAdmin' und 'CustUsers' die Berechtigung 'Read-Limited' für den Ordner 'Public Queries'.
  3. Er erteilt der Gruppe 'CustUsers' die Berechtigung 'Read-Only' für den Ordner 'CustFolder' (es gibt keine Möglichkeit, wie im vorherigen Szenario, die Berechtigung 'Read-Write' zu erteilen).
  4. Er erteilt der Gruppe 'CustAdmin' die Berechtigung 'Read-Write' für den Ordner 'CustFolder'.

In diesem Fall können die Mitglieder der Gruppe 'CustAdmin' den Inhalt des Ordners 'CustFolder' modifizieren. Benutzer, die ausschließlich zur Gruppe 'CustUsers' gehören, können dies nicht.

Alternatives Szenario 3b: Mehrere Kundengruppen

Ein großer Kunde kann mehrere interne Gruppen haben, die Zugriff auf eine interne ClearQuest-Datenbank benötigen. In dieser Situation gibt es zwei Fälle: Die Kundengruppen sind entweder unabhängig, oder sie kooperieren miteinander.

Im ersten Fall sind die beiden Kundengruppen unabhängig voneinander und müssen nicht unbedingt voneinander wissen. Dieser Fall würde so behandelt wie zwei vollkommen voneinander unabhängige Kunden. Das einzige wirkliche Problem ist die Auswahl der Namen für die ClearQuest-Gruppen und Kundenordner, so dass kein Verdacht aufkommt, dass mehrere Gruppen vorhanden sind. Dies kann je nach erforderlicher Sicherheitsrichtlinie kritisch sein. Wenn Sie beispielsweise 'Acme1' und 'Acme2' verwenden, würde dies einen Benutzer, der nur zu der einen oder nur zu der anderen Gruppe gehört, vermuten lassen, dass es eine beliebige Anzahl weiterer 'AcmeN'-Gruppen gibt. Die Auswahl angemessener Namen für diese Situation muss der Benutzer üben.

Im zweiten Fall kooperieren die Gruppen miteinander und wissen voneinander, dass sie dieselbe Datenbank verwenden. In dieser Situation ist die Auswahl der Gruppen- und Ordnernamen weniger wichtig. Je nach gewünschtem Grad der gemeinsamen Nutzung der Datenbank, sind verschiedene Varianten für diesen Fall denkbar. Gewöhnlich kontrolliert jede Gruppe bzw. der Administrator jeder Gruppe den eigenen Kundenordner, erlaubt aber der jeweils anderen Gruppe Lesezugriff. Abhängig davon, ob jede Gruppe eine gesonderte Gruppe für die Verwaltung hat (siehe den vorherigen Abschnitt Alternatives Szenario 3a: Verwaltung eigener Ordner durch den Kunden), sind hierfür 2 bzw. 4 Gruppen erforderlich. Eine andere Variante ist die, dass die Gruppen sich die Verwaltungsrolle teilen. Dies macht nur Sinn, wenn der vorherige alternative Workflow verwendet wird. In diesem Fall könnten anstelle von 4 auch nur 3 ClearQuest-Gruppen verwendet werden: 2 für die Kundengruppen und eine für einen allgemeinen Administrator.

Alternatives Szenario 3c: Kooperierende Kunden

Dies ist eine Situation, in der mehrere Kunden an einem einzigen Projekt beteiligt sind und beide dieselben Daten in der internen ClearQuest-Datenbank sichten müssen. Diese Situation kann auf zwei Arten gehandhabt werden.



Feedback