JAX-RS 2.0-Ressource mit Annotationen schützen

Sie können JAX-RS-Ressourcen (Java™ API for RESTful Web Services) mithilfe von Annotationen schützen, die Sicherheitseinstellungen festlegen.

Vorbereitende Schritte

In dieser Task wird davon ausgegangen, dass Sie die Anwendung entwickelt und die JAX-RS-Ressourcen ermittelt haben, die Sie mithilfe von Annotationen schützen möchten.

Informationen zu diesem Vorgang

Sie können JAX-RS-Ressourcen schützen, indem Sie Annotationen für die von JSR 250 unterstützte Sicherheit verwenden. Sie können die folgenden Annotationen verwenden, um Ihren JAX-RS-Anwendungsressourcen Berechtigungssemantik hinzuzufügen:
@PermitAll
Gibt an, dass alle Sicherheitsrollen berechtigt sind, auf Ihre JAX-RS-Ressourcen zuzugreifen.
@DenyAll
Gibt an, dass keine Sicherheitsrollen berechtigt sind, auf Ihre JAX-RS-Ressourcen zuzugreifen.
@RolesAllowed
Gibt die Sicherheitsrollen an, die berechtigt sind, auf Ihre JAX-RS-Ressourcen zuzugreifen.

Sie können Ihre Ressourcen auf Klassenebene oder auf Methodenebene annotieren. Die folgenden Regeln steuern die Annotationen für die Sicherheit:

Annotationen auf Methodenebene haben Vorrang vor Annotationen auf Klassenebene
Im folgenden Code-Snippet ist die JAX-RS-Ressource, die von den Annotationen @GET und @Path von /addresses und der zugehörigen Methode getList() referenziert wird, nicht eingeschränkt und allgemein zugänglich. Die Ressource, die mit den Annotationen @PUT und @Path von /addresses und der zugehörigen Methode updateList() referenziert wird, erfordert jedoch die Rolle Manager. Beispiel:
@Path(value="/addresses")
@PermitAll
public class  AddressBookResource {

  @GET
  @Produces(value="text/plain")
  public String getList() {
  }

  @PUT
  @RolesAllowed(“Manager”)
  public void updateList(String[] books) {
  }
}
Die Annotationen für die Sicherheit schließen sich gegenseitig aus.
Dies bedeutet, dass jede Ressource von maximal einer Annotation für die Sicherheit gesteuert wird. So ist das folgende Beispiel nicht gültig, weil sowohl @PermitAll als auch @RolesAllowed angegeben sind:
@Path(value="/addresses")
@PermitAll
@RolesAllowed(“Employee”)
public class  AddressBookResource {

  @GET
  @Produces(value="text/plain")
  public String getList() {
  }
}

Im vorherigen Codebeispiel hat die Annotation "@RolesAllowed" Vorrang, und die Annotation "@PermitAll" wird ignoriert. Wenn Sie die Annotation "@RolesAllowed" und die Annotation "@DenyAll" angeben, hat die Annotation "@DenyAll" Vorrang.

Gleiches gilt, wenn Sie die Annotationen "@PermitAll" und "@DenyAll" auf Methoden- oder auf Klassenebene angeben. In diesem Fall hat die Annotation "@DenyAll" Vorrang, da sie die Sicherheit durch Einhaltung des Standardsicherheitsprinzips gewährleistet.

Wenn die Annotationen "@PermitAll", "@DenyAll" und "@RolesAllowed" alle auf Methoden- oder Klassenebene definiert werden, hat die Annotation "@DenyAll" Vorrang vor den Annotationen "@RolesAllowed" und "@PermitAll". Die Prioritätsreihenfolge dieser Annotationen ist wie folgt:
  1. @DenyAll
  2. @RolesAllowed
  3. @PermitAll

