Für z/OS-Plattformen

Mit WZSSAD auf z/OS-Sicherheitsressourcen zugreifen

WZSSAD (WLP z/OS System Security Access Domain) (WZSSAD) bezeichnet die Berechtigungen, die dem Liberty-Server erteilt werden. Diese Berechtigungen steuern, welche SAF-Anwendungsdomänen (System Authorization Facility) und -Ressourcenprofile der Server für die Authentifizierung und Berechtigung von Benutzern abfragen darf.

Wenn Sie beispielsweise zwei Liberty-Serverinstanzen konfigurieren möchten, eine für Produktions- und eine für Testzwecke, und Sie unterschiedliche Rollenzugriffsberechtigungen für die Instanzen verwenden möchten, können Sie zwei unterschiedliche Zugriffsdomänen für die Systemsicherheit (System Security Access Domain) konfigurieren.

Der Liberty-Server ist ein nicht autorisiertes Programm, das von Benutzern mit und ohne Administratorrechte konfiguriert werden kann, daher muss im Interesse der Systemsicherheit und Systemintegrität sichergestellt werden, dass ein Benutzer den Server nicht nutzt, um sicherheitsrelevante Operationen auszuführen, für die er nicht explizit berechtigt ist.

Anmerkung: WZSSAD ist nur gültig, wenn der Server berechtigte SAF-Services für die Authentifizierung und die Berechtigung verwendet. Das bedeutet, dass der Angel-Prozess aktiv ist und dass dem Server die Berechtigung für die Verwendung der berechtigten SAFCRED-Serviceroutinen erteilt wurde.
Die folgenden drei Operationen werden von WZSSAD geschützt:
  • Benutzer authentifizieren
  • Subjekt für Java EE-Rolle berechtigen
  • Subjekt für andere SAF-Ressourcen berechtigen
Standardmäßig ist WZSSAD nicht konfiguriert, d. h., der Server ist nicht berechtigt, Authentifizierungen durchzuführen oder Berechtigungen zu erteilen. Beispielsweise kann der Liberty-Server berechtigte SAF-Services zur Authentifizierung oder Berechtigung erst nutzen, wenn ein Administrator die Services berechtigt, die Operationen teilweise oder vollständig auszuführen.

Benutzer authentifizieren

Der Server authentifiziert Benutzer für eine bestimmte SAF-Domäne, die durch Definition einer als APPLID in der APPL-Klasse referenzierten Ressource konfiguriert wird. Um einen Benutzer für eine Domäne zu authentifizieren, muss der Benutzer Lesezugriff auf die Ressource APPLID in der APPL-Klasse haben. Wenn die APPL-Klasse aktiv ist, benötigt die nicht authentifizierte Benutzer-ID (standardmäßig WSGUEST) auch Lesezugriff auf die APPLID-Ressource in der APPL-Klasse.

Der vom Server verwendete Name der APPLID-Ressource wird durch das Attribut profilePrefix im Konfigurationselement <safCredentials> angegeben. Wenn Sie dieses Element nicht angeben, wird das Standardattribut "profilePrefix" von BBGZDFLT verwendet.

Das folgende Beispiel zeigt, wie das Attribut profilePrefix von BBGZDFLT in der Datei server.xml konfiguriert wird:
<safCredentials profilePrefix="BBGZDFLT"/>
Das folgende Beispiel veranschaulicht die Verwendung von RACF-Befehlen für die Konfiguration von APPLID als BBGZDFLT:
// BBGZDFLT-APPLID in RACF definieren.
RDEFINE APPL BBGZDFLT UACC(NONE)

// APPL-Klasse aktivieren.
// Wenn die Klasse nicht aktiv ist, unterliegt die Domäne keinen Einschränkungen, d. h., jeder kann sich für sie authentifizieren.
SETROPTS CLASSACT(APPL)

// Alle Benutzer, die vom Server authentifiziert werden sollen, müssen Lesezugriff auf die APPLID in der APPL-Klasse haben:
PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(UserID)
//Die nicht authentifizierte Benutzer-ID erfordert Lesezugriff (READ) auf die APPLID in der APPL-Klasse:
PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(WSGUEST)
Darüber hinaus muss dem Server die Berechtigung erteilt werden, im Rahmen von WZSSAD Authentifizierungsaufrufe in der angegebenen APPLID-Domäne durchzuführen. Auf diese Weise wird verhindert, dass ein nicht berechtigter Benutzer den Server für die Verwendung berechtigter SAF-Services nutzt, um festzustellen, welche APPLIDs authentifiziert werden können und welche nicht. Um dem Server die Berechtigung für die Authentifizierung in einer bestimmten APPLID-Domäne zu erteilen, muss die ID der gestarteten Task des Liberty-Servers Lesezugriff auf das Profil BBG.SECPFX.<APPLID> in der Klasse SERVER haben:
RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)
PERMIT BBG.SECPFX.BBGZDFLT CLASS(SERVER) ACCESS(READ) ID(serverUserId)

