Sécurité

types d’OS, dont chacun a sa propre
méthode pour l’identification, l’authentification, et l’autorisation
utilisateur. En revanche, les EJB possèdent quelques
fonctions de sécurité qui simplifient considérablement la
mise en place des autorisations propres à  l’application.
Une application ITP J2EE déployée prévoit généralement
que, quand un utilisateur navigateur envoie la première requête
pour une fonction sécurisée de l’application, le conteneur
Web renvoie une page logon demandant un ID et mot
de passe utilisateur. Cela se fait par le code servlet/JSP personnalisé
ou simplement en déclarant qu’un servlet frontal
est protégé et en spécifiant les deux pages Web logon et logon-
error. (L’application déployée doit aussi utiliser SSL pour
la requête de logon, les requêtes suivantes, et les réponses
qui contiennent des données sensibles, du genre mots de
passe et numéros de cartes de crédit.) Dès lors qu’un utilisateur
est authentifié, le conteneur Web maintient pour lui un
jeton de sécurité pendant la session. Ce jeton de sécurité est
vérifié quand un servlet (ou code d’aide) appelle une méthode
EJB ou tente d’accéder à  d’autres ressources, comme
en cas d’appels JDBC pour accéder à  une base de données.
L’administrateur de sécurité système est chargé de maintenir
un registre d’utilisateurs et de leurs appartenances à 
des groupes : profils utilisateur iSeries et profils de groupes,
par exemple. En termes J2EE, ce sont des principaux de sécurité.
L’administrateur de sécurité WAS (ou autre serveur
d’applications J2EE) doit configurer le conteneur Web pour
utiliser le registre lors de l’authentification des utilisateurs
d’applications.
Le conteneur Web (et le serveur Web) offrent des moyens
d’autorisation basiques pour restreindre l’accès aux servlets,
aux JSP ou aux données statiques (comme des fichiers
d’images). Mais c’est au niveau EJB que se pratique l’essentiel
du contrôle d’autorisation des applications ITP J2EE.
Pour chaque session ou entity EJB, un développeur peut
spécifier un ou plusieurs rôles de sécurité qui sont autorisés
à  appeler la méthode. Quand l’EJB est déployé, ces rôles doivent
être associés aux principaux de sécurité définis dans le
registre des utilisateurs système. A l’exécution, un utilisateur
exécutant un servlet (ou autre programme Java) qui appelle
une méthode EJB, doit être associé directement (ou via l’appartenance
à  un groupe) avec un rôle qui est autorisé à  appeler
la méthode. Cette approche J2EE de la sécurité offre un
moyen simple à  un développeur pour définir l’autorisation
« logique » concernant les fonctions de gestion d’une application,
tandis qu’un administrateur de sécurité gère quels
utilisateurs système ont accès aux fonctions de gestion.
Pour des règles d’autorisation dépendant des données,
comme le fait de restreindre à  un groupe d’utilisateurs limité,
l’accès aux informations personnelles des cadres, une
méthode EJB peut vérifier si le principal de sécurité courant
est associé à  un rôle (par exemple, au DRH) qui est défini par
le programmeur quand l’EJB est développé. Quand l’EJB est
déployé, l’administrateur de sécurité WAS associe le rôle à  un
utilisateur ou groupe concret.
Vous pouvez aussi définir un servlet ou un EJB pour qu’il
« s’exécute » comme un utilisateur particulier quand il procède
à  des appels de méthode, fournissant ainsi une fonction
similaire à  l’autorité adoptée par programme de l’OS/400.
Pour permettre l’accès aux ressources protégées à  l’extérieur
de l’application J2EE (tables de base de données, anciennes
applications, par exemple), l’administrateur de sécurité
peut préciser comment l’information de sécurité d’un
utilisateur de l’application J2EE doit être associée à  l’information
de logon et d’autorisation appropriée, nécessaire à  la
ressource externe.