Par: Bourgou Mohsen Chouaieb Sonia GL5 INSAT

Présentation au sujet: "Par: Bourgou Mohsen Chouaieb Sonia GL5 INSAT"— Transcription de la présentation:

1 Par: Bourgou Mohsen Chouaieb Sonia GL5 INSAT 2005-2006
Sécurité J2EE avec WAS Par: Bourgou Mohsen Chouaieb Sonia GL5 INSAT

2 Plan Introduction à la sécurité Les bases de la sécurité
Architecture de la sécurité dans J2EE Sécurisation d’une application J2EE WebSphere Application Server de IBM Sécurité avec WAS Conclusion Références et documentation

3 Introduction à la sécurité

4 Les 4 Piliers de la sécurité
Autorisation Authentification Intégrité: État du contenu Intact? Confidentialité

5 Plus concrètement… Identification: qui est-ce?
Authentification: est-ce bien la personne à laquelle je pense? La confidentialité: est-ce que quelqu’un d’autre écoute et comprend? L’intégrité: Le contenu est-il intact, modifié? La non répudiation: impossibilité de renier un échange!

6 Les bases de la sécurité
Cryptographie Hachage Signature numérique

7 Les bases de la sécurité
Cryptographie Cryptage à clé symétrique ou à clé asymétrique. Algorithmes: RSA, DSA, Diffie-Hellman… Hachage: convertir un élément de données d'une longueur qcq en un nombre d'une longueur fixe. Techniques: MD5, SHA-1. Signature Numérique: Agit comme un contrôle d'intégrité des données et fournit la preuve de possession de la clé privée. Le processus est transparent pour l'utilisateur.

8 Architecture de la sécurité dans J2EE
Contrôle aux ressources systèmes JCA JAAS JCE JSSE SSL

9 Contrôle aux ressources systèmes
Vérification du code avec Security Policy: permet de définir exactement les limitations du code exécuté. détermine les permissions correspondantes aux droits d'accès attribuées au code Java provenant d'une source déterminée. Le Security Manager permet de vérifier: la politique de sécurité en cours et les permissions à accorder à un processus particulier, avant même que celui-ci soit exécuter.

10 JCA: Java Cryptography Architecture
S’organise autour du package java.security. Inclus dans JDK à partir de sa version 1.1. Concept sécuritaire complet et puissant. Permet l’utilisation d’utilitaires et le développement de fonctionnalités cryptographiques. JCA regroupe 3 API Java fournissant les outils cryptographiques:

