La sécurité applicative répond à deux questions fondamentales : l’authentification. Qui es-tu ? Vérifier l’identité de l’utilisateur interagissant avec l’application (la méthode la plus communément utilisée étant le couple crédentials username/password). Et l’autorisation. Qu’est ce que tu as le droit de faire ? Déterminer les habilitations d’un utilisateur authentifié au sein d’une application (les ressources auxquelles on peut accéder, les services qu’il peut appeler, les données qu’il peut consulter…)

Afin de mettre en place les mécanismes de sécurité répondant à ces deux questions, on a souvent eu recours à des solutions propriétaires, chacun gérant le problème à sa manière. Un semblant de standard est cependant apparu. A savoir le maintenant bien rôdé JAAS (Java Authentication and Authorization Service) dont la robustesse n’a d’égal que la rigidité de son implémentation. De plus, les possibilités de sécurité offertes par la spécification Servlet JEE ou la spécification EJB trahissent un manque de profondeur flagrant pour gérer des cas de scénarios d’entreprise réels. Ces différents standards ne sont d’ailleurs pas portables au niveau War ou EAR et impliquent donc un travail de reconfiguration à chaque changement d’environnement (ex : changement de serveur d’applications).

Mourad NAJAR
Ahmad SOUSAK
Michael Isvy