Annotazioni di sicurezza
Le annotazioni sono un potente meccanismo di programmazione derivante dal JSR-175 raccomandazione. Un'annotazione è un modo standard per includere comportamenti di sicurezza supportati consentendo al tempo stesso la generazione automatica del codice sorgente e dei file di configurazione.
| Scenario | Regole |
|---|---|
| Metadati di sicurezza solo nel descrittore di distribuzione | Non è necessaria alcuna unione, vengono propagati i metadati di sicurezza dal descrittore di distribuzione. |
| Metadati di sicurezza solo nelle annotazioni | Non è necessaria alcuna fusione, i metadati di sicurezza definiti con le annotazioni vengono propagati. |
| Metadati di sicurezza nel descrittore di distribuzione e nelle annotazioni | I metadati del descrittore di distribuzione e delle annotazioni vengono uniti. I metadati nelle annotazioni vengono sovrascritti dallo stesso tipo di dati dal descrittore di distribuzione. |
- @DeclareRoles (Servlet 2.5 e superiori e EJB 3)
IL MergeAction l'implementazione trova tutte le classi annotate con il file DeclareRoles annotazione. All'interno di ciascuna classe annotata per ciascun nome di ruolo specificato, se i ruoli di sicurezza elencati nel descrittore di distribuzione non contengono un file SecurityRole con il nome del ruolo annotato, un nuovo SecurityRole viene creato e aggiunto a questo elenco di ruoli di sicurezza.
- @RunAs (Servlet 2.5 e superiori e EJB 3)
IL MergeAction l'implementazione trova tutte le classi con l'estensione RunAs annotazione. Per ogni classe annotata, trova il Servlet o l'Enterprise Java Bean (EJB) associato alla classe specificata. Determina quindi se un elemento run-as è definito nel descrittore di distribuzione per il servlet o EJB. Se non ne viene trovato uno, viene creato un nuovo elemento run-as e aggiunto al descrittore di distribuzione. Se viene trovato un elemento run-as, verrà utilizzato questo elemento run-as invece di crearne uno nuovo. Il nome del ruolo utilizzato nel file RunAs l'annotazione deve essere definita nel descrittore di distribuzione.
- @DenyAll (solo EJB 3)
IL MergeAction l'implementazione trova tutti i metodi annotati con il file DenyAll annotazione. Per ciascun metodo annotato, se il metodo non è incluso nell'elenco dei descrittori di distribuzione dei metodi esclusi, e a MethodPermission non esiste nel descrittore di distribuzione, un nuovo MethodElement viene creato e aggiunto a questo elenco di metodi esclusi nel descrittore di distribuzione.
- @PermitAll (solo EJB 3)
IL MergeAction l'implementazione trova tutte le classi e i metodi con il file PermitAll annotazione. Per ogni classe annotata, trova l'Enterprise Java Bean (EJB) associato alla classe specificata. Quindi cerca il sottoinsieme di MethodElements nell'elenco di tutti i MethodPermissions definito nel descrittore di distribuzione per questo EJB. Se un MethodElement con un nome di metodo con caratteri jolly ("*") non viene trovato e non esiste un metodo con caratteri jolly nell'elenco dei metodi esclusi o nell'elenco dei MethodElements con ruoli di sicurezza, un nuovo MethodPermission e uno nuovo MethodElement sono creati. Il nuovo MethodPermission è contrassegnato come deselezionato e viene aggiunto al file MethodPermission elenco nel descrittore di distribuzione. Il nuovo MethodElement viene aggiunto al MethodElement elenco dei nuovi creati deselezionati MethodPermission. Un'azione simile viene eseguita per tutti i metodi annotati. Invece di un carattere jolly MethodElement, la firma del metodo deve corrispondere esattamente alla firma del metodo annotato.
- @RolesAllowed (solo EJB 3)
IL MergeAction l'implementazione trova tutte le classi e i metodi con il file RolesAllowed annotazione. Per ogni classe annotata, trova l'EJB associato alla classe data. Quindi trova il sottoinsieme di MethodElements nell'elenco di tutti i MethodPermissions definito nel descrittore di distribuzione per questo EJB. Se un MethodElement con un nome di metodo con caratteri jolly ("*") non viene trovato e non esiste un metodo con caratteri jolly nell'elenco dei metodi esclusi o nell'elenco dei metodi non selezionati MethodElements, un nuovo MethodPermission E MethodElement sono creati. Se un MethodPermission per questo EJB esiste esattamente con gli stessi ruoli di quelli trovati nell'annotazione, this MethodPermission verrà utilizzato invece di crearne uno nuovo. Per ogni nome di ruolo specificato nell'annotazione, un nuovo SecurityRole viene creato e aggiunto al file SecurityRole elenco nel MethodPermission, Se la MethodPermission è stato appena creato, viene aggiunto al file MethodPermission elenco nel descrittore di distribuzione. Il nuovo MethodElement creato viene aggiunto al file MethodElement elenco dei MethodPermission. Un'elaborazione simile viene eseguita per tutti i metodi annotati. Invece di un carattere jolly MethodElement, la firma del metodo deve corrispondere esattamente alla firma del metodo annotato. Inoltre, per ogni nome di ruolo specificato nell'annotazione, se l'elenco dei descrittori di distribuzione dei ruoli di sicurezza non contiene un file SecurityRole con il nome del ruolo annotato, un nuovo SecurityRole viene inoltre creato e aggiunto a questo elenco di ruoli di sicurezza.
- @ServletSecurity (Servlet 3.0 soltanto)Nota: Supporto per ServletSecurity annotazione per servlet 3.0 è nuovo in questa versione di WebSphere® Application Server.
Quando un'applicazione viene distribuita, il file ServletSecurity MergeAction l'implementazione trova tutti i servlet con l'estensione ServletSecurity annotazione. Per ogni servlet annotato, trova il servlet associato alla base della classe specificata nel file WebServlet annotazione. Se RolesAllowed nel ServletSecurity l'annotazione non viene trovata nel descrittore di distribuzione, crea quindi un attributo nome-ruolo per il ruolo nel descrittore di distribuzione.
Quando viene avviata un'applicazione, il file WebContainer ispeziona tutti i servlet con il file RunAs, declareRoles, E ServletSecurity annotazioni e imposta tali annotazioni sul file setServletSecurity() metodo del ServletRegistration annotazione. IL WebContainer notifica al componente di sicurezza di ispezionare tutto ServletRegistration annotazioni con pattern URL e vincoli di sicurezza. Il componente di sicurezza determina quindi se un modello URL è definito nel descrittore di distribuzione. Se non ne è definito uno nel descrittore di distribuzione, i vincoli di sicurezza e RunAs ruolo nel pattern URL vengono creati e quindi utilizzati. Se una corrispondenza esatta è già definita nel descrittore di distribuzione, i vincoli di sicurezza e RunAs vengono utilizzati i ruoli nel pattern URL del descrittore di distribuzione al posto dei dati di annotazione.
Nota: Quando la proprietà del sistema di autenticazione web, com.ibm.wsspi.security.web.webAuthReq, è impostato per persistente, puoi accedere a un URL non protetto se vengono forniti un nome utente e una password validi.L'annotazione servlet ereditata è un'annotazione di metadati. Non specificare l'annotazione ereditata nella classe. Se una sottoclasse non ha un'annotazione di sicurezza, eredita automaticamente l'annotazione di sicurezza dalla classe genitore. La sottoclasse può sovrascrivere le annotazioni di sicurezza principali specificando le proprie annotazioni di sicurezza.
L'esempio seguente riguarda tutti i metodi HTTP senza vincoli:@WebServlet ("/Example") @ServletSecurity public class Example extends HttpServlet { …… }L'esempio seguente riguarda tutti i metodi HTTP senza elemento <auth-constraint> e riservati TransportGuarantee necessario:@WebServlet ("/Example") @ServletSecurity(@HttpConstraint(transportGuarantee = TransportGuarantee.CONFIDENTIAL)) public class Example extends HttpServlet { …… }L'esempio seguente riguarda tutti i metodi HTTP con tutti gli accessi negati:@WebServlet ("/Example") @ServletSecurity(@HttpConstraint(EmptyRoleSemantic.DENY)) public class Example extends HttpServlet { …… }L'esempio seguente riguarda tutti i metodi HTTP ad eccezione dei valori GET e POST senza vincoli. Per GET, l'elemento <auth-constraint> richiede l'appartenenza a ALL ROLE. Per POST, tutti gli accessi sono negati.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity((httpMethodConstraints = { @HttpMethodConstraint(value = "GET", rolesAllowed = "ALL ROLE"), @HttpMethodConstraint(value="POST", emptyRoleSemantic = EmptyRoleSemantic.DENY)) }) public class Example extends HttpServlet { …… }L'esempio seguente riguarda tutti i metodi HTTP tranne GET, l'elemento <auth-constraint> richiede l'appartenenza a ALL ROLE e il metodo GET non ha vincoli.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity(value = @HttpConstraint(rolesAllowed = "ALL ROLE"), httpMethodConstraints = @HttpMethodConstraint("GET")) public class Example extends HttpServlet { …… }L'esempio seguente riguarda tutti i metodi HTTP eccetto TRACE, l'elemento <auth-constraint> richiede l'appartenenza a ALL ROLE e per TRACE ogni accesso è negato.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity(value = @HttpConstraint(rolesAllowed = "ALL ROLE"), httpMethodConstraints = @HttpMethodConstraint(value="TRACE", emptyRoleSemantic = EmptyRoleSemantic.DENY)) public class Example extends HttpServlet { …… }