11 JAAS: Java Authentication and Authorization Service
Standard de sécurité de JAVA (depuis qu'il a été intégré à la JDK 1.4). Processus: D’authentification: déterminer l’identité de celui qui exécute le code Java D’autorisation: donner les permissions requises aux utilisateurs pour performer leurs actions. Doté de mécanismes souples et évolutifs de sécurisation des applications Java client et serveur.

12 JAAS L'API de JAAS est très complète, voici ses principales interfaces: Callback –Permet d'encapsuler les informations échangées entre les services de sécurités et un CallbackHandler. CallbackHandler – Permet de faciliter la communication entre une application et les service de sécurités. LoginContext – Fournit les méthodes basiques utilisées afin d'authentifier un utilisateur, une autre application, ... LoginModule – Fournit un type particulier d'authentification a travers un module ajouté Principal – Représente une entité unique (utilisateur, organisation, mot de passe,...) qui peut être authentifié. Subject – Groupement d'informations pour une entité.

13 JCE Java Cryptography Extension
Stockage des informations confidentielles. Ensemble de classes implémentant des fonctions d’encryptions, de génération et de vérification de clés, d’utilisation des algorithmes MAC (Message Authentification Code). API JCE dans Java 2 SDK, v1.4:  Packetages caractérisant JCE (chiffrement, le déchiffrement et la génération de clés...): Package javax.crypto Package javax.crypto.interfaces Package javax.crypto.spec

14 JSSE Java Secure Sockets Extension
API permettant l’implémentation des sockets sécurisées (SSLSocket et SSLServerSocket), de managers de clés, de contextes SSL. Assure l’intégrité de l’information transmise et la confidentialité des informations. Autorise des connexions réseaux sécurisées. Crée un canal sécurisé de transmission. Fournit une Implémentation du protocole SSL.

15 SSL: Secure Socket Layer
Pourquoi SSL? Vous n’êtes pas toujours certain de l’identité de votre interlocuteur. Les données transmises peuvent être interceptées par une tierce partie (espion passif). Les données transmises et interceptées peuvent être modifiées à votre insu (espion actif).

16 Sécurisation d’une application J2EE

17 Architecture d’une application J2EE

18 Critiques de la Sécurité dans la plupart des applications J2EE
couche présentation : Sécurité limitée au niveau authentification. Pas de découpage par rôle. couche métier : Inexistence de la sécurité au niveau des EJBs. couche intégration : Aucune confidentialité des données critiques. Transmission des données en clair.

19 Sécurisation de la couche présentation

20 Couche présentation Responsable de deux services de sécurité fondamentaux : l'authentification et l'habilitation des utilisateurs. Alternatives de sécurité possibles: Déclarative: basée sur la notion de rôles définies pour accéder à un domaine sécurisé. Programmatique pure: contrôle beaucoup plus fin, mais avec beaucoup de code. Déclarative et programmatique: affine le contrôle sur les domaines avec peu de code.

21 Méthode déclarative Méthodes d’authentification dans une WebApp.
Configuration d’authentification. Configuration d’autorisation.

22 Méthode déclarative Méthodes d’authentification dans une WebApp
FORM 2 pages: login.html et error.html BASIC On a une boîte de dialogue. Envoi du username et password en clair. DIGEST Pareil à BASIC sauf que seul le password est envoyer en plus il est crypté  Plus Sécurisé! CLIENT-CERTIFICATE Utilise SSL et des clés publiques pour les certificats.

23 Méthode déclarative Configuration d’authentification: Web.xml
<login-config> <auth-method>FORM</auth-method> <realm-name>default</realm-name> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config> <security-role> <role-name>rolename</role-name> </security-role>

24 Méthode déclarative Configuration de l’authentification Web.xml
<login-config> <auth-method>BASIC</auth-method> <realm-name>basic-file</realm-name> </login-config>

25 Méthode déclarative Configuration des autorisations: Web.xml
<security-constraint> <web-resource-collection> <web-resource-name>Pages protégées</web-resource-name> <url-pattern>/PageSecurisé.html</url-pattern> <http-method>PUT</http-method> <http-method>DELETE</http-method> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>staffmember</role-name> </auth-constraint> </security-constraint>

26 Méthodes Programmatiques
Les méthodes HttpServlet : getRemoteUser(): Retourne l’identifiant de l’utilisateur identifié. getUserPrincipal(): Retourne un objet de type Principal caractérisant l’utilisateur connecté. isUserInRole(String role): Permet de déterminer si l’utilisateur connecté possède le rôle passé en paramètre.

27 Sécurisation de la couche Métier

28 Couche métier La spécification J2EE décrit un contrôle assez fin dans lequel l'élément unitaire est la méthode. L’accès aux méthodes est restreint aux rôles des utilisateurs ou à d’autres composants de l’application (EJB…). Basé sur la notion des rôles en configurant le fichier ejb-jar.xml

29 Configuration de ejb-jar.xml
<assembly-descriptor> <security-role> <role-name>client</role-name> <role-name>administrateur</role-name> </security-role> <method-permission> <unchecked/> <method> <ejb-name>ReclamationEJB</ejb-name> <method-intf>Remote</method-intf> <method-name>create</method-name> </method> </method-permission> <ejb-name>ClientEJB</ejb-name> <method-intf>Home</method-intf> <method-name>ajoutClient</method-name> </assembly-descriptor>

30 Sécurité applicative pour les EJBs
Les méthodes EJB: isCallerInRole(String roleName): si l’utilisateur connecté possède le rôle passé en paramètre ou pas. getCallerPrincipal(): Retourne un objet de type CallerPrincipal.

31 Sécurisation de la couche Intégration

32 Couche intégration Sécurisation des données confidentielles des utilisateurs: Hachage des mots de passes. Cryptage des numéros de comptes bancaires. Chiffrement via JCE.

33 Protection contre les injections SQL
Deux étapes à travers lesquels passe chaque entrée d’un utilisateur: Vérification de la taille du nom d’utilisateur et du mot de passe. Interception des caractères non permis: * % ; ‘

34 Démo…

35 WebSphere Application Server de IBM
WAS comporte un ensemble complet d'outils intégrés pour l'optimisation et la gestion d'applications Web complexes.

36 Sécurité avec WAS

37 WAS permet de: décrire et réaliser la sécurité avec un annuaire LDAP et/ou un annuaire personnalisé décrire les principes de SSL et l'utiliser pour sécuriser les connexions décrire le fonctionnement d'un registre d'utilisateur personnalisé.

38 Étapes pour la sécurisation d’application
Installation et configuration d'un serveur IBM Directory Server; Utilisation d'un annuaire LDAP comme registre d'utilisateurs pour WebSphere; Configuration de SSL pour sécuriser les connexions; Utilisation d'un registre personnalisé pour les utilisateurs WebSphere.

39 La sécurité sous WebSphere
Peut être découpées en deux catégories de sécurité: La sécurité globale. La sécurité applicative.

40 I- La sécurité globale S'applique à toutes les applications fonctionnant sur le serveur. Définit le type de registre utilisateur utilisé, les méthodes d'authentification…  Configs accessibles depuis la console d'administration. Toutes les configs données dans cette console agiront comme valeur par défaut pour toutes les applications.

41 II- La sécurité applicative
Définit les besoins spécifiques d'une application. Permet de spécialiser ou complémenter des configurations générales et peut aussi permettre de contourner certaines configurations. Si l'application gère des ressources spécifiques, différents types d'utilisateurs,... elle peut redéfinir des droits qui lui seront propre.

42 La sécurité sous WebSphere

43 Les registres utilisateurs (Pluggable User Registry)

44 Les registres utilisateurs
Stockent les noms d'utilisateurs et le nom des groupes d'utilisateurs. Trois types de registres de base sur le serveur: Local operating system user registry LDAP user registry Custom user registry Toutefois, WebSphere ne peut utiliser plusieurs registres utilisateurs en même temps pour l'authentification des utilisateurs.

45 1. Local operating system user registry
Permet d'utiliser le système d'exploitation sur lequel est exécuté WebSphere pour extraire les noms et groupes d'utilisateurs. Si WebSphere utilise les noms contenus dans les registres systèmes, il n'en utilise pas entièrement la hiérarchie de droit et il se peut qu'un utilisateur par le biais de WebSphere acquiert plus de droit que normalement.

46 2. LDAP user registry Lightweight Directory Access Protocol
Registre d'utilisateurs. De plus la plupart des serveur LDAP disponibles sur le marché sont maintenant suffisamment équipé de mécanisme de sécurité pour être fiable et être utilisable avec WebSphere. Cependant WebSphere ne supporte pas tous les serveurs LDAP du marché.

47 3. Custom user registry Ce module laisse une porte ouverte vers une implémentation personnalisée d'un registre utilisateur. Cette interface permet aussi de définir tous les accès virtuels aux données sauvegardées (fichier sur le serveur ou depuis un serveur de BD). Il va permettre l'interaction entre le serveur d'application et les modules d'authentification.

48 Les modules d'authentifications (Pluggable Authentification)

49 Les modules d'authentifications
WebSphere fournit deux protocoles d'authentification de base : Simple WebSphere Authentification Mechanism (SWAM) Lightweight Third Party Authentication (LTPA). Ces deux protocoles diffèrent essentiellement sur leur comportement avec des applications réparties.

50 1. SWAM (Simple WebSphere Authentication Mechanism)
Protocole d'authentification qui s'adresse aux applications solitaires et simples. Inclus une restriction sur la transmission des «credentials»:  Si une servlet ou un EJB dans une application serveur 1 appelle une méthode distante sur un EJB ou une servlet fonctionnant dans un serveur 2, alors l'identité de l'appelant ne sera pas transmis à la deuxième application.

51 2. LTPA (Light Weight Third Party Authentication)
Est tout l'inverse du protocole SWAM. Entièrement destiné à une utilisation dans des applications multiples et réparties. Capable de supporter la sécurité des applications réparties à travers l'utilisation de la cryptographie. Requiert simplement l'utilisation d'un registre d'utilisateur partagé et centralisé de type LDAP.

52 Les modules d'autorisation (Pluggable Authorization)

53 Les modules d'autorisation
Sont basés sur la spécification de la J2EE. Aussi basés sur les services proposés par JAAS. Un autre mécanisme : Tivoli Access Manager Permet le déploiement rapide d'applications Web sécurisées. Gère le contrôle d'accès de tout utilisateur et navigateur Internet aux serveurs et applications web. 2 composants: Management Server (pour l’accès) et Authorization Server.

54 Les autres composants de la sécurité sous WebSphere

55 Autres composants de la sécurité
Nous allons maintenant présenter une série de composants utilisés pour la sécurité interne au serveur d'application WebSphere. Security Server Security collaborators JMX MBeans

56 Security Server C’est un composant qui est exécuté dans chaque processus serveur. Responsable de l'authentification du maintient des sessions utilisateurs Collabore avec le processus d'autorisation ainsi que le gestionnaire de registres utilisateurs.

57 Security collaborators
Ce sont des processus serveurs responsables de l'exécution des contraintes de sécurité spécifiées dans les configurations générales du serveur. Deux types de collaborateurs : Web security collaborator EJB security collaborator

58 1. Web security collaborator
Inclus dans le module Web et fournit les services: Vérifie l'authentification Effectue l'autorisation en accord avec les configurations spécifiées dans les descripteur de déploiement Effectue des logs de sécurité.

59 2. EJB security collaborator
Inclus dans le conteneur EJB et a les fonctionnalités: Vérifie l'authentification des clients Supporte la communication avec le registre utilisateur Effectue des logs de sécurité. Communique avec l'ORB (Object Request Broker) à l'aide du protocole CSIv2 (protocole OMG qui permet une meilleure interopérabilité entre les fournisseurs: JDBC, JavaMail…).

60 JMX MBeans JMX ou Java Management Extension, est une série de nouvelles interfaces et de java Beans qui permettent: de gérer la configuration la mise à jour des applications Il contacte le security server avec le but de l’authentification. Généralement utilisé afin de gérer les différentes tâches, processus ou applications.

61 Pour résumer

62 Démo…

63 Conclusion La sécurisation par couche respecte les bonnes pratiques de programmation. WebSphere est donc un serveur d'application particulièrement performant pour la sécurisation d’applications. Néanmoins, WebSphere est un serveur d'application lourd. Gourmand en ressource, il n'est pas compatible tout système comme il est pourtant annoncé par IBM.

64 That’s All !! Thank you.

65 Références et Documentation