"Langage universel par excellence, Java offre au programmeur un framework complet pour concevoir des applications client/serveur sécurisées. Tout ceci est expliqué en détail dans le présent ouvrage, véritable bible de la sécurité vue par Java."
JavaSecurity | |
| Auteur | Scott Oaks |
| Editeur | O'Reilly |
| ISBN | 1-56592-403-7 |
| Pages | 469 |
| Prix | $34.95 |
| Rédacteur | Zimm |
<!-- Ceci est a mettre comme texte de la news annoncant la revue<br/> du livre -->
Langage universel par excellence, Java offre au programmeur un
framework complet pour concevoir des applications client/serveur
sécurisées. Tout ceci est expliqué en détail dans le présent ouvrage,
véritable bible de la sécurité vue par Java.
<!-- Fin du texte de la news -->
Le livre commence par une introduction plutôt générale aux concepts de
sécurité tels qu'ils sont implantés dans Java : la machine
virtuelle, la "sandbox" qui isole le programme dans un environnement
restreint, les services système accessibles aux applications et aux
applets. Toujours sur un ton accessible au néophyte, le second chapitre
traite de la sécurité au niveau langage et des moyens syntaxiques
utilisables.
Le reste de l'ouvrage se veut sensiblement plus technique et est
organisé autour de deux thèmes principaux : le contrôle de l'exécution
et les outils cryptographiques. La première partie commence par une
présentation du chargement dynamique des classes, et des contraintes
sécuritaires qu'il est possible de mettre en place. On apprend
également comment implémenter son propre ClassLoader et
comment établir des politiques d'acceptation ou de rejet du code
chargé. Puis l'essentiel de cette partie du livre traite du contrôle
d'accès : on découvre comment interdire à une applicaiton ou une applet
certaines opérations sur le système ou, au contraire, comment accorder
des privilèges lorsqu'il y en a besoin. Tous ces mécanismes ne sont
malheureusement implantés que partiellement dans les navigateurs les
plus courants (IE/Netscape), ce qui réduit quelque peu
l'intérêt pratique de ce chapître. Enfin, un chapître plus général est
consacré à la mise en oeuvre de politiques de sécurité.
La seconde partie consacrée à la cryptographie se veut tout aussi
orientée implémentation puisqu'elle se contente de présenter les
classes Java relatives à ce domaine et à leur utilisation pour
des fins classiques ; signature numérique, chiffrement,
authentification, gestion des clefs. Le lecteur intéressé par les
algorithmes cryptographiques à proprement parler ne trouvera que très
peu d'informations ici et devra se reporter à un ouvrage plus
spécialisé dans le domaine. En principe, ces chapîtres sont accessibles
aux débutants, mais en pratique, des connaissances élémentaires (savoir
ce qu'est une clef secrète, une clef publique, une signature etc...)
seront très utiles pour aborder cette partie.
Enfin, les annexes proposent un survol rapide des outils disponibles
pour Java et fournit également quelques références et liens
concernant la sécurité informatique en général.
Dans l'ensemble, ce livre est donc résolument orienté pratique. Bien
que cela le rende d'un accès facile, cela suppose également quelques
connaissances théoriques préalables dans le domaine de la sécurité, il
s'adresse donc principalement au développeur devant déployer une
solution basée sur Java ; il conviendra moins au néophyte qui
souhaite découvrir la problématique de la sécurité au travers
d'exemples pratiques.
Rédigé dans un style concis et facilement lisible, le texte est
complété par de nombreux exemples, chaque chapître propose une
implémentation fonctionnelle utilisant les mécanismes et classes
abordés. La version visée est principalement Java Platform 2,
ce qui correspond aux versions 1.2 et 1.3 du JDK. Les versions
1.0 et 1.1 de Java étaient en effet beaucoup plus limitées
dans ce domaine, néanmoins, le livre y fait également référence et
souligne les principales différences entre les deux générations du
langage.
Pour terminer, une remarque qui a son importance : tous les exemples de
cet ouvrage ont été testés avec succès sous Linux avec le
JDK 1.2.2. Cependant, du fait des réglementations concernant
l'exportation de la technologie cryptographique hors des Etats-Unis (et
son importation en Europe) à l'heure où ces tests ont été réalisés,
toutes les bibliothèques requises ne sont pas fournies en standard avec
le JDK.
En somme, il s'agit donc d'un excellent livre, vivement recommandé dès
lors qu'on développe une application un tant soit peu "sérieuse" en
Java. Un texte clair et des exemples didactiques rendent sa lecture
aisée, à tel point qu'il risque de devenir votre livre de chevet !
Rappelons tout de même qu'il ne s'agit pas d'un ouvrage sur la sécurité
informatique en général et qu'il nécessite au moins quelques notions
élémentaires dans ce domaine.
Ce livre a été traduit en français.
Table des matières
- 1. Java Application Security
- 2. Java Language Security
- 3. Java Class Loaders
- 4. The Security Manager Class
- 5. The Access Controller
- 6. Implementing Security Policies
- 7. Introduction to Cryptography
- 8. Security Providers
- 9. Message Digests
- 10. Keys and Certificates
- 11. Key Management
- 12. Digital Signatures
- 13. Encryption
- A Security Tools
- B Identity-Based Key Management
- C Security Resources
- D Quick Reference
# Innocente question
Posté par bmc . Évalué à 1.
Plus précisemment, quels sont les domaines où il est utilisé régulièrement et où il surpasse les autres langages ?
Si j'en ai retenu quelque chose, c'est qu'il sert à décharger le serveur de tâches qui peuvent être réalisées par le client. Mais quels genres d'applications ?
[^] # Re: Innocente question
Posté par Laurent Laborde (site web personnel) . Évalué à 1.
(Ceci EST un troll)
--
ker2x
Sam? y'a ton troll favori la...
[^] # Re: Innocente question
Posté par Laurent Laborde (site web personnel) . Évalué à 1.
(Ceci EST un troll)
--
ker2x
Sam? y'a ton troll favori la...
[^] # Re: Innocente question
Posté par crusher . Évalué à 1.
Et les applets ce n'est pas le truc le plus important pour Java.
Le plus important c'est Java coté serveur.
Je bosse sur un site ou la partie web s'appuie sur des servlets+JSP(Java Server Pages) qui commnuniques avec des objets CORBA/Java.
Et bien je développe sur mon PC/Windows avec J++ par ex.: (j'utilise aussi JBuilder), je teste en local sur un apache Win32+moteur de servlet puis j'uploade mes classes sur le serveur Solaris sans rien recompiler !
Bon c'est juste pour insister sur la portabilité.
Il y a plein d'autres trucs importants: le garbage collector, la sécurité (ex.:éradication du buffer overflow), la tonne d'API dispo. ET multiplateforme (XML, SSL, BDD, ...)
Bon je dois y aler mais si vous en voulez plus n'hésitez pas à me le dire !
[^] # Re: Innocente question
Posté par Anonyme . Évalué à 0.
Java est un langage propre, objet, stricte et securisé pas comme le C ou le C++. Cette grande rigueur permet a des JVM comme HotSpot de Sun, d'optimiser à la recompilation le code, ce qui permet d'obtenir des perfomances supérieur en Java qu'avec n'importe quelle autre langage. Malgrès la surcharge du début.
Ceci va à l'encontre de beaucoup d'idées reçues.
Il y a beaucoup de personne qui ne connaissent pas java et qui pense que son seul interet, c'est la portabilité.
Erreur, actuellement, en stage je fais du developpement Java, qui pour l'instant ne tourne que sur NT (marché oblige).
voila
--
Cyrille (fiifo)
[^] # Re: Innocente question
Posté par schyzomarijks . Évalué à 1.
Bon, je sais que je n'ai pas une machine top speed Giga hertz mais je n'ai pas été convaincu. Par contre, c vrai que Java est fourit avec un nombre conséquente d'API.
[^] # Re: Innocente question
Posté par yVa Yann ARMAND . Évalué à 1.
Par contre, si tu utilise des binding sur des toolkit graphique natif et que tu n'a pas a relancer ta JVM toutes les 30 secondes, c'est pas mal (voir macOSX).
Coté serveur, Java dispose d'une api exceptionnelle, et les bonnes JVM apportent un vrai confort d'utilisation et de programmation.
Pour ce qui est du langage en lui meme, c'est un bon compromis dans le paradigme objet dynamique, mais il souffre de quelque imperfections.
Je dirai qu'il manque un peu d'ambition formaliste (pour parler comme les vrai) :-)
[^] # Re: Innocente question
Posté par Pat Le Nain . Évalué à 1.
C'est surtout un problème de consommation mémoire.
>De plus SWING a régulièrement des bogues d'affichage et n'est pas des plus réactifs.
C'est dû au fait que Swing est entièrement codé en Java (principe du Lightweight, composant dit "léger"), ce qui est plus portable (le nombre d'objets graphiques awt utilisés est plus réduit) mais demande plus de ressources.
> Par contre, c vrai que Java est fourit avec un nombre conséquente d'API.
C'est pour moi un avantage énorme sur d'autres langages (comme Eiffel qui est un très bon langage objet mais qui n'as pas/peu d'APIs).
[^] # Re: Innocente question
Posté par Anonyme . Évalué à 0.
comment explique tu que pour transformer un Integer en String on puisse faire "Integer.toString" (methode tres pratique) mais que pour transformer une chaine en entier il n'existe pas "String.toInteger" ?
Java, c'est un langage trop jeune, qui aurait pu etre propre et logique mais qui n'est a mon avis rien de tout cela. Un marketing digne de microsoft a reussi a pousser ce langage en avant, mais en terme de performances c'est une catastrophe.
En fait le seul avantage que je lui vois, c'est de simplifier la vie des developpeurs (garbage collector pour viter au programmeur d'avoir a liberer la memoire quand il n'en a plus besoin ...). Le resultat, c'est que le garbage collector amene plein de problemes que l'on aurait pas avec un langage qui materne moins les developpeurs !!!
sinon, oui JAVA est portable, mais il n'y a rien de magique a cela, puisqu'en fait il faut installer une machine virtuelle sur chaque architecture. Vous savez, si vous installez un emulateur psx sur chaque machine, on peut considerer que les jeux psx sont portables :-))
[^] # Re: Innocente question
Posté par François B. . Évalué à 1.
Je m'explique : si tu as un objet de type Integer et que tu veux sa représentation sous forme de chaîne, tu peux utiliser la méthode Integer.toString() (méthode d'instance). Il est normal que cette méthode soit dans Integer parce qu'elle s'applique sur un Integer, et de plus, qui mieux que celui qui implémente la classe Integer sait comment représenter un entier sous forme de chaîne.
En revanche, si tu as un entier (type de base int, pas un objet) et que tu veux le transformer en chaîne, tu peux utiliser String.valueOf(int i) (méthode de classe) pour toute transformation basique. int étant un type de base, il s'agit d'une règle de "bonne conduite" que d'accepter les types de base comme initialisation d'un objet. Par contre, la méthode Integer.toString(int i[, int radix]) (méthode de classe) est plus adaptée pour cette tâche parce la manipulation met en oeuvre des entiers, pas des chaînes (la chaîne est simplement le résultat).
De la même manière, dans l'autre sens, on passera de String vers Integer avec Integer.valueOf(String s[, int radix]) et de String vers int avec Integer.parseInt(String s[, int radix]) (deux méthodes de classe).
Sinon, en ce qui concerne la portabilité, la différence de Java par rapport à la plupart des autres langages, c'est qu'il a été pensé dès le départ comme un langage pouvant s'exécuter partout. C'est pour cela que beaucoup trouvent que le langage est plus limité que d'autres, simplement du fait du problème de dénominateur commun entre toutes les platteformes pouvant "exécuter" du Java.
[^] # Re: Innocente question
Posté par Anonyme . Évalué à 0.
String.toInteger() qui aurait ete logique puisque l'on a bien la methode Integer.toString()
je trouve ca pas logique du tout, avec TES arguments, c'est l'objet String qui sait le mieux comment se traduire en Integer ...
[^] # Re: Innocente question
Posté par franck (site web personnel) . Évalué à 1.
[^] # Re: Innocente question
Posté par Pat Le Nain . Évalué à 1.
$ Integer entier = new Integer(5);
$ System.out.println("valeur d'un entier = " + entier);
> valeur d'un entier = 5
De même que la concaténation de chaînes (opérateur +) est transparente (utilise la classe StringBuffer), la transformation d'une valeur en chaîne est transparente (en utilisant la méthode toString() propre à l'objet).
Une traduction explicite de l'argument de println est : new StringBuffer().append("valeur d'un entier = ").append(entier.toString()).toString()
[^] # Re: Innocente question
Posté par Chamelle Kolabo . Évalué à -1.
Sinon on peut parfaitement utiliser la puissance de java avec des langages comme tcl,scheme et python
http://www.jython.org/(...)
[^] # Re: Innocente question
Posté par MetalX . Évalué à 1.
Excuse-moi, mais ta question est un peu c... En effet, quel que soit le domaine, tu trouveras tjs qqn pour te dire que tel langage est le meilleur, et qqn d'autre pour le contredire.
Par contre, il y a des avantages a utiliser Java. Il est extremement portable, il est relativement simple et sur, et il est assez homogene. De +, si tu connais deja le C ou le C++, il n'est pas difficile a apprendre.
Voila les avantages que je lui confere, de par mon experience personnelle.
Enfin, je dirai que si tu es un programmeur C ou C++ moyen, que tu te plantes tout le temps dans tes pointeurs et que tu traques regulierement des *segmentation faults* , il serait peut etre bon que tu essaies Java, en particulier si la portabilite est importante.
[^] # Re: Innocente question
Posté par Anonyme . Évalué à 0.
on peut pas créer un Vector de Integer, il faut créer un Vector (de Object) et faire un cast avec (Integer) dès qu'on veut utiliser un élément du Vector.
Celà dit, il semblerait qu'il soit question de remédier à ce pb (et à qq autres) dans une version future.
Sinon, c'est vraiment top comme langage grâce aux api bien conçues (thread, rmi, ...).
# Tant qu'on y est...
Posté par Anonyme . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.