JACC-Unterstützung in WebSphere Application Server

WebSphere Application Server unterstützt die JACC-Spezifikation (Java™ Authorization Contract for Containers), die externen Sicherheitsprovidern den Umgang mit der Java EE-Berechtigung (Java Platform, Enterprise Edition) ermöglichen.

Diese JAAC-Spezifikation stellt einige Anforderungen an die Container im Anwendungsserver und an den Provider. Die Container müssen die Angaben der Sicherheitsrichtlinie bei der Anwendungsimplementierung an den Provider weitergeben und sich bezüglich aller Berechtigungsentscheidungen an den Provider wenden. Die Provider müssen die Richtlinieninformationen bei der Anwendungsimplementierung in ihrem Repository speichern. Anhand dieser Informationen treffen die Provider dann Entscheidungen hinsichtlich der Berechtigung, wenn sie vom Container dazu aufgefordert werden.

JACC-Zugriffsentscheidungen

Wenn die Sicherheit aktiviert ist und auf eine Enterprise-Bean oder Webressource zugegriffen wird, fordert der EJB-Container oder Web-Container die Sicherheitslaufzeit auf, eine Zugriffsberechtigungsentscheidung zu treffen. Wird ein externer Provider verwendet wird, wird diese Zugriffsentscheidung an diesen Provider delegiert.

In Übereinstimmung mit der JACC-Spezifikation (Java Authorization Contract for Containers) wird das entsprechende Genehmigungsobjekt erstellt, werden die entsprechenden Richtlinienkontext-Handler registriert und wird die entsprechende Richtlinienkontextkennung (contextID) festgelegt. Anschließend wird die vom Provider implementierte Objektmethode java.security.Policy aufgerufen, um die Zugriffsentscheidung zu treffen.

In den folgenden Abschnitten ist beschrieben, wie dieser Aufruf für Enterprise-Bean-Ressourcen und Webressourcen erfolgt.

Zugriffsentscheidungen für Enterprise-Beans

Wenn die Sicherheit aktiviert ist und auf eine EJB-Methode zugegriffen wird, delegiert der EJB-Container die Berechtigungsprüfung an die Sicherheitslaufzeit. Wenn JACC aktiviert ist, führt die Sicherheitslaufzeit die Berechtigungsprüfung wie folgt durch:
  1. Sie erstellt aus dem Bean-Namen, dem Methodennamen, dem Schnittstellennamen und der Methodensignatur das Objekt EJBMethodPermission.
  2. Sie erstellt die Kontext-ID und legt sie mit der Methode "PolicyContext.setContextID(contextID)" im Thread fest.
  3. Sie registriert die erforderlichen Richtlinienkontext-Handler, einschließlich des Richtlinienkontext-Handlers Subject.
  4. Sie erstellt das Objekt "ProtectionDomain" mit Principal im Subject. Falls es keinen Principal gibt, wird als Name des Principals null übergeben.
  5. Die Zugriffsentscheidung wird an den JACC-Provider delegiert. Dazu wird die vom Provider implementierte Methode "implies" des Richtlinienobjekts aufgerufen. An diese Methode werden die Objekte "EJBMethodPermission" und "ProtectionDomain" übergeben.
  6. Die Zugriffsprüfung für isCallerInRole läuft genauso ab, nur dass hier anstelle des Objekts "EJBMethodPermission" das Objekt "EJBRoleRefPermission" erstellt wird.

Zugriffsentscheidungen für Webressourcen

