Transcript method - TeamSoftsuite

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
 Références et documentation

Introduction à la sécurité
Les 4 Piliers de la sécurité
Autorisation
Authentification
Intégrité:
État du
contenu
Intact?
Confidentialité
Plus concrètement…

Identification: qui est-ce?

Authentification: est-ce bien la personne à

La confidentialité: est-ce que quelqu’un d’autre

L’intégrité: Le contenu est-il intact, modifié?

La non répudiation: impossibilité de renier un
laquelle je pense?
écoute et comprend?
é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
JCA
JAAS
JCE
JSSE
SSL
aux ressources systèmes
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
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.
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 :



couche métier :


Sécurité limitée au niveau authentification.
Pas de découpage par rôle.
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


BASIC



On a une boîte de dialogue.
Envoi du username et password en clair.
DIGEST


2 pages: login.html et error.html
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>
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.
30
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
Démo…
62
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
