1 Sécurité dans Java EE Présentation du cours Plan (1/2) Plan (2/2

1
Sécurité dans Java EE
Université de Nice - Sophia Antipolis
Richard Grin
Version 0.17 – 17/9/13
Présentation du cours
Ce cours montre comment sécuriser une
application Java EE : réserver l’accès de pages
Web ou de méthodes d’EJB à certains utilisateurs
Toute la sécurité n’est pas standardisée dans
Java EE ; pour les parties non standardisées, des
exemples de configuration sont donnés pour le
serveur d’application GlassFish
R. Grin Sécurité Java EE page 2
R. Grin Sécurité Java EE page 3
Plan (1/2)
Généralités sur la sécurité
Présentation de la sécurité dans Java EE
Déclaration des rôles
Authentification
Protection des pages Web
Protéger les méthodes des EJB
Code Java pour la sécurité
Configuration de GlassFish
R. Grin Sécurité Java EE page 4
Plan (2/2)
Un exemple avec template
Logs dans GlassFish – mise au point
Gérer les mots de passe
R. Grin Sécurité Java EE page 5
Généralités sur la sécurité
Réserver des parties d’une application à certains
utilisateurs implique de gérer
nl’authentification des utilisateurs
nla vérification des autorisations
R. Grin Sécurité Java EE page 6

2
Authentification
Obtenir l’identité des utilisateurs et vérifier qu’un
utilisateur est bien celui qu’il prétend être
Le plus souvent, il s’agit de demander le nom et
le mot de passe de l’utilisateur
R. Grin Sécurité Java EE page 7
Autorisation
Lorsqu’un utilisateur est entré dans l’application,
vérifier qu’il a bien le droit
nd’accéder aux ressources (pages Web, base
de données,…)
nd’accomplir des actions sur ces ressources
(par exemple les consulter, les modifier, les
supprimer)
nde lancer des opérations
R. Grin Sécurité Java EE page 8
Transport des informations
Protéger les informations qui transitent sur le
réseau contre des personnes non autorisés :
nempêcher la lecture des données
confidentielles
nrepérer qu’une information transmise a été
modifiée par une tierce personne avant
d’arriver à destination
R. Grin Sécurité Java EE page 9
Ce support n’abordera que l’authentification par
mot de passe et les autorisations
Il n’abordera pas, par exemple, l’étude des
certificats et de la signature des documents
Les transparents suivants donnent la terminologie
habituelle liée à la sécurité
R. Grin Sécurité Java EE page 10
Utilisateur
L’utilisateur d’une application est identifié par des
« pièces d’identité », credentials en anglais, qui
prouvent son identité
Le plus souvent la saisie d’un nom de login et d’un
mot de passe prouve l’identité d’un utilisateur
L’utilisateur peut correspondre à une personne ou
à une (partie d’une) application informatique
R. Grin Sécurité Java EE page 11 Richard Grin EJB page 12
Principal
Une fois qu’il est authentifié, l’utilisateur devient
un principal (terme anglais qui signifie mandant,
commettant) au nom duquel il effectuera des
opérations dans l’application
Un principal peut être un utilisateur, un groupe
d’utilisateurs, ou autre, qui a été défini dans
l’environnement opérationnel d’exécution

3
R. Grin Sécurité Java EE page 13
Rôle
La politique de sécurité des serveurs d’application
repose sur la notion de rôle
Exemples de rôle : administrateur, organisateur,
participant, chef de service
Un principal / utilisateur peut avoir un ou plusieurs
rôles dans une application
Un rôle donne des droits aux utilisateurs qui ont
ce rôle
La notion de rôle augmente la portabilité de
l’application puisqu’on ne fait aucune prévision
sur l’existence d’utilisateurs particuliers
Rôles d’un utilisateur
C’est celui qui déploie l’application qui associe
ces rôles
La manière dont un rôle est associé à un
utilisateur n’est pas standard et dépend du
serveur d’application
Tomcat et GlassFish définissent des groupes
d’utilisateurs et il est possible de les configurer
pour qu’un groupe corresponde à un rôle (voir
section « Configuration GlassFish » plus loin
dans ce support)
R. Grin Sécurité Java EE page 14
Groupes d’utilisateurs
Les utilisateurs sont souvent regroupés en
groupes qui ont les mêmes types d’autorisation,
ce qui facilite l’attribution de rôles aux utilisateurs
(on peut donner en bloc un rôle à tous les
membres d’un groupe)
Par exemple, le groupe des utilisateurs
enregistrés, le groupe des visiteurs non
enregistrés, le groupe des administrateurs
R. Grin Sécurité Java EE page 15
Realm – domaine de sécurité
Pour authentifier les utilisateurs, les serveurs
d’application doivent conserver des informations
sur ces utilisateurs
Un domaine de sécurité (realm), identifié par son
nom, définit comment ces informations sont
conservées, et comment on les utilise pour
l’authentification (voir balise <login-config> de
web.xml) ; la définition d’un realm n’est pas
standardisée
Exemples : domaine défini par un fichier des mots
de passe, par des tables relationnelles, par un
registre LDAP, par des certificats informatiques
R. Grin Sécurité Java EE page 16
Intervenants dans le
processus de développement
Le développeur écrit l’application et indique les
rôles nécessaires pour les ressources protégées
L’administrateur du serveur d’application gère les
utilisateurs et les groupes d’utilisateurs
Celui qui déploie l’application dans le serveur
d’application indique la correspondance entre les
utilisateurs et groupe d’utilisateurs et les rôles
définis par l’application (le plus souvent en
utilisant les fichiers de déploiement)
R. Grin Sécurité Java EE page 17 R. Grin Sécurité Java EE page 18
Présentation de la sécurité
dans Java EE

4
Richard Grin EJB page 19
Principe général
Écrire du code pour la sécurité est très complexe
et il est préférable de s’appuyer le plus possible
sur les facilités offertes par les serveurs
d’application
Déclaration ou programmation
Java EE permet d’implémenter une politique de
sécurité de façon déclarative ou par
programmation Java
Le plus simple est d’utiliser les déclarations
(annotations Java ou fichiers de déploiement
XML) pour indiquer comment les ressources
sont protégées
Si la façon déclarative ne suffit pas, il est
possible de programmer les cas les plus
complexes en Java
R. Grin Sécurité Java EE page 20
Déclaration
Les annotations permettent d’écrire les
informations sur la politique de sécurité directement
dans le code Java des EJB ou des servlets
Il n’est pas toujours possible d’utiliser une
annotation ; en ce cas les informations de sécurité
sont décrites dans des balises des fichiers de
déploiement
Toutes les annotations ont leur pendant sous forme
de balise XML ; en cas de contradiction, une
information dans un fichier de déploiement
l’emporte sur une annotation
R. Grin Sécurité Java EE page 21
Fichiers de déploiement
Fichiers standards qui ne dépendent pas du serveur
d’application : web.xml (module Web),
ejb-jar.xml (module EJB), application.xml
(module application qui peut regrouper plusieurs
modules dans un fichier EAR)
Chaque serveur d’application peut aussi avoir ses
propres fichiers de déploiement pour les informations
non standardisées ; pour GlassFish,
glassfish-web.xml, glassfish-ejb-jar.xml,
glassfish-application-web.xml
R. Grin Sécurité Java EE page 22
Types de déclarations
Java EE permet de déclarer
nles rôles utilisés par l’application
nla façon d’authentifier les utilisateurs
nles pages Web protégées et les rôles qui y ont
accès
nles classes ou méthodes Java protégées et les
rôles qui y ont accès
R. Grin Sécurité Java EE page 23
JAAS
La sécurité en Java EE est basé sur Java
Authentication and Authorization Service (JAAS)
qui est inclus dans Java SE (voir cours sur la
sécurité en Java pour plus de détails)
JAAS est centré sur l’utilisateur : il permet de
donner des permissions en se basant sur
l’utilisateur qui exécute le code
JAAS s’appuie sur la notion de modules de login
qui permettent d’authentifier l’utilisateur en
utilisant un certain mode (par exemple en
consultant une base de données)
R. Grin Sécurité Java EE page 24

5
Nous allons tout d’abord étudier comment définir
les rôles puis comment authentifier un utilisateur
Nous verrons enfin comment protéger des pages
Web, puis comment restreindre l’accès à des
méthodes Java
L’attribution de rôles à un utilisateur n’est pas
standardisée ; elle sera étudiée pour le cas de
GlassFish
R. Grin Sécurité Java EE page 25 R. Grin Sécurité Java EE page 26
Déclaration des rôles
Déclaration des rôles
Un rôle doit être déclaré avant d’être utilisé
On peut le faire avec une annotation ou dans un
fichier de déploiement XML
R. Grin Sécurité Java EE page 27
Annotations pour les rôles
On verra les annotations @RolesAllowed,
@PermitAll et @DenyAll pour protéger l’accès
à des méthodes
@RolesAllowed déclare automatiquement les
rôles concernés
Dans des cas complexes, l’annotation
@DeclareRoles peut être utile pour utiliser le
nom d’un rôle dans une classe, sans que le rôle
ne soit déclaré par ailleurs
R. Grin Sécurité Java EE page 28
Annotation pour déclarer des rôles
L’annotation @DeclareRoles peut être mise sur
un EJB ou un servlet, au niveau de la classe
Elle peut prendre en paramètre un nom de rôle ou
une liste de noms de rôle (entourée par des
accolades)
La casse (majuscules – minuscules) est
significative dans les noms de rôle
R. Grin Sécurité Java EE page 29
Exemples
@Stateless
@DeclareRoles("admin")
public class MonBean { ... }
@Stateless
@DeclareRoles({"admin", "membre", "visiteur"})
public class MonBean {
@Resource
private SessionContext sc;
public void m() {
if (sc.isCallerInRole("membre")
...
}
R. Grin Sécurité Java EE page 30