Verwenden von CA AppLogic® › Grid-Administrationshandbuch › Rollenbasierte Zugriffskontrolle › Beispielszenario

Beispielszenario

CA AppLogic® gibt kein umfassendes Schema von vordefinierten Gruppen und Benutzern an. Dies erlaubt Grid-Administratoren, Benutzer, Gruppen und Objektzugriffe passend zu jeder Situation einzurichten. Im Allgemeinen folgen Grid-Administratoren diesen Schritten:

• Erstellen Sie lokale Benutzer.
• Erstellen Sie einen Satz lokaler Gruppen. Diese Gruppe kann verwendet werden, um Benutzer zu trennen nach Arbeitstyp (zum Beispiel Grid-Administration, Anwendungsentwicklung, Qualitätssicherung, etc.), nach Unternehmensstrukturen (zum Beispiel nach Abteilung oder Geschäftsbereich, damit verschiedene Gruppen von Benutzern ein Grid für ihre Entwicklungsarbeiten gemeinsam nutzen können) oder nach anderen Praxisbereichen. Der gleiche Effekt kann auch mit globalen Gruppen erreicht werden, was besonders sinnvoll ist, wenn das gleiche Setup für zwei oder mehrere Grids verwendet wird.
• Fügen Sie je nach dem Benutzer zu Gruppen, oder Gruppen zu Gruppen hinzu.
• Ändern Sie Objekt-ACLs, um Gruppen bestimmte Zugriffsebenenrechte zuzuweisen.

Das folgende Szenario zeigt ein praktisches Beispiel davon, wie dieser Vorgang funktionieren kann, um einen Benutzerzugriff effektiv zu steuern.

Ace Starships Incorporated (ASI) baut Raumschiffe. Jedes Raumschiff enthält unter anderem Softwaresysteme für Life Support und Antrieb. Diese zwei Softwaresysteme werden auf einem großen freigegebenen CA AppLogic®-Grid entwickelt, bevor sie auf Produktions-Grids auf dem eigentlichem Raumschiff bereitgestellt werden. Der Entwicklungsprozess auf diesem Grid schließt folgende Teams ein:

• Entwicklerteam für Life Support
• Entwicklerteam für Antrieb
• Outsider - Fachleute in der Entwicklung von Middleware-Appliances (allgemeine Appliances)
• Auditoren - ASI-Personal, das zerstörungsfreien Zugriff auf Entwicklung benötigt
• Qualitätssicherung - Personal für Qualitätssicherung, das die Produkte beider Entwicklerteams und der Outsider testet

Auch verfügen wir über:

• Einen globalen Benutzer, john_adams, der Grid-Administrator ist - der Verantwortliche für die Grid-Verwaltung
• Eine globale Benutzerin, jane_osprey, die Grid-Operatorin ist - die Verantwortliche für das Grid, wenn der Grid-Administrator schläft

Außerdem:

• ASI verwendet einen unternehmensweiten LDAP-basierten Verzeichnisdienst für zentralisierte Benutzer- und Gruppenverwaltung. Bis auf die Outsiders verfügen alle über ein Konto auf diesem System.
• Das Team für Antrieb verwendet einige vom Team für Life Support erstellten Anwendungen, verändert aber die Architektur dieser Anwendungen nicht.
• Beide Teams verwenden von den Outsiders entwickelte Appliances, verändern aber diese Appliances nicht.
• Es gibt globale Kataloge, die für die unterschiedlichen Entwicklungsaufwände spezielle Appliances enthalten: life_support, Antrieb und Outsider.

Eine der ersten Entscheidungen, die in diesem Szenario zu treffen sind, betrifft die Frage, ob die Gruppenmitgliedschaft mithilfe des unternehmensweiten Verzeichnisses oder mithilfe lokaler Gruppen verwaltet werden sollte. In diesem Beispiel wählen wir die erste Vorgehensweise:

• Erstellen Sie mithilfe des unternehmensweiten ASI-Verzeichnisses die Gruppen "life_support", "Antrieb", "Qualitätssicherung" und "Auditoren" und fügen Sie diesen Gruppen die entsprechenden globalen Benutzer hinzu. Dieser Vorgang wird außerhalb von CA AppLogic® ausgeführt.

In unserem Beispiel führt der anfängliche CA AppLogic®-Benutzer, der ein Mitglied der lokalen Gruppe "admin" ist, folgende Einrichtung für die Benutzer und Gruppen aus:

