TP 8 — Sécurité dans une API Jakarta
RESTful
Mise en place de la sécurité basée sur les rôles
Module Jakarta EE / JAX-RS
Serveur WildFly [Link]
Rôles ADMIN, USER
Méthode HTTP Basic Authentication
Partie 1 — Configuration de l'application
1.1 Classe d'activation JAX-RS
La classe ApplicationConfig est le point d'entrée de l'application JAX-RS. L'annotation
@ApplicationPath définit la racine de l'API, et @DeclareRoles déclare les rôles utilisés dans toute
l'application.
package [Link];
import [Link];
import [Link];
import [Link];
@ApplicationPath("/api")
@DeclareRoles({"ADMIN", "USER"})
public class ApplicationConfig extends Application {
}
✔ Sans @DeclareRoles, les annotations de sécurité sur les endpoints sont ignorées par le serveur.
1.2 Modèle — classe Produit
La classe Produit est un simple POJO (Plain Old Java Object) sérialisé automatiquement en JSON par
WildFly via JSON-B.
package [Link];
public class Produit {
private Long id;
private String nom;
private double prix;
public Produit() {}
public Produit(Long id, String nom, double prix) {
[Link] = id; [Link] = nom; [Link] = prix;
}
// Getters & Setters ...
}
1.3 Service métier — ProduitService
Le service gère une liste statique de produits en mémoire. Le bloc static { } initialise deux produits au
démarrage.
public class ProduitService {
private static List<Produit> produits = new ArrayList<>();
static {
[Link](new Produit(1L, "PC", 8000));
[Link](new Produit(2L, "Souris", 150));
}
public List<Produit> getAll() { return produits; }
public void delete(Long id) {
[Link](p -> [Link]().equals(id));
}
}
1.4 Ressource REST sécurisée — ProduitResource
C'est ici que la sécurité est appliquée. Chaque endpoint reçoit une annotation de contrôle d'accès :
Annotation Effet
@PermitAll Accessible à tous, sans authentification
@RolesAllowed("ADMIN") Réservé aux utilisateurs ayant le rôle ADMIN
@DenyAll Bloqué pour tout le monde
@Path("/produits")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class ProduitResource {
private ProduitService service = new ProduitService();
@GET
@PermitAll // Accès public
public List<Produit> getAll() {
return [Link]();
}
@DELETE
@Path("/{id}")
@RolesAllowed("ADMIN") // ADMIN seulement
public void delete(@PathParam("id") Long id) {
[Link](id);
}
}
Partie 2 — Fichiers de configuration
2.1 [Link] — Activation de l'authentification HTTP Basic
Le fichier [Link] active l'authentification HTTP Basic et déclare les rôles de sécurité reconnus par le
serveur.
<!-- src/main/webapp/WEB-INF/[Link] -->
<web-app ...>
<!-- Active l'authentification HTTP Basic -->
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>ApplicationRealm</realm-name>
</login-config>
<!-- Rôles reconnus par l'application -->
<security-role>
<role-name>ADMIN</role-name>
</security-role>
<security-role>
<role-name>USER</role-name>
</security-role>
</web-app>
■ Sans , WildFly n'applique aucune authentification même si @RolesAllowed est présent.
2.2 [Link] — Liaison avec le domaine de sécurité WildFly
Ce fichier spécifique à WildFly lie l'application au domaine other, qui correspond à l'ApplicationRealm
configuré dans WildFly. Sans ce fichier, les utilisateurs créés via [Link] ne sont pas reconnus.
<!-- src/main/webapp/WEB-INF/[Link] -->
<jboss-web xmlns="[Link]
<security-domain>other</security-domain>
</jboss-web>
✔ Le domaine 'other' est préconfiguré dans WildFly pour utiliser ApplicationRealm.
Partie 3 — Création des utilisateurs dans WildFly
WildFly gère ses utilisateurs d'application via des fichiers .properties. L'outil [Link] (Windows) ou
[Link] (Linux) permet de créer ces utilisateurs en ligne de commande.
Commande à exécuter :
cd WILDFLY_HOME/bin
[Link] # Windows
./[Link] # Linux / macOS
Utilisateurs créés :
Username Password Rôle (Group) Accès
admin admin123 ADMIN GET + DELETE
user user123 USER GET uniquement
✔ Les fichiers modifiés sont : standalone/configuration/[Link] et [Link].
Partie 4 — Tests avec Postman
L'URL de base de l'application déployée est :
[Link]
Test Méthode Authentification Code attendu Explication
1 GET Aucune 200 OK @PermitAll — accès libre
2 DELETE /1 Aucune 401 Unauthorized Pas de credentials fournis
3 DELETE /1 user / user123 403 Forbidden Rôle USER insuffisant
4 DELETE /1 admin / admin123 200 OK Rôle ADMIN autorisé
Configuration de l'authentification dans Postman :
Onglet Authorization de la requête
Type : Basic Auth
Username : admin (ou user)
Password : admin123 (ou user123)
Partie 5 — Résumé du flux de sécurité
Le schéma suivant résume le traitement d'une requête sécurisée par WildFly :
Étape Composant Rôle
1 Client (Postman) Envoie la requête HTTP avec ou sans credentials Basic Auth
2 WildFly Undertow Intercepte la requête et vérifie le login-config dans [Link]
3 ApplicationRealm Vérifie username/password dans [Link]
4 Elytron (domaine other) Associe les groupes/rôles depuis [Link]
5 JAX-RS / RESTEasy Vérifie @RolesAllowed / @PermitAll sur l'endpoint appelé
6 ProduitResource Exécute la logique métier si accès autorisé
Conclusion
Ce TP illustre la mise en place d'une sécurité basée sur les rôles dans une API REST Jakarta EE
déployée sur WildFly. Les points clés à retenir sont :
• @DeclareRoles : déclare les rôles disponibles dans l'application.
• @PermitAll / @RolesAllowed : contrôlent l'accès au niveau de chaque endpoint.
• [Link] : active l'authentification HTTP Basic côté serveur.
• [Link] : lie l'application à l'ApplicationRealm de WildFly.
• [Link] : crée les utilisateurs avec leurs rôles dans WildFly.