Wenn die Sicherheit aktiviert und für die Verwendung eines JACC-Providers konfiguriert und auf eine Webressource, z. B. ein Servlet oder eine JSP-Datei, zugegriffen wird, delegiert die Sicherheitslaufzeit die Genehmigungsentscheidung wie folgt an den JACC-Provider:
  1. Es wird ein WebResourcePermission-Objekt erstellt, um festzustellen, ob der URI abgewählt ist. Wenn der Provider das Subjekt "Alle" anerkennt, ist dieses hier ebenfalls ausgewählt.
    1. Das WebResourcePermission-Objekt wird aus dem urlPattern und der HTTP-Methode, auf die zugegriffen wird, konstruiert.
    2. Ein ProtectionDomain-Objekt mit null als Name des Principals wird erstellt.
    3. Mit der Berechtigung (Permission) und der Schutzdomäne (ProtectionDomain) wird die Methode Policy.implies des JACC-Providers aufgerufen. Wenn der URI-Zugriff abgewählt ist (oder der Zugriff dem Subjekt "Alle" gewährt wird), erlaubt der Provider den Zugriff und gibt in der Methode "implies" true zurück. Der Zugriff wird dann ohne weitere Prüfungen gewährt.
  2. Falls beim vorherigen Schritt kein Zugriff gewährt wurde, wird ein WebUserDataPermission-Objekt erstellt, um festzustellen, ob der Uniform Resource Identifier (URI) ausgeschlossen ist oder mit dem Protokoll HTTPS umgeleitet werden muss.
    1. Das WebUserDataPermission-Objekt wird aus dem urlPattern, auf das zugegriffen wird, der aufgerufenen HTTP-Methode und dem Transporttyp der Anforderung konstruiert. Falls die Anforderung über HTTPS gesendet wird, wird der Transporttyp auf VERTRAULICH gesetzt. Andernfalls wird null übergeben.
    2. Ein ProtectionDomain-Objekt mit null als Name des Principals wird erstellt.
    3. Mit der Berechtigung (Permission) und der Schutzdomäne (ProtectionDomain) wird die Methode Policy.implies des JACC-Providers aufgerufen. Wenn die Anforderung das Protokoll HTTPS verwendet und die Methode "implies" false zurückgibt, wird der Fehler HTTP 403 (Zugriffsverbot) gemeldet. Es werden keine weiteren Überprüfungen durchgeführt. Wenn die Anforderung nicht das Protokoll HTTPS verwendet und die Methode "implies" false zurückgibt, wird die Anforderung über HTTPS umgeleitet.
  3. Die Sicherheitslaufzeit versucht, den Benutzer zu authentifizieren. Falls die Authentifizierungsinformationen bereits vorliegen (z. B. ein LTPA-Token), werden diese verwendet. Andernfalls müssen die Berechtigungsnachweise des Benutzers eingegeben werden.
  4. Nach Auswertung der Benutzerberechtigungen wird eine abschließende Berechtigungsprüfung durchgeführt, um festzustellen, ob der Benutzer die Zugriffsberechtigung für den URI hat.
    1. Wie in Schritt 2 wird das WebResourcePermission-Objekt erstellt. Das ProtectionDomain-Objekt enthält jetzt den Principal, der versucht, auf den URI zuzugreifen. Der Richtlinienkontext-Handler Subject enthält ebenfalls die Benutzerinformationen, die für die Zugriffsprüfung verwendet werden können.
    2. Die Methode "implies" des Providers wird mit dem Permission-Objekt und dem ProtectionDomain-Objekt aufgerufen, die zuvor erstellt wurden. Wird dem Benutzer erlaubt, auf die Ressource zuzugreifen, gibt die Methode "implies" true zurück. Falls dem Benutzer der Zugriff nicht erlaubt wird, gibt die Methode "implies" false zurück.
Sollte die Reihenfolge der oben beschriebenen Schritte später geändert werden (z. B., um den Durchsatz zu verbessern), so wird das Ergebnis dennoch dasselbe sein. Ist die Ressource beispielsweise ausgeschlossen, kann im Ergebnis nicht auf sie zugegriffen werden.

Weitere Informationen zu diesen Zugriffsberechtigungen finden Sie in der Dokumentation "JSR-000115 Java Authorization Contract for Containers (Version 1.5 Maintenance Release)".

Subject-Informationen für die Zugriffsentscheidung verwenden

Ist der Provider bei der Zugriffsentscheidung auf das von WebSphere Application Server generierte Subject angewiesen, kann er die öffentlichen Berechtigungsnachweise im Subject abfragen, um den Berechtigungsnachweis WSCredential zu erhalten. Mit der WSCredential-API werden Angaben zum Benutzer angefordert. Zu diesen Angaben gehören der Name und die Gruppe, zu der der Benutzer gehört. Anhand dieser Informationen wird die Zugriffsentscheidung gefällt.

Wenn der Provider die erforderlichen Informationen zum Subject hinzufügt, kann WebSphere Application Server die Informationen für die Zugriffsentscheidung verwenden. Der Provider kann die Informationen mit dem Feature Trust Association Interface oder durch Anmeldemodule in Application Server hinzufügen.

Der Abschnitt zur Weitergabe von Sicherheitsattributen enthält weitere Informationen zum Hinzufügen der für WebSphere Application Server erforderlichen Informationen zum Subject. Weitere Informationen hierzu finden Sie im Artikel Sicherheitsattribute an Anwendungsserver weitergeben.

Dynamische Modulaktualisierungen in JACC

WebSphere Application Server unterstützt unter bestimmten Bedingungen dynamische Aktualisierungen der Webmodule. Wenn ein Webmodul aktualisiert, gelöscht oder zu einer Anwendung hinzugefügt wird, wird nur dieses Modul gestoppt und gestartet. Die übrigen Module der Anwendung sind nicht betroffen und die Anwendung selbst wird nicht gestoppt und neu gestartet.

Wenn Sie die Standardberechtigungsengine verwenden, werden alle Sicherheitsrichtlinien in den Webmodulen geändert. Anschließend wird die Anwendung gestoppt und erneut gestartet. Wenn Sie die JACC-basierte Berechtigung verwenden, richtet sich das Verhalten nach der vom Provider unterstützten Funktionalität. Kann ein Provider dynamische Änderungen an Webmodulen vornehmen, sind nur die Webmodule betroffen. Andernfalls wird die gesamte Anwendung gestoppt und neu gestartet, damit die Änderungen an den Webmodulen in Kraft treten können.

Ein Provider kann angeben, ob er dynamische Aktualisierungen unterstützt, indem er im JACC-Konfigurationsmodell die Option Unterstützung dynamischer Modulaktualisierungen angibt. (Weitere Informationen hierzu finden Sie im Artikel Zugriff auf Java EE-Ressourcen mit Tivoli Access Manager berechtigen.) Diese Option kann in der Administrationskonsole oder mit einem Script aktiviert bzw. inaktiviert werden. Es ist davon auszugehen, dass die meisten Provider die Richtlinieninformationen in ihrem externen Repository speichern und somit diese dynamischen Aktualisierungen unterstützen können. Für die Mehrzahl der Provider sollte diese Option standardmäßig aktiviert werden.

Wenn die Option Unterstützung dynamischer Modulaktualisierungen aktiviert ist und ein Webmodul mit Sicherheitsrollen dynamisch hinzugefügt, modifiziert oder gelöscht wird, sind nur spezifische Webmodule betroffen, die dann neu gestartet werden müssen. Ist die Option inaktiviert, muss die gesamte Anwendung neu gestartet werden. Wenn dynamische Aktualisierungen durchgeführt werden, werden die Sicherheitsrichtlinieninformationen der betroffenen Module an den Provider weitergegeben. Weitere Informationen zur Weitergabe der Sicherheitsrichtlinie finden Sie im Artikel Weitergabe von JACC-Richtlinien.

Initialisierung des JACC-Providers

Wenn ein JACC-Provider beim Serverstart initialisiert werden muss, z. B. um die Kommunikation des Clientcodes mit dem Servercode zu ermöglichen, kann er die "Schnittstelle com.ibm.wsspi.security.authorization.InitializeJACCProvider" implementieren. Nähere Informationen finden Sie im Artikel Schnittstellen, die JACC unterstützen.

Wenn diese Schnittstelle implementiert wird, wird sie beim Serverstart aufgerufen. An die Methode "initialize" dieser Implementierung werden alle angepassten Eigenschaften des JACC-Konfigurationsmodells weitergegeben. Die angepassten Eigenschaften können in der Administrationskonsole oder mit einem Script eingegeben werden.

Beim Herunterfahren des Servers wird für die vom Provider angeforderte Bereinigung die Methode "cleanup" aufgerufen. Die Implementierung dieser Schnittstelle ist strikt optional und wird nur angewendet, wenn der Provider eine Initialisierung beim Serverstart anfordert.

Heterogene Knotenumgebung und JACC

Die Berechtigung mit JACC (Java Authorization Contract for Containers) ist ein neues Feature in WebSphere Application Server Version 6. In WebSphere Application Server Version 9 wird die neueste JACC-Spezifikation der Version 1.5 unterstützt.

Die JACC-Konfiguration wird auf Zellenebene definiert und gilt für alle Knoten und Server in dieser Zelle.

Wenn Sie die JACC-basierte Berechtigung mit den Funktionen der Version 1.5 verwenden möchten, darf die Zelle nur Knoten der Version 9 und höher enthalten. Diese Einschränkung bedeutet, dass bei Verwendung einer heterogenen Knotenumgebung mit Knoten der Version 8.5.x oder einer früheren Version in einer Zelle mit Version 9 oder höher die verwendete JACC-basierte Berechtigung auf der niedrigsten unterstützten Version in der Zelle basiert. In diesem Fall handelt es sich um die JACC-basierte Berechtigung der Version 1.4.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_jaccsupport
Dateiname:csec_jaccsupport.html