Verwaltungsrollen und Berechtigung für den Namensservice
WebSphere Application Server erweitert die rollenbasierte Zugriffssteuerung der Java™-EE-Sicherheit (Java Platform, Enterprise Edition), um die Verwaltungs- und Benennungssubsysteme des Produkts zu schützen.
Verwaltungsrollen
Es wurden mehrere Verwaltungsrollen definiert, um die Berechtigungsstufen zu schaffen, die für die Ausführung spezieller Verwaltungsfunktionen von WebSphere Application Server entweder über die Administrationskonsole oder die Scripting-Schnittstelle für Systemverwaltung wsadmin benötigt werden. Die Berechtigungsrichtlinie wird nur bei Aktivierung der Verwaltungssicherheit umgesetzt. Die folgende Tabelle beschreibt die Verwaltungsrollen:
Rolle | Beschreibung |
---|---|
Monitor (Überwachung) | Eine Einzelperson oder eine Gruppe, die die Rolle "Monitor" (Überwachung)
verwendet, hat die wenigsten Berechtigungen.
Zur Rolle
"Monitor" gehören die folgenden Tasks:
|
Configurator (Konfiguration) | Diese Rolle besitzt zusätzlich zur Rolle "Monitor" (Überwachung) die
Berechtigung, die Konfiguration von WebSphere Application Server zu ändern. Mit dieser Rolle
können alle alltäglichen Konfigurationstasks ausgeführt werden. Mit der Rolle "Configurator" können die folgenden Tasks ausgeführt werden:
|
Operator (Bedienung) | Diese Rolle besitzt zusätzlich zur Überwachungsberechtigung die
Berechtigung, die Konfiguration des Laufzeitstatus zu ändern. Es können beispielsweise
folgende Tasks ausgeführt werden:
|
Administrator (Verwaltung) | Diese Rolle besitzt außer den Berechtigungen der Rollen
Operator (Bedienung) und Configurator (Konfiguration) weitere Berechtigungen, die nur ihm zugewiesen sind. Ein Administrator kann z. B. die folgenden Tasks ausführen:
Anmerkung:
Ein Administrator kann den Verwaltungsrollen keine Benutzer und Gruppen zuordnen. Weitere Informationen dazu, wie Sie Benutzern, denen die Administratorrolle in WebSphere Application Server nicht zugewiesen wurde, Verwaltungsrechte für das eingebundene Repository erteilen, finden Sie unter Benutzer und Gruppen Rollen für die Erteilung von Verwaltungsrechten für das eingebundene Repository zuordnen im Artikel Sicherheit bereitstellen. |
Adminsecuritymanager | Nur Benutzer, die dieser Rolle zugeordnet sind, können Benutzer Verwaltungsrollen zuordnen. Wenn eine differenzierte Verwaltungssicherheit verwendet wird, können außerdem nur Benutzer, die dieser Rolle zugeordnet sind, Berechtigungsgruppen verwalten. Nähere Informationen finden Sie im Artikel Verwaltungsrollen. |
Deployer (Implementierung) | Benutzer, die dieser Rolle zugeordnet sind, können Konfigurationsaktionen und Laufzeitoperationen in Anwendungen ausführen. |
Auditor | Benutzer mit dieser Rolle können die Konfigurationseinstellungen für das Subsystem für Sicherheitsprüfung
anzeigen und ändern. Ein Benutzer mit der Rolle "Auditor" kann beispielsweise die folgenden Tasks ausführen:
|
Rolle | Beschreibung |
---|---|
iscadmins | Diese Rolle ist nur für Benutzer der Administrationskonsole verfügbar, nicht für Benutzer von
wsadmin. Benutzer, die dieser Rolle zugeordnet sind, haben Administratorrechte für die Verwaltung
von Benutzern und Gruppen in eingebundenen Repositorys.
Ein Benutzer der Rolle "iscadmins" kann beispielsweise die folgenden Tasks ausführen:
|
Rolle | Beschreibung |
---|---|
Deployer (Implementierung) | Diese Rolle ist nur für Benutzer von wsadmin verfügbar, nicht für Benutzer der Administrationskonsole. Benutzer, die dieser Rolle zugeordnet sind, können Konfigurationsaktionen und Laufzeitoperationen in Anwendungen ausführen. |
Wenn die Verwaltungssicherheit aktiviert ist, ist die rollenbasierte Zugriffssteuerung für das Verwaltungssubsystem in Kraft. Zum Verwaltungssubsystem gehören der Sicherheitsserver, die Administrationskonsole, das Scripting-Tool wsadmin und alle JMX-MBeans (Java Management Extensions). Wenn die Verwaltungssicherheit aktiviert ist, fordern sowohl die Administrationskonsole als auch das administrative Scripting-Tool von den Benutzern die benötigten Authentifizierungsdaten. Die Administrationskonsole ist außerdem so ausgelegt, dass die auf den Seiten angezeigten Steuerungsfunktionen an die Sicherheitsrolle des Benutzers angepasst werden. Beispielsweise sieht ein Benutzer, der nur die Rolle "Monitor" hat, nur nicht sicherheitsrelevante Konfigurationsdaten. Ein Benutzer, der der Rolle "Operator" zugeordnet ist, kann den Systemstatus ändern.
Wenn Sie die Registry wechseln (z. B. von einem eingebundenen Repository zu einer LDAP-Registry), müssen Sie die Informationen, die sich auf die zuvor konfigurierte Registry beziehen, für Konsolbenutzer und Konsolgruppen entfernen.
Die Dialoge für die Sicherheitsanpassung in WebSphere Application
Server for z/OS
zwingen das Verwaltungssubsystem, die MVS-Identitäten aller gestarteten
Systemtasks von WebSphere Application Server (z. B. Controller, Servants usw.) als WebSphere-Administratoren
zu behandeln und die konfigurierte WebSphere-Administrator-ID zu akzeptieren. Wenn ein eingebundenes Repository, eine eigenständige
LDAP-Registry (Lightweight Directory Access Protocol) oder eine eigenständige angepasste Registry angegeben wird,
werden die konfigurierten Server-IDs für die Arbeiten verwendet, die
vom System ausgeführt werden, und nicht für Arbeiten, die von den gestarteten Tasks ausgeführt werden.
![[z/OS]](../images/ngzos.gif)
![[z/OS]](../images/ngzos.gif)
- Dies ist der Grund, warum der Laufzeitcode von WebSphere Application Server, der unter der Server-ID ausgeführt wird, die Berechtigung zur Ausführung von Laufzeitoperationen erfordert. Sie können die Server-ID und das Kennwort explizit eingeben oder automatisch generieren lassen. Wenn Sie die Server-ID eingeben, muss diese einem gültigen Benutzer in der Registry entsprechen. Wenn Sie die Server-ID automatisch generieren lassen möchten, verwenden Sie die Funktion "internalServerId". Sie können diese Option in der Konfigurationsanzeige jeder Benutzerregistry auswählen. Wenn Sie internalServerId verwenden möchten, geben Sie die Administrator-ID oder adminID im Feld Name des primären Benutzers mit Verwaltungsaufgaben ein. Diese adminID ist ein gültiger Benutzer in der Registry. Es ist kein Kennwort für diese ID erforderlich, und es wird kein Kennwort in der Konfiguration gespeichert. Weitere Informationen finden Sie im Abschnitt "Interne Server-ID" weiter unten.
- Wenn Verwaltungsrollen keine expliziten Benutzer oder Gruppen
zugeordnet wurden, kann man sich mit der Serveridentität oder Administrator-ID an der
Administrationskonsole oder dem Scripting-Tool wsadmin anmelden, um Verwaltungsrollen auszuführen
und anderen Benutzern und Gruppen Verwaltungsrollen zuzuordnen. Dies ist möglich, weil die Serveridentität
(oder Administrator-ID) automatisch der Rolle "adminsecuritymanager" zugeordnet wird. Nur die Benutzer und Gruppen, die der Rolle
"adminsecuritymanager"
zugeordnet sind, können die Benutzer und Gruppen für alle Verwaltungsrollen verwalten. Nachdem
Sie sich mit der Serveridentität (oder Administrator-ID) angemeldet haben,
lässt die Sicherheitsrichtlinie für die Verwaltung die Ausführung von Operationen wie den folgenden zu:
- Server-ID und Serverkennwort ändern
- Verwaltungssicherheit von WebSphere Application Server aktivieren oder inaktivieren
- Java-2-Sicherheit durch Auswahl der Option Java-2-Sicherheit verwenden, um den Anwendungszugriff auf lokale Ressourcen zu beschränken erzwingen
- LTPA-Kennwörter ändern oder Schlüssel generieren
- Es ist keine spezielle Konfiguration erforderlich, um die Serveridentität wie angegeben zu aktivieren, wenn Sie die Verwaltungssicherheit für die Administration aktivieren. Die Serveridentität wird der Administratorrolle automatisch zugeordnet. Das Hinzufügen oder Entfernen von Benutzern und Gruppen für die Verwaltungsrollen ist über die Administrationskonsole von WebSphere Application Server jederzeit möglich. Sie müssen den Server jedoch erneut starten, damit die Änderungen wirksam werden. Es wird empfohlen, eine oder mehrere Gruppen und nicht Benutzer bestimmten Verwaltungsrollen zuzuordnen, da eine flexiblere und einfachere Verwaltung ermöglicht wird. Wird eine Gruppe einer Verwaltungsrolle zugeordnet, erfolgt das Hinzufügen und Entfernen von einzelnen Benutzern (in der Gruppe) außerhalb von WebSphere Application Server und erfordert keinen Serverneustart.
Wenn die Server Verwaltungssicherheit aktiviert ist, werden die WebSphere Application
Server unter der Serveridentität ausgeführt, die in der aktiven Konfiguration der Benutzerregistry definiert ist.
Obwohl dies nicht in der Administrationskonsole oder anderen Tools angezeigt wird,
ist der Rolle "Administrator" ein Sondersubjekt Server zugeordnet. Dies ist der Grund, warum der Laufzeitcode von WebSphere Application Server, der unter der Server-ID ausgeführt
wird, die Berechtigung zur Ausführung von Laufzeitoperationen erfordert.
Wenn keinem anderen Benutzer
Verwaltungsrollen zugeordnet wurden, kann man sich mit der Serveridentität an der
Administrationskonsole oder dem Scripting-Tool wsadmin anmelden, um Verwaltungsaufgaben auszuführen
und anderen Benutzern und Gruppen Verwaltungsrollen zuzuordnen. Da die Serveridentität standardmäßig
der Verwaltungsrolle zugeordnet ist, erfordert die administrative Sicherheitsrichtlinie eine
Verwaltungsrolle zum Ausführen der folgenden Operationen:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Server-ID und Serverkennwort ändern
- Verwaltungssicherheit von WebSphere Application Server aktivieren oder inaktivieren
- Java-2-Sicherheit durch Auswahl der Option Java-2-Sicherheit verwenden, um den Anwendungszugriff auf lokale Ressourcen zu beschränken erzwingen
- LTPA-Kennwörter ändern oder Schlüssel generieren
- Benutzer und Gruppen Verwaltungsrollen zuordnen
- Benutzer mit Verwaltungsaufgaben, der sich von der Benutzeridentität des Servers unterscheidet und die Überprüfbarkeit von Verwaltungsaktionen verbessern soll. Der Benutzername gibt den Namen eines Benutzers mit Verwaltungsberechtigungen an, der im lokalen Betriebssystem definiert ist.
- Unterscheidung der Serveridentität von der Identität des Benutzers mit Verwaltungsaufgaben, um die Überprüfbarkeit zu verbessern. Die Benutzeridentität des Servers wird verwendet, um die Kommunikation zwischen Servern zu authentifizieren.
- Mittels der internen Server-ID
kann die Benutzeridentität für die Authentifizierung zwischen Servern automatisch generiert werden.
Aufgrund der automatischen Generierung der Serveridentität wird eine bessere Überprüfbarkeit für Zellen
für Knoten mit Version 6.1 und höher unterstützt.
In WebSphere Application Server Version 6.1 können Sie die intern generierte Server-ID
speichern, weil das WCCM-Sicherheitsmodell (WebSphere Common Configuration Model) ein neues Tag,
internalServerId, enthält.
Sie müssen während der Sicherheitskonfiguration keine Serverbenutzer-ID und kein Kennwort angeben. Eine Ausnahme sind
heterogene Zellenumgebungen.
Eine intern generierte Server-ID ist eine weitere Stufe des Zugriffsschutzes in der Serverumgebung, weil das
Serverkennwort nicht offen gelegt wird, wie es in den Releases vor
Version 6.1 der Fall ist. Zur Gewährleistung der Abwärtskompatibilität müssen Sie jedoch
die Server-ID angeben, wenn Sie frühere Versionen von WebSphere Application Server verwenden.
Wenn Sie die Sicherheit aktivieren, können Sie den Benennungsrollen einen oder mehreren Benutzern zuordnen. Weitere Informationen hierzu finden Sie im Artikel Benutzer zu Benennungsrollen zuordnen. Konfigurieren Sie jedoch zuerst die aktive Benutzerregistry, bevor Sie den Benennungsrollen Benutzer zuordnen. Die Benutzer- und Gruppenvalidierung ist von der aktiven Benutzerregistry abhängig. Weitere Informationen hierzu finden Sie im Artikel Benutzerregistrys konfigurieren.
- Möglichkeit, ein Sondersubjekt Verwaltungsrollen zuzuordnen. Ein Sondersubjekt ist eine Generalisierung einer bestimmten Klasse von Benutzern. Die Sondersubjekte "AllAuthenticated" und "AllAuhenticatedInTrustedRealms" (bei realmübergreifender Verwendung) bedeuten, dass die Zugriffsprüfung der Verwaltungsrollen sicherstellt, dass der anfragende Benutzer zumindest authentifiziert wurde. Das Sondersubjekt "Jeder" bedeutet, dass jeder, ob authentifiziert oder nicht, die Aktion so ausführen darf, als wäre die Sicherheit nicht aktiviert.
Berechtigung für Namensservice
Die CosNaming-Sicherheitskomponente ermöglicht eine bessere Unterteilung der Sicherheitssteuerung von CosNaming-Funktionen. CosNaming-Funktionen sind auf CosNaming-Servern, wie z. B. dem WebSphere Application Server, verfügbar. Diese Funktionen betreffen den Inhalt des Namespace von WebSphere Application Server. Im Allgemeinen gibt es zwei Verfahren, mit denen Clientprogramme zu CosNaming-Aufrufen führen. Beim ersten Verfahren wird der JNDI-Aufruf (Java Naming and Directory Interface) verwendet. Beim zweiten Verfahren rufen die CORBA-Clients (Common Object Request Broker Architecture) die CosNaming-Methoden direkt auf.
- CosNamingRead
- CosNamingWrite
- CosNamingCreate
- CosNamingDelete
- CosNamingRead
- Sie können den Namespace von WebSphere Application Server beispielsweise mit den JNDI-Lookup-Methoden abfragen. Das Sondersubjekt "Jeder" (Everyone) ist die Standardwertegruppe dieser Rolle.
- CosNamingWrite
- Sie können Schreiboperationen wie JNDI bind, rebind und unbind sowie CosNamingRead-Operationen durchführen. Standardmäßig werden Subjekte dieser Rolle nicht zugeordnet.
- CosNamingCreate
- Sie können mit JNDI-Operationen wie createSubcontext und CosNamingWrite-Operationen neue Objekte im Namespace erstellen. Standardmäßig werden Subjekte dieser Rolle nicht zugeordnet.
- CosNamingDelete
- Sie können Objekte im Namespace löschen, z. B. mit der JNDI-Methode destroySubcontext und CosNamingCreate-Operationen. Standardmäßig werden Subjekte dieser Rolle nicht zugeordnet.
Wenn Sie eine
Benutzerregistry vom Typ lokales Betriebssystem für WebSphere Application Server for z/OS konfigurieren, sind einige Punkte zu beachten. Weitere Informationen finden Sie in den Artikeln Registry oder Repository auswählen und LocalOS-Benutzerregistrys konfigurieren. Wenn
Sie eingebundene Repositorys, eine eigenständige LDAP- oder eine eigenständige angepasste Registry verwenden möchten, müssen Sie
die Anpassung für das lokale Betriebssystem entfernen, indem Sie die vorkonfigurierte Konfigurationsgruppe von
WebSphere Application Server
und die Administratoridentität aus der Konsolgruppe entfernen und die Konsolbenutzer löschen.
Standardmäßig wird allen vier CosNaming-Rollen ein Sondersubjekt "Server" zugeordnet. Das Sondersubjekt Server erlaubt einem Prozess von WebSphere Application Server, der unter der Serveridentität ausgeführt wird, den Zugriff auf alle CosNaming-Operationen. Beachten Sie bitte, dass dieses Sondersubjekt nicht mit der Administrationskonsole oder anderen Verwaltungstools angezeigt oder geändert werden kann.
Es ist keine spezielle Konfiguration erforderlich, um die Serveridentität wie angegeben zu aktivieren, wenn Sie die Verwaltungssicherheit für die Administration aktivieren. Die Serveridentität wird der Administratorrolle automatisch zugeordnet.
Das Hinzufügen oder Entfernen von Benutzern, Gruppen und der Sondersubjekte
"AllAuthenticated" (Alle authentifizierten Benutzer)
und "Everyone" (Jeder) für die Benennungsrollen ist
über die Administrationskonsole von WebSphere jederzeit möglich. Damit die Änderungen wirksam werden, ist jedoch ein Neustart des Servers
erforderlich.
Es ist keine
Konfiguration erforderlich, um die Serveridentität (wie angegeben) zu aktivieren,
wenn die Verwaltungssicherheit aktiviert wird, weil die Server-ID automatisch der
Rolle "Administrator" zuordnet wird. Das Hinzufügen oder Entfernen von Benutzern, Gruppen und der Sondersubjekte
"AllAuthenticated" (Alle authentifizierten Benutzer)
und "Everyone" (Jeder) für die Benennungsrollen ist
über die Administrationskonsole von WebSphere jederzeit möglich. Damit die Änderungen wirksam werden, ist jedoch ein Neustart des Servers
erforderlich. Wenn die SAF-Berechtigung ausgewählt wird, muss der Server nicht erneut gestartet werden, um weitere Benutzer
oder Gruppen zu berechtigen.
Es wird empfohlen, den Benennungsrollen Gruppen oder Sondersubjekte anstatt einzelne Benutzern zuzuordnen, da dies auf längere Sicht eine flexiblere und einfachere Verwaltung ermöglicht. Durch das Zuordnen einer Gruppe zu einer Benennungsrolle erfolgt das Hinzufügen und Entfernen von einzelnen Benutzern (in der Gruppe) außerhalb von WebSphere Application Server und erfordert keinen Serverneustart.
Die CosNaming-Berechtigungsrichtlinie wird nur bei Aktivierung der Verwaltungssicherheit angewendet. Wenn die Verwaltungssicherheit aktiviert ist, führen Versuche, CosNaming-Operationen ohne die erforderliche Rolle auszuführen, zu einer Ausnahme des Typs org.omg.CORBA.NO_PERMISSION vom CosNaming-Server.
Jede CosNaming-Funktion ist genau einer Rolle
zugeordnet. Deshalb
können Benutzer, denen die Rolle "CosNamingCreate" zugewiesen ist, den Namespace nur dann abfragen, wenn ihnen auch der Namespace
CosNamingRead zugewiesen ist.
Und in den meisten Fällen benötigt ein Ersteller
drei Rollen: CosNamingRead, CosNamingWrite und CosNamingCreate. Die Rollen
"CosNamingRead" und "CosNamingWrite"
des genannten Beispiels für einen Ersteller sind in der Rolle "CosNamingCreate" mit enthalten. Meistens brauchen Administratoren
von WebSphere Application Server die Rollenzuordnungen der Benutzer und Gruppen
nicht zu ändern, wenn sie von einer früheren auf diese Version wechseln.
Es ist zwar möglich, den Zugriff auf den Namespace durch Änderung der Standardwertegruppe stark einzuschränken, dies kann jedoch zur Laufzeit zu unerwarteten Ausnahmen des Typs org.omg.CORBA.NO_PERMISSION führen. Normalerweise greifen Java-EE-Anwendungen auf den Namespace zu. Sie verwenden dabei die Identität des Benutzers, der beim Zugriff auf die Java-EE-Anwendung in WebSphere Application Server authentifiziert wurde. Wenn der Lieferant der Java-EE-Anwendung die erwarteten Benennungsrollen nicht eindeutig mitteilt, sollte die Standardberechtigungsrichtlinie für Benennung nur mit Vorsicht geändert werden.