Sicherheitsannotationen
Annotationen sind ein leistungsfähiger Programmiermechanismus, der auf die Empfehlung JSR-175 zurückzuführen ist. Eine Annotation ist eine Standardmethode für den Einschluss unterstützter Sicherheitsverhalten, bei der Quellcode und Konfigurationsdateien automatisch generiert werden können.
Szenario | Regeln |
---|---|
Nur Sicherheitsmetadaten im Implementierungsdeskriptor | Es ist keine Zusammenführung erforderlich. Die Sicherheitsmetadaten aus dem Implementierungsdeskriptor werden weitergegeben. |
Nur Sicherheitsmetadaten in Annotationen | Es ist keine Zusammenführung erforderlich. Die in Annotationen definierten Sicherheitsmetadaten werden weitergegeben. |
Sicherheitsmetadaten im Implementierungsdeskriptoren und in Annotationen | Die Metadaten aus dem Implementierungsdeskriptor und aus den Annotationen werden zusammengeführt. Die Metadaten in Annotationen werden mit demselben Typ von Daten aus dem Implementierungsdeskriptor überschrieben. |
- @DeclareRoles (Servlet 2.5 und höher sowie EJB 3)
Die MergeAction-Implementierung sucht alle Klassen, die mit der Annotation "DeclareRoles" annotiert sind. Wenn die im Implementierungsdeskriptor aufgelisteten Sicherheitsrollen kein SecurityRole-Element mit dem annotierten Rollennamen enthalten, wird in jeder annotierten Klasse für jeden angegebenen Rollennamen ein neues SecurityRole-Element erstellt und der Liste der Sicherheitsrollen hinzugefügt.
- @RunAs (Servlet 2.5 und höher sowie EJB 3)
Die MergeAction-Implementierung sucht alle Klassen mit der Annotation "RunAs". Sie sucht für jede annotierte Klasse das Servlet bzw. die EJB (Enterprise JavaBean), das bzw. die der angegebenen Klasse zugeordnet ist. Anschließend stellt sie fest, ob ein RunAs-Element im Implementierungsdeskriptor des Servlets bzw. der EJB definiert ist. Wenn kein RunAs-Element gefunden wird, wird ein neues RunAs-Element erstellt und dem Implementierungsdeskriptor hinzugefügt. Wenn ein RunAs-Element gefunden wird, wird dieses RunAs-Element verwendet, anstatt ein neues zu erstellen. Der in der Annotation "RunAs" verwendete Rollenname muss im Implementierungsdeskriptor definiert sein.
- @DenyAll (nur EJB 3)
Die MergeAction-Implementierung sucht alle Methoden, die mit der Annotation "DenyAll" definiert sind. Wenn die Methode nicht in der Implementierungsdeskriptorliste ausgeschlossener Methoden enthalten und kein MethodPermission-Element im Implementierungsdeskriptor vorhanden ist, wird für jede annotierte Methode ein neues Element "MethodElement" erstellt und dieser Liste ausgeschlossener Methoden im Implementierungsdeskriptor hinzugefügt.
- @PermitAll (nur EJB 3)
Die MergeAction-Implementierung sucht alle Klassen und Methoden mit der Annotation "PermitAll". Sie sucht für jede annotierte Klasse die EJB (Enterprise JavaBean), die der angegebenen Klasse zugeordnet ist. Anschließend sucht sie die Untergruppe der MethodElements-Elemente in der Liste aller MethodPermissions-Elemente, die im Implementierungsdeskriptor für diese EJB definiert sind. Wenn kein Element "MethodElement" mit einem Platzhalter ("*") für den Methodennamen gefunden wird und keine Platzhaltermethode in der Liste ausgeschlossener Methoden bzw. in der Liste der MethodElements-Elemente mit Sicherheitsrollen vorhanden ist, werden ein neues Element "MethodPermission" und ein neues Element "MethodElement" erstellt. Das neue Element "MethodPermission" wird als nicht ausgewählt gekennzeichnet und MethodPermission-Liste im Implementierungsdeskriptor hinzugefügt. Das neue Element "MethodElement" wird der MethodElement-Liste des neu erstellten, nicht ausgewählten Elements "MethodPermission" hinzugefügt. Ähnliche Aktionen werden für alle anderen annotierten Methoden ausgeführt. Wenn kein Platzhalterelement "MethodElement" vorhanden ist, muss die Methodensignatur mit der Signatur der annotierten Methode exakt übereinstimmen.
- @RolesAllowed (nur EJB 3)
Die MergeAction-Implementierung sucht alle Klassen und Methoden mit der Annotation "RolesAllowed". Sie sucht für jede annotierte Klasse die EJB, die der angegebenen Klasse zugeordnet ist. Anschließend sucht sie die Untergruppe der MethodElements-Elemente in der Liste aller MethodPermissions-Elemente, die im Implementierungsdeskriptor für diese EJB definiert sind. Wenn kein Element "MethodElement" mit einem Platzhalter ("*") für den Methodennamen gefunden wird und keine Platzhaltermethode in der Liste ausgeschlossener Methoden bzw. in der Liste nicht ausgewählter MethodElements-Elemente vorhanden ist, werden ein neues Element "MethodPermission" und ein neues Element "MethodElement" erstellt. Wenn ein Element "MethodPermission" für diese EJB vorhanden ist, die genau dieselben Rollen besitzt, wie sie in der Annotation gefunden wurden, wird dieses Element "MethodPermission" verwendet, anstatt ein neues zu erstellen. Für jeden Rollennamen, der in der Annotation angegeben ist, wird ein neues Element "SecurityRole" erstellt und der SecurityRole-Liste im Element "MethodPermission" hinzugefügt. Falls das Element "MethodPermission" neu erstellt wurde, wird es der MethodPermission-Liste im Implementierungsdeskriptor hinzugefügt. Das neu erstellte Element "MethodElement" wird der MethodElement-Liste des Elements "MethodPermission" hinzugefügt. Ähnliche Verarbeitungsschritte werden für alle anderen annotierten Methoden ausgeführt. Wenn kein Platzhalterelement "MethodElement" vorhanden ist, muss die Methodensignatur mit der Signatur der annotierten Methode exakt übereinstimmen. Falls die Implementierungsdeskriptorliste der Sicherheitsrollen kein Element "SecurityRole" mit dem annotierten Rollennamen enthält, wird außerdem für jeden in der Annotation angegebenen Rollennamen ein neues Element "SecurityRole" erstellt und der Liste der Sicherheitsrollen hinzugefügt.
- @ServletSecurity (nur Servlet 3.0)Anmerkung: Die Unterstützung für die Annotation "ServletSecurity" für Servlet 3.0 ist neu in diesem Release von WebSphere Application Server.
Wenn eine Anwendung implementiert wird, sucht die Implementierung "ServletSecurity MergeAction" alle Servlets mit der Annotation "ServletSecurity". Für jedes annotierte Servlet sucht die Implementierung das Servlet, das der angegebenen Klassenbasis in der Annotation "WebServlet" zugeordnet ist. Wenn RolesAllowed nicht in der Annotation "ServletSecurity" im Implementierungsdeskriptor gefunden wird, wird ein Attribut "role-name" für die Rolle im Implementierungsdeskriptor erstellt.
Wenn eine Anwendung gestartet wird, untersucht der Web-Container alle Servlets mit den Annotationen "RunAs", "declareRoles" und "ServletSecurity" und setzt diese Annotationen in der Methode "setServletSecurity()" der Annotation "ServletRegistration". Der Web-Container weist die Sicherheitskomponente an, alle Annotationen "ServletRegistration" mit URL-Mustern und Sicherheitsvorgaben zu untersuchen. Daraufhin stellt die Sicherheitskomponente fest, ob ein URL-Muster im Implementierungsdeskriptor definiert ist. Ist kein URL-Muster im Implementierungsdeskriptor definiert, werden die Sicherheitsvorgaben und die RunAs-Rolle im URL-Muster erstellt und dann verwendet. Wenn bereits eine exakte Übereinstimmung im Implementierungsdeskriptor definiert ist, werden die Sicherheitsvorgaben und die RunAs-Rolle im URL-Muster des Implementierungsdeskriptors anstelle der Annotationsdaten verwendet.
Anmerkung: Ist die Systemeigenschaft "com.ibm.wsspi.security.web.webAuthReq" für die Webauthentifizierung auf persisting gesetzt, können Sie sich bei einem ungesicherten URL anmelden, wenn ein gültiger Benutzername und ein gültiges Kennwort angegeben werden.Die Servlet-Annotation "Inherited" ist eine Metadatenannotation. Geben Sie die Annotation "Inherited" nicht in der Klasse an. Wenn eine Unterklasse keine Sicherheitsannotation besitzt, übernimmt sie automatisch die Sicherheitsannotation von der übergeordneten Klasse. Die Unterklasse kann die übergeordneten Sicherheitsannotationen mit eigenen Sicherheitsannotationen überschreiben.
Das folgende Beispiel gilt für alle HTTP-Methoden ohne Vorgaben:@WebServlet ("/Example") @ServletSecurity public class Example extends HttpServlet { …… }
Das folgende Beispiel gilt für alle HTTP-Methoden ohne Element <auth-constraint> und erforderlicher TransportGuarantee-Einstellung "confidential" (vertraulich):@WebServlet ("/Example") @ServletSecurity(@HttpConstraint(transportGuarantee = TransportGuarantee.CONFIDENTIAL)) public class Example extends HttpServlet { …… }
Das folgende Beispiel gilt für alle HTTP-Methoden, bei denen alle Zugriffe verweigert werden:@WebServlet ("/Example") @ServletSecurity(@HttpConstraint(EmptyRoleSemantic.DENY)) public class Example extends HttpServlet { …… }
Das folgende Beispiel gilt für alle HTTP-Methoden mit Ausnahme der GET- und POST-Werte ohne Vorgaben. Für GET erfordert das Element <auth-constraint> die Zugehörigkeit zu ALL ROLE. Für POST werden alle Zugriffe verweigert.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity((httpMethodConstraints = { @HttpMethodConstraint(value = "GET", rolesAllowed = “ALL ROLE"), @HttpMethodConstraint(value="POST“, emptyRoleSemantic = EmptyRoleSemantic.DENY)) }) public class Example extends HttpServlet { …… }
Das folgende Beispiel gilt für alle HTTP-Methoden mit Ausnahme von GET. Das Element <auth-constraint> erfordert die Zugehörigkeit zu ALL ROLE, und die Methode GET hat keine Vorgaben.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity(value = @HttpConstraint(rolesAllowed = "ALL ROLE"), httpMethodConstraints = @HttpMethodConstraint("GET")) public class Example extends HttpServlet { …… }
Das folgende Beispiel gilt für alle HTTP-Methoden mit Ausnahme von TRACE. Das Element <auth-constraint> erfordert die Zugehörigkeit zu ALL ROLE, und für TRACE werden alle Zugriffe verweigert.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity(value = @HttpConstraint(rolesAllowed = "ALL ROLE"), httpMethodConstraints = @HttpMethodConstraint(value="TRACE", emptyRoleSemantic = EmptyRoleSemantic.DENY)) public class Example extends HttpServlet { …… }