2009-05-21 4 views
1

Fondamentalement, le problème est le suivant:
Il existe une procédure de base de données stockée qui prend un nom d'utilisateur comme argument et produit des données XML en fonction de celui-ci. Il est appelé par une méthode sans arguments dans un service Web non sécurisé (appelons ce service Web WSA). Il y a aussi un autre service web (appelons-le WSB) qui est censé appeler WSA. Dans cette configuration, WSA ne devrait jamais être appelé par WSB et jamais par quelqu'un d'autre. WSB est ce que les utilisateurs appellent et c'est la façon dont ils obtiennent les données XML requises. Les services Web sont déployés sur OC4J et leur sécurité est activée. WSB est sécurisé par OC4J et est accessible en fournissant le nom d'utilisateur et le mot de passe d'un utilisateur OC4J.
Lors du test d'un service Web, OC4J met à votre disposition un formulaire dans lequel vous pouvez entrer des informations de connexion avant d'appeler un service Web. Si vous choisissez d'inclure des informations de sécurité dans l'en-tête et prévisualisez le message avant d'appeler le service, le nom d'utilisateur et le mot de passe figurent dans le message.
Mon problème est que je ne peux pas obtenir les informations de sécurité (ou au moins le nom d'utilisateur) pour atteindre l'implémentation de point de terminaison et l'appel de la procédure stockée. Jusqu'à présent, j'ai créé WSA, fait un proxy de service Web qui s'y réfère, et créé WSB basé sur le proxy.
Ce que j'ai essayé jusqu'à présent d'obtenir le nom d'utilisateur (et pourquoi il ne fonctionne pas):Comment envoyer un nom d'utilisateur entre des demandes de service Web?

  1. Had WSA mettre en œuvre javax.xml.rpc.server.ServiceLifecycle. Cela fournit WSA avec une instance de javax.xml.rpc.server.ServletEndpointContext, qui me fournit un java.security.Principal. Cependant, Principal est null si j'appelle WSB (qui à son tour appelle WSA). Si je sécurise WSA et l'appelle directement, le Pricipal n'est pas nul et contient l'utilisateur (mais cela ne résout pas le problème, car je dois appeler WSB, pas WSA).

  2. Gestionnaires créés (extension javax.xml.rpc.handler.GenericHandler) pour les deux services, qui étaient supposés pouvoir traiter le message. Une chose m'a vraiment déconcerté ici. Les méthodes du gestionnaire sont appelées correctement - le gestionnaire WSB gère la demande, puis le gestionnaire WSA gère la demande, puis le gestionnaire WSA gère la réponse et enfin le gestionnaire WSB gère la réponse. Mais quand j'ai essayé d'imprimer les messages dans un fichier à chaque étape, j'ai découvert que même à la première étape (lorsque WSB gère la requête) il n'y a pas d'informations de sécurité dans le message. Aucun nom d'utilisateur, rien. Le message est en fait assez différent de ce qui est affiché sur la page d'invocation lors de l'aperçu du message de demande avant d'appeler le service.

  3. Essayé d'injecter une instance de WebServiceContext en utilisant l'annotation @Resource, mais apparemment OC4J ne le supporte pas.

Si quelqu'un peut faire la lumière sur l'endroit où je pourrais faire quelque chose de mal, je serais très reconnaissant.

Répondre

1

Le problème est que "WSA est appelé par une méthode sans arguments dans un service Web non sécurisé". Donc, il n'y a pas de contexte de sécurité pour que WSA prenne l'identifiant d'utilisateur de ...

La solution la plus simple pourrait être de changer l'API WSA pour accepter un identifiant d'utilisateur dans les paramètres de la requête.

HTH Tom

Questions connexes