La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Sécurité J2EE avec WAS Par: Bourgou Mohsen Chouaieb Sonia GL5 INSAT 2005-2006."— Transcription de la présentation:

1 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 dune 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é Authentification Autorisation Confidentialité Intégrité: État du contenu Intact?

5 Plus concrètement… Identification: qui est-ce? Authentification: est-ce bien la personne à laquelle je pense? La confidentialité: est-ce que quelquun dautre écoute et comprend? Linté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 Sorganise autour du package java.security. Inclus dans JDK à partir de sa version 1.1. Concept sécuritaire complet et puissant. Permet lutilisation dutilitaires 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: Dauthentification: déterminer lidentité de celui qui exécute le code Java Dautorisation: 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 dencryptions, de génération et de vérification de clés, dutilisation 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 limplémentation des sockets sécurisées (SSLSocket et SSLServerSocket), de managers de clés, de contextes SSL. Assure lintégrité de linformation 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 lidentité 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 dune application J2EE

17 Architecture dune 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 dauthentification dans une WebApp. Configuration dauthentification. Configuration dautorisation.

22 Méthode déclarative Méthodes dauthentification 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 dauthentification: Web.xml FORM default /login.jsp /error.jsp rolename

24 Méthode déclarative Configuration de lauthentification Web.xml BASIC basic-file

25 Méthode déclarative Configuration des autorisations: Web.xml Pages protégées /PageSecurisé.html PUT DELETE GET POST staffmember

26 Méthodes Programmatiques Les méthodes HttpServlet : getRemoteUser(): Retourne lidentifiant de lutilisateur identifié. getUserPrincipal(): Retourne un objet de type Principal caractérisant lutilisateur connecté. isUserInRole(String role): Permet de déterminer si lutilisateur 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. Laccès aux méthodes est restreint aux rôles des utilisateurs ou à dautres composants de lapplication (EJB…). Basé sur la notion des rôles en configurant le fichier ejb-jar.xml

29 Configuration de ejb-jar.xml client administrateur ReclamationEJB Remote create administrateur ClientEJB Home ajoutClient

30 30 Sécurité applicative pour les EJBs Les méthodes EJB: isCallerInRole(String roleName): si lutilisateur 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 dun utilisateur: Vérification de la taille du nom dutilisateur 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 dapplication 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 laccè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 Cest 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 lauthentification. Généralement utilisé afin de gérer les différentes tâches, processus ou applications.

61 Pour résumer

62 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 dapplications. 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 Thats All !! Thank you.

65 Références et Documentation


Télécharger ppt "Sécurité J2EE avec WAS Par: Bourgou Mohsen Chouaieb Sonia GL5 INSAT 2005-2006."

Présentations similaires


Annonces Google