2010-11-16 4 views
1

Si je souhaite déployer des applets à privilèges élevés, ils doivent être signés. Pour cela, un certificat est créé, puis un fichier jar est signé avec un jarsigner. Après cela, dans le code HTML, il faut spécifier le code, la base de code ET l'archive (jar) que nous avons signé auparavant.Existe-t-il un autre moyen d'utiliser des applets signés?

Cependant, j'ai écrit une servlet qui agit comme deux choses:

  1. il se trouve à l'URL pointé par la base de code et sert class bytecode à l'applet.
  2. La même servlet utilise également la sérialisation pour communiquer avec l'applet. Ainsi, chaque fois que l'applet reçoit une classe, elle ne sait pas qu'elle va à la base de code qui revient à la servlet.
Presque comme une mini installation RMI mais plus simple. J'espère que vous pouvez voir le pouvoir dans cela.

Malheureusement pour les applets signés, il faut l'archive. Maintenant, le servlet est également capable de charger un objet Certificate et de l'envoyer à l'applet. Voici donc la configuration: À un moment l'applet reçoit le bytecode de classe et il a aussi le certificat. Ce serait bien si l'applet pouvait instancier toutes les classes reçues en utilisant ce certificat (sinon, le code de jar est signé et l'extérieur n'est pas ce qui provoque des messages désagréables à l'utilisateur).

Alors ma question pour vous des beaux aficionados de Java: Y aurait-il par un moyen pour moi d'utiliser les données de bytecode et le certificat d'instancier la classe comme un objet signé afin que le plugin affiche la boîte de dialogue de sécurité, accepte Teh certificat et élève les privilèges de l'objet. Ce que j'ai pu trouver est qu'il existe une classe CodeSource qui accepte l'URL et le certificat de la base de code et qui est essentielle au processus de signature. Ce dont je ne suis pas sûr, c'est comment on pourrait intercepter le chargement des classes à l'intérieur des applets pour installer des certificats supplémentaires non obtenus via un fichier JAR via archive.

Que dites-vous? Merci beaucoup.

Répondre

0

Je ne suis pas convaincu de l'utilisation de classes de chargement générées à la volée.

Cela dit, d'une manière simple et dangereux de classes ont accès complet est d'appeler ..

System.setSecurityManager(null); 

.. à un stade précoce de l'initialisation de l'applet(). Cela échouerait dans une applet en boîte de sable, mais fonctionnera dans une applet de confiance.

Une meilleure façon (plus sûre) d'obtenir le résultat souhaité consisterait à implémenter un gestionnaire de sécurité personnalisé, offrant des privilèges élevés uniquement au code provenant du serveur.

L'implémentation d'un gestionnaire de sécurité peut sembler décourageante, mais il est facile d'en faire une simple. Voir cette réponse au fil System.ext() de comp.lang.java.programming pour un exemple.

Questions connexes