• Ein lokales Benutzerkonto für jeden Outsider erstellen.
• Folgende lokale Gruppen erstellen:
  • Outsider
  • grid_operators
  • app_developers
• Die Gruppenmitgliedschaft einrichten:
  • Die erstellten lokalen Benutzer zu den lokalen Gruppen-Outsiders hinzufügen.
  • Die globalen Gruppen "life_support", "Antrieb" und "Qualitätssicherung" zur Gruppe der "app_developers" hinzufügen.
  • Die lokalen Gruppen-Outsider zur Gruppe der "app_developers" hinzufügen.
  • Den globalen Benutzer john_adams zur Gruppe "admin" hinzufügen.
  • Die globale Benutzerin jane_osprey zur Gruppe der "grid_operators" hinzufügen.
• Objekt-ACLs ändern, um Objektzugriff einzurichten:
  • Die Grid-ACL ändern auf:
    • Der lokalen Gruppe "grid_operators" Zugriffsebenenrechte für "grid_operator" erteilen.
    • Der lokalen Gruppe "app_developers" Zugriffsebenenrechte für "app_developer" erteilen.
    • Den globalen Gruppenauditoren Überwachungszugriffsebenenrechte (monitor) erteilen.
  • Die globalen Katalog-ACLs ändern:
    • Der globalen Gruppe "life_support" volle Zugriffsebenenrechte (full) auf dem life_support-Katalog erteilen, der globalen Gruppe "Antrieb" auf dem Antriebskatalog, und der lokalen Gruppe "Outsiders" auf dem Outsider-Katalog.
    • Der lokalen Gruppe "app_developers" Konfigurationszugriffsebenenrechte (configure) auf dem Outsider-Katalog erteilen, und der globalen Gruppe "Antrieb" auf dem life_support-Katalog.

Die folgenden Tabellen zeigen die Gruppenmitgliedschaft in unserem Szenario:

Die folgende Tabelle zeigt die den Prinzipalen für entsprechende Objekte in unserem Szenario erteilten Zugriffsebenenrechte:

Die erste Einrichtung von Benutzern und Gruppen ist nun vollständig. An diesem Punkt können sich globale Benutzer, die zu den globalen Gruppen "life_support", "Antrieb", "Qualitätssicherung" und "Auditoren" gehören, beim Grid anmelden. Jedem Benutzer werden dann automatisch die notwendigen Zugriffsebenenrechte erteilt, um seine Arbeit ausführen zu können.

Zugriff auf die globalen Kataloge ist auch eingerichtet worden, sodass auf Appliances bei Bedarf Zugriff besteht. Jedoch können nur Mitglieder der Gruppe, die volle Zugriffsebenenrechte (full) auf einem Katalog hat, destruktive Vorgänge auf diesem Katalog ausführen.

Wenn ein Benutzer eine neue Anwendung erstellt, wird dieser Benutzer der Anwendungseigentümer, und ihm werden auf dieser Anwendung volle Zugriffsebenenrechte (full) erteilt. Der Benutzer will die Anwendungs-ACL möglicherweise irgendwann ändern, um anderen Mitgliedern seines Entwicklerteams oder eines anderen Teams Zugriff auf die Anwendung zu erteilen. Zum Beispiel:

• Ein Mitglied des Teams für Life Support kann der lokalen Gruppe life_support volle Zugriffsebenenrechte (full) auf der Anwendung erteilen, sodass andere Teammitglieder sie nach Belieben ändern können.
• Ein Mitglied des Teams für Life Support kann der lokalen Gruppe Antrieb Konfigurationszugriffsebenenrechte (configure) auf die Anwendung erteilen, sodass Mitglieder dieser Gruppe die Anwendung konfigurieren oder sie nutzen, aber ihre Architektur nicht verändern können.
• Ein Mitglied des Teams für Life Support kann der globalen Gruppe Qualitätssicherung alle möglichen Zugriffsebenenrechte erteilen, die für das Testen der Anwendung notwendig sind (zum Beispiel Lesezugriff (read), um eine Kopie der Anwendung für getrenntes Testen zu erstellen, Konfigurationszugriff (configure), um die Anwendung zu konfigurieren oder sie zu verwenden, ohne ihre Architektur zu verändern, etc.).