1 / 65

Sécurité J2EE avec WAS

Sécurité J2EE avec WAS. Par: Bourgou Mohsen Chouaieb Sonia GL5 INSAT 2005-2006. 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

nieve
Télécharger la présentation

Sécurité J2EE avec WAS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. JCEJava 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. JSSEJava 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> <method-permission> <role-name>administrateur</role-name> <method> <ejb-name>ClientEJB</ejb-name> <method-intf>Home</method-intf> <method-name>ajoutClient</method-name> </method> </method-permission> </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.

More Related