Subjekt für Java EE-Rolle berechtigen

Der Server berechtigt ein Subjekt für die Sicherheitsrolle einer Java EE-Anwendung. Dazu prüft er, ob das Subjekt für eine in der Klasse EJBROLE definierte SAF-Ressource berechtigt ist. Der Name des SAF-Ressourcenprofils wird über den Anwendungsrollennamen mit dem SAF-Rollenmapper zugeordnet. Der SAF-Rollenmapper generiert einen SAF-Profilnamen für einen bestimmten Anwendungsrollennamen und einen bestimmten Anwendungsressourcennamen. Standardmäßig generiert er den Namen des SAF-Profils mit dem Muster {Profilpräfix}.{Ressource}.{Rolle}. Beispiel:
profilePrefix="BBGZDFLT"

Application resource name = "MYAPP"

Application role name = "ADMIN"

Mapped profile name = "BBGZDFLT.MYAPP.ADMIN"

Weitere Informationen finden Sie unter Liberty: Zuordnung von Rollen zu SAF-Profilen steuern.

WZSSAD beschränkt die SAF-Profile in der Klasse EJBROLE, für die der Server Berechtigungsoperationen ausführen darf. Auf diese Weise wird verhindert, dass ein nicht berechtigter Benutzer den Server für die Verwendung berechtigter SAF-Services nutzt, um Informationen zu den EJBROLE-Profilen abzurufen, für Berechtigungen erteilt bzw. nicht erteilt werden können. Dem Server muss die Berechtigung für die Ausführung von Berechtigungsprüfungen für das übergeordnetes Qualifikationsmerkmal (HLQ, High-Level Qualifier) des EJBROLE-Profilnamens erteilt werden. Das übergeordnetes Qualifikationsmerkmal des Profilnamens ist das erste Segment des Profilnamens bis zum ersten Punkt ('.') ausschließlich. Beispiel:
EJBROLE profile name = "BBGZDFLT.ADMIN" 
HLQ = "BBGZDFLT"
Um dem Server die Berechtigung für die Ausführung von Berechtigungsprüfungen für das Profil HLQ zu erteilen, muss der Benutzer, der dem Serverprozess zugeordnet ist, Lesezugriff auf das Profil BBG.SECPFX.<HLQ> in der Klasse SERVER haben:
RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)
PERMIT BBG.SECPFX.BBGZDFLT CLASS(SERVER) ACCESS(READ) ID(serverUserId)
Da der SAF-Rollenmapper in diesem Beispiel für das übergeordnete Qualifikationsmerkmal (HLQ) des zugeordneten Profils das Profilpräfix angibt, steuert das Profil BBG.SECPFX.BBGZDFLT sowohl die Berechtigungen für die Authentifizierung der APPLID als auch die Berechtigungen für die Autorisierung des EJBROLE-Profils.

Subjekt für andere SAF-Ressourcen berechtigen

Java EE-Anwendungen können Zugriffssteuerungsprüfungen für andere SAF-Klassen als EJBROLE durchführen. WZSSAD beschränkt die SAF-Klassen außerhalb von EJBROLE, für die der Server Berechtigungsoperationen ausführen kann. Dies verhindert, dass ein nicht berechtigter Benutzer oder eine nicht berechtigte Anwendung den Server für die Verwendung berechtigter SAF-Services nutzt, um Informationen zu den Ressourcenprofilen in anderen SAF-Klassen als EJBROLE abruft, für die der Benutzer bzw. die Anwendung berechtigt bzw. nicht berechtigt ist.

Um dem Server die Berechtigung für die Ausführung von Berechtigungsprüfungen für andere SAF-Klassen als EJBROLE zu erteilen, muss der Benutzer, der dem Serverprozess zugeordnet ist, Lesezugriff auf das Profil BBG.SECCLASS.<SAF-CLASS> in der Klasse SERVER haben. Beispiel für die Berechtigung für ein Profil in der Klasse FACILITY:
RDEFINE SERVER BBG.SECCLASS.FACILITY UACC(NONE)
PERMIT BBG.SECCLASS.FACILITY CLASS(SERVER) ACCESS(READ) ID(serverUserId)
Anmerkung: Für welche Ressourcenprofile in der Nicht-EJBROLE-Klasse der Server Berechtigungsoperationen ausführen darf, ist nicht beschränkt. Wenn dem Server die Berechtigung für die Durchführung von Berechtigungsprüfungen für eine Nicht-EJBROLE-Klasse erteilt wurde, kann er die Berechtigungsprüfung für jedes Profil in dieser Klasse ausführen.

Symbol das den Typ des Artikels anzeigt. Referenzartikel

Dateiname: rwlp_WZSSAD_zos.html