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

Sécurité J2EE avec WAS

Par: Bourgou MohsenChouaieb Sonia

GL5

INSAT2005-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 Références et documentation

Introduction à la sécurité

Les 4 Piliers de la sécurité

Authentification

Autorisation

Confidentialité

Intégrité:État du contenu Intact?

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!

Les bases de la sécurité

Cryptographie

Hachage

Signature numérique

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.

Architecture de la sécurité dans J2EE

Contrôle aux ressources systèmesJCA

JAASJCEJSSESSL

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.

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:

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.

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é.

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

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.

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).

Sécurisation d’une application J2EE

Architecture d’une application J2EE

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.

Sécurisation de la couche

présentation

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.

Méthode déclarative

Méthodes d’authentification dans une WebApp.

Configuration d’authentification.

Configuration d’autorisation.

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.

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>

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>

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>

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.

Sécurisation de la couche Métier

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

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.

Sécurisation de la couche Intégration

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.

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: * % ; ‘

Démo…

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.

Sécurité avec WAS

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é.

É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.

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.

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.

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.

La sécurité sous WebSphere

Les registres utilisateurs

(Pluggable User Registry)

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.

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.

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é.

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.

Les modules d'authentifications

(Pluggable Authentification)

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.

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.

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.

Les modules d'autorisation

(Pluggable Authorization)

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.

Les autres composants de la

sécurité sous WebSphere

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

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.

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

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é.

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…).

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.

Pour résumer

62

Démo…

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.

That’s All !!

Thank you.

Références et Documentation www.javaworld.com www.improve-technologies.com www.ibm.com www.sun.com http://www-1.ibm.com http://solutions.journaldunet.com http://www.redbooks.ibm.com http://www.bea.com