Berechtigung

Die Berechtigung in Liberty legt fest, ob ein Benutzer Zugriff auf eine bestimmte Rolle innerhalb des Systems hat.

Die Berechtigung legt die Zugriffsrechte für Ressourcen fest. Gewöhnlich folgt die Berechtigung der Authentifizierung, bei der eine Identität bestätigt wird. Während die Authentifizierung die Frage "Sind Sie wirklich die Person, die zu sein Sie behaupten?" beantwortet, beantwortet die Berechtigung die Frage "Sind Sie berechtigt, die Aktion auszuführen, die Sie auszuführen versuchen?".

Berechtigung für Verwaltungsfunktionen

Wenn eine Entität versucht, auf eine Ressource zuzugreifen, bestimmt der Berechtigungsservice, ob die Entität die erforderlichen Rechte für den Zugriff auf die Ressource hat. Dieses Konzept kommt zur Anwendung, wenn eine Entität auf eine Anwendung zugreift und oder wenn eine Entität Verwaltungsfunktionen ausführt. Der Hauptunterschied zwischen der Berechtigung des Zugriffs auf eine Anwendung und der Berechtigung des Zugriffs auf eine Verwaltungsfunktion besteht darin, wie die Benutzer Rollen zugeordnet werden. Für die Berechtigung von Anwendungen verwenden Sie das Element application-bnd in der Datei server.xml oder ibm-application-bnd.xml/xmi, um die Benutzer Rollen zuzuordnen. Für die Berechtigung von Verwaltungsfunktionen verwenden Sie das Element administrator-role in der Datei server.xml, um die Benutzer der Administratorrolle zuzuordnen. Weitere Informationen zur Verwaltungssicherheit finden Sie unter Verbindung zu Liberty mit JMX herstellen.

Berechtigung für Anwendungen

Das folgende Diagramm beschreibt, wie die Berechtigung für Anwendungen funktioniert:

Abbildung 1. Übersicht über den Berechtigungsprozess
Der Berechtigungsservice überprüft die Zuordnungen von Rollen zu Benutzern in den Konfigurationsdateien der Anwendung und des Servers. Basierend auf dem Ergebnis der Überprüfung wird die Zugriffsanforderung bewilligt oder zurückgewiesen.
  1. Die Berechtigung wird durchgeführt, wenn eine Eintität versucht, auf eine Ressource in einer Anwendung zuzugreifen, die von Liberty bedient wird. Der Web-Container ruft den Berechtigungsservice auf, um anhand einer Gruppe erforderlicher Rollen zu bestimmen, ob ein Benutzer berechtigt ist, auf eine bestimmte Ressource zuzugreifen. Die erforderlichen Rollen werden von den auth-constraint-Elementen im Implementierungsdeskriptor und in @ServletSecurity-Annotationen bestimmt.
  2. Der Berechtigungsservice bestimmt, welchen Objekten die erforderliche Rolle zugeordnet ist. Dieser Schritt wird ausgeführt, indem die in der Datei ibm-application-bnd.xmi oder ibm-application-bnd.xml und im Element application-bnd der Datei server.xml definierten Zuordnungen verarbeitet werden. Die Zuordnungen aus diesen beiden Quellen werden zusammengeführt. Wenn dieselbe Rolle in beiden Quellen vorhanden ist, wird nur die Rollenzuordnung aus der Datei server.xml verwendet. Die Verwendung der Datei server.xml für die Zuordnung von Rollen zu Benutzern hat den Vorteil, dass Ihre Anwendung nicht in eine EAR-Datei gepackt werden muss und sich leichter aktualisierten lässt. Andererseits lässt sich Ihre Anwendung bei Verwendung der Datei ibm-application-bnd.xmi/xml in andere Server und andere Server mit WebSphere Application Server Traditional portieren, die die Datei server.xml nicht unterstützen.
  3. Wenn die erforderliche Rolle dem Sondersubjekt EVERYONE zugeordnet ist, kehrt der Berechtigungsservice sofort zurück, um jedem Benutzer Zugriff zu gewähren. Wenn die Rolle dem Sondersubjekt ALL_USERS zugeordnet und der Benutzer authentifiziert ist, erteilt der Berechtigungsservice diesem Benutzer den Zugriff. Ist keine dieser Bedingungen erfüllt, bestimmt der Berechtigungsservice, welche Benutzer und Gruppen der erforderlichen Rolle zugeordnet sind. Der Berechtigungsservice erteilt den Zugriff auf die Ressource, wenn der Benutzer der erforderlichen Rolle zugeordnet ist oder wenn der Benutzer zu einer Gruppe gehört, die der Rolle zugeordnet ist.
  4. Der Berechtigungsservice gibt ein Ergebnis an den Web-Container zurück, das Aufschluss darüber gibt, ob dem Benutzer der Zugriff erteilt oder verweigert wird.

Sondersubjekte

Bei der Zuordnung von Entitäten zu Rollen können Sie ein Sondersubjekt anstelle eines bestimmten Benutzers oder einer bestimmten Gruppe zuordnen. Ein Sondersubjekt ist eine Erweiterung des Subjektkonzepts. Ein Sondersubjekt kann eine Gruppe von Benutzern darstellen, die einer bestimmten Kategorie entsprechen.

Die folgenden beiden Typen von Sondersubjekten sind verfügbar:
  • EVERYONE: Stellt eine beliebige Entität im System dar. Das bedeutet, dass es keine Sicherheit gibt, weil jeder zugreifen kann und keine Berechtigungsnachweise angefordert werden.
  • ALL_AUTHENTICATED_USERS: Stellt eine beliebige Entität dar, die erfolgreich im Server authentifiziert wurde.
Wenn Sie einem Benutzer ein Sondersubjekt zuordnen möchten, aktualisieren Sie entweder die Datei ibm-application-bnd.xmi/xml oder die Datei server.xml. Hierbei befindet sich application-bnd im Element application. In diesem Beispiel wird die Rolle mit dem Namen AllAuthenticated dem Sondersubjekt ALL_AUTHENTICATED_USERS zugeordnet:
    <application-bnd>
           <security-role name="AllAuthenticated">
               <special-subject type="ALL_AUTHENTICATED_USERS" />
           </security-role>
       </application-bnd>

Weitere Informationen hierzu finden Sie unter Berechtigung für Anwendungen in Liberty konfigurieren.

Zugriffs-IDs und Berechtigung

Für die Berechtigung eines Benutzers oder einer Gruppe benötigt der Server eine Methode für die eindeutige Identifizierung dieses Benutzers bzw. dieser Gruppe. Diesem Zweck dient die eindeutige ID des Benutzers bzw. der Gruppe, und diese IDs werden für die Erstellung der Berechtigungskonfiguration verwendet. Diese IDs werden von der Benutzerregistry-Implementierung bestimmt. Die eindeutige Benutzer-ID ist der Wert von getUniqueUserId(), und die eindeutige Gruppen-ID ist der Wert von getUniqueGroupId(). Sie können aber auch explizit eine Zugriffs-ID für den Benutzer oder die Gruppe in der Berechtigungskonfiguration angeben. Diese expliziten Zugriffs-IDs werden anstelle der von der Benutzerregistry-Implementierung zurückgegebenen Werte verwendet. Für die Angabe einer Zugriffs-ID in der Datei ibm-application-bnd.xml/xmi oder der Datei server.xml (hierbei ist application-bnd im Element application) verwenden Sie das Attribut access-id für das Element user oder group.

In diesem Beispiel wird eine Zugriffs-ID für den Benutzer Bob und die Gruppe developers angegeben:
    <application-bnd>
           <security-role name="Employee">
               <user name="Bob" access-id="user:MyRealm/Bob"/>
               <group name="developers" access-id="group:myRealm/developers"/>
           </security-role>
    </application-bnd>
Anmerkung: Das Attribut access-id wird für die Berechtigungsprüfung verwendet. Wenn es nicht angegeben ist, wird es über die konfigurierte Registry ermittelt, indem der Benutzer- oder Gruppenname verwendet wird. Sie müssen jedoch das Attribut access-id, wie im nachfolgenden Beispiel gezeigt, angeben, wenn die Benutzer oder Gruppen nicht zur aktiven Registry gehören, wie beispielsweise bei der Verwendung einer programmsteuerten Anmeldung, JSON Web Token (JWT) oder MicroProfile JWT (mpJwt).

OAuth

OAuth ist ein offener Standard für delegierte Berechtigung. Mithilfe des OAuth-Berechtigungsframeworks kann ein Benutzer der Anwendung eines anderen Anbieters den Zugriff auf seine mit einem anderen HTTP-Service gespeicherten Informationen erteilen, ohne seine Zugriffsberechtigungen oder alle seine Daten weiterzugeben. Weitere Informationen zur Verwendung von OAuth für die Berechtigung in Liberty finden Sie in der Dokumentation zu OAuth.

Berechtigung für Anwendungen, wenn keine Rollenzuordnungsbindung angegeben ist

Wenn die Bindungsinformationen für die Rollenzuordnung für eine geschützte Anwendung nicht angegeben werden, verwendet die Standardberechtigungsengine den Rollennamen, der die Ressource schützt, als Gruppennamen für diese Rolle. Lautet der Rollennamen beispielsweise "manager", hat ein Benutzer, der zu einer Managergruppe gehört, Zugriff auf diese Ressource. Dies gilt nur, wenn in der Datei server.xml oder in der Anwendungsbindungsdatei keine Anwendungsbindungsinformationen für die Anwendung angegeben sind. Das Hinzufügen der nachstehenden Bindung inaktiviert beispielsweise die Bindung der Sicherheitsrolle zur Gruppe:
<application type="war" id="myapp" name="myapp" 	location="${server.config.dir}/apps/myapp.war">
      <application-bnd>
	     <security-role name="anyAppRoleName"/>
      </application-bnd>
</application>
Anmerkung: Damit eine Berechtigung für einen Gruppennamen in der Benutzerregistry erfolgreich ist, muss der Rollenname mit dem vollständigen oder eindeutigen Namen der Gruppe in der Registry übereinstimmen, die konfiguriert ist, und nicht mit dem Kurznamen. Wenn beispielsweise der Kurzname der Gruppe swGroup ist, der vollständige oder eindeutige Name in der Benutzerregistry jedoch CN=swGroup,o=company,c=us lautet, müssen Sie als Rollennamen CN=swGroup,o=company,c=us angeben, damit die Berechtigung erfolgreich funktioniert.

Symbol das den Typ des Artikels anzeigt. Konzeptartikel

Dateiname: cwlp_authorization.html