Vererbungsregel
JSR 250-Annotationen, die auf Klassenebene festgelegt werden, wirken sich nur auf die Klassen, die sie annotieren, und auf die zugehörigen Methoden der Unterressourcen aus. Auf Klassenebene angegebene Annotationen haben keine Auswirkung auf Ressourcen, die von einer Superklasse geerbt werden.
Regel für das Überschreiben von Methoden
Annotationen in Ressourcen, die überschriebenen Methoden in Unterklassen entsprechen, haben Vorrang vor Annotationen, die in der übergeordneten Klasse enthalten sind. Im folgenden Snippet wird die Rolle LocalAdministrator verwendet, um auf die Unterressource /addresses/local zuzugreifen:
@Path(value="/addresses")
@PermitAll
public class  AddressBookResource {

  @GET
  @Produces(value="text/plain")
  public String getList() {
  } 

  @PUT
  @RolesAllowed(“Administrator”)
  public void updateList(String books) {
          
  }
  }

  @Path(value="/addresses")
  @PermitAll
  public class LocalAddressBookResource 
               extends AddressBookResource {
         
  @PUT
  @RolesAllowed(“LocalAdministrator”)
  @Path(value=”local”)  
  public void updateList(String books){  
          
  }
}
Hinweise zu @RolesAllowed
Es ist nicht zulässig, mehrere @RolesAllowed-Annotationen gleichzeitig in einer Ressource zu verwenden. Beispielsweise können Sie die folgenden Festlegungen:
@RolesAllowed("role1")
@RolesAllowed("role2")
public String foo() {
}
mit diesem Code-Snippet realisieren:
@RolesAllowed({"role1", "role2"})
public String foo() {
}
Hinweise zur Verwendung von Annotationen für die Sicherheit und zur Konfiguration von Integritätsbedingungen für die Sicherheit

Annotationen für die Sicherheit folgen dem deklarativen Sicherheitsmodell. Integritätsbedingungen für die Sicherheit, die im Implementierungsdeskriptor, der Datei "web.xml", konfiguriert sind, haben Vorrang vor Integritätsbedingungen für die Sicherheit, die über das Programm in der Anwendung annotiert sind. Es ist wichtig, dass Entwickler von JAX-RS-Ressourcen eine Balance zwischen konfigurierbaren Integritätsbedingungen für die Sicherheit und annotierten Integritätsbedingungen für die Sicherheit finden. Annotierte Integritätsbedingungen werden zusätzlich zu konfigurierten Integritätsbedingungen für die Sicherheit verwendet. Die JAX-RS-Laufzeitumgebung sucht nach annotierten Integritätsbedingungen, nachdem die Laufzeitumgebung des Web-Containers nach konfigurierten Integritätsbedingungen für die Sicherheit in der Datei "web.xml" gesucht hat.

Konfigurieren Sie die Integritätsbedingungen für die Authentifizierung in der Datei "web.xml". In der folgenden Beispieldatei "web.xml" ist die Integritätsbedingung SecurityConstraint_1 für die Sicherheit definiert. Diese Integritätsbedingung wird verwendet, um eine Authentifizierung bei der Anwendung anzufordern. Außerdem definiert die Integritätsbedingung SecurityConstraint_1 Vorgaben für URL-Muster, die den JAX-RS-Ressourcen entsprechen. Wenn eine JAX-RS-Ressource aufgerufen wird, die einer dieser Integritätsbedingungen entspricht, werden Berechtigungsprüfungen durchgeführt. Zugriffsprüfungen werden für die deklarativen Sicherheitsannotationen erst durchgeführt, nachdem die konfigurierten Integritätsbedingungen geprüft wurden.
<web-app id="WebApp_someID">
  	<servlet>
    <servlet-name>AddressBookAppSample</servlet-name>
  <servlet-class>com.ibm.websphere.jaxrs.server.IBMRestServlet</servlet-class>
  <init-param>
    <param-name>javax.ws.rs.Application</param-name>
    <param-value>jaxrs.sample.AddressBookApplication</param-value>
   </init-param>
        		<load-on-startup>1</load-on-startup>
    </servlet>  <servlet-mapping>
        <servlet-name>AddressBookApp</servlet-name>
        <url-pattern>/*</url-pattern>
  </servlet-mapping>
  <security-constraint id="SecurityConstraint_1">
    <web-resource-collection id="WebResourceCollection_1">
       <web-resource-name>AddressBookAppSample</web-resource-name>
       <description>Protection area for Rest Servlet</description>
       <url-pattern>/*</url-pattern>
       <http-method>GET</http-method>
       <http-method>POST</http-method>
       <http-method>PUT</http-method> 
    </web-resource-collection>
    <auth-constraint id="AuthConstraint_1">
      <description>Role1 for this rest servlet</description>
      <role-name>Role</role-name>
    </auth-constraint> 
    <user-data-constraint id="UserDataConstraint_1">
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
    </security-constraint>
    <security-role id="SecurityRole_1">
      <description>This Role is used to drive authentication</description>
      <role-name>Role1</role-name>
    </security-role>
    <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>test realm</realm-name>
    </login-config>
</web-app>

In der vorherigen Beispieldatei "web.xml" wird Role1 für die gesamte Anwendung verwendet. Wenn Sie nur deklarative Sicherheitsannotationen definieren und keine Integritätsbedingungen für die Berechtigung aus der Datei "web.xml" verwenden, können Sie diese Rolle in der Anwendung dem Sondersubjekt für die Benutzerauthentifizierung mit dem Namen "AllAuthenticated" zuordnen.

Vorgehensweise

  1. Stellen Sie fest, ob Integritätsbedingungen für die Sicherheit in der Datei "web.xml" für Ihre JAX-RS-Anwendung definiert sind.
  2. Konfigurieren Sie die Datei "web.xml", und fügen Sie Integritätsbedingungen für die Sicherheit hinzu. Integritätsbedingungen für die Sicherheit, die im Implementierungsdeskriptor, der Datei "web.xml", konfiguriert sind, haben Vorrang vor Integritätsbedingungen für die Sicherheit, die über das Programm in der Anwendung annotiert sind.
  3. Bestimmen Sie, ob zusätzlich zu den Integritätsbedingungen in der Datei "web.xml" Annotationen für die Sicherheit hinzugefügt werden sollen. Legen Sie fest, ob die Annotation @PermitAll, @DenyAll oder @RolesAllowed hinzugefügt werden soll, um zusätzliche Sicherheit für Ihre JAX-RS-Ressourcen zu erreichen. Berücksichtigen Sie die Regeln für das Hinzufügen von Annotationen für die Sicherheit, wie z. B. die zuvor beschriebenen Regeln für Vorrangstellung und Vererbung.

Ergebnisse

Sie haben sichere JAX-RS-Ressourcen mithilfe deklarativer Sicherheitsannotationen definiert.

Beispiel

Das folgende Code-Snippet veranschaulicht, wie Sie Sicherheitsannotationen für den Schutz von JAX-RS-Ressourcen verwenden können. In diesem Beispiel ist der Stammressource /addresses eine Annotation "@PermitAll" zugeordnet, und deshalb können alle Benutzer auf die Unterressource der zugehörigen Methoden @GET und @Produces(value="text/plain") zugreifen, weil diese Ressource keine eigenen Sicherheitsannotationen einführt. Die Unterressource der Methode "@PUT" hat jedoch eine eigene Annotation "@RolesAllowed" und erfordert die Rolle Administrator.
@Path(value="/addresses")
@PermitAll
public class  AddressBookResource {

  @GET
  @Produces(value="text/plain")
  public String getList() {
  } 

       
  @RolesAllowed(“Administrator”)
  @PUT
  public void updateList(String books) {
          
  }
}

Symbol, das den Typ des Artikels anzeigt. Taskartikel



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