2009-10-23 4 views
6

Je suis en train de créer un service Web RESTful (JBoss + RESTeasy). Le programmeur de l'interface utilisateur écrit une application Web Ajax qui l'utilisera. L'application Web sera une page HTML avec tout ce qui est fait en JavaScript. Pour des raisons de sécurité, tout le trafic passe par SSL.Authentification Ajax sans laisser le navigateur ouvrir la boîte de dialogue de connexion

Actuellement j'utilise l'authentification de base. Le programmeur d'interface utilisateur peut afficher une boîte de dialogue pour obtenir un nom d'utilisateur et un mot de passe et mettre "Authorization: Basic xxxxx" dans l'en-tête. Malheureusement, si le mot de passe est faux, la boîte de dialogue de connexion du navigateur moche apparaît. En outre, il n'y a aucun moyen pour l'utilisateur de se déconnecter. C'est inacceptable.

Il semble qu'il n'y ait aucun moyen d'intercepter une réponse 401 à un XMLHttpRequest dans l'un des navigateurs que nous utiliserons.

L'authentification basée sur les formulaires ne fonctionnera pas pour nous. Nous avons besoin d'une fermeture de session automatique après une certaine période d'inactivité (l'équivalent d'un timeout de session). Le serveur ne peut pas renvoyer soudainement une page de connexion lorsque le client attend un objet JSON. JBoss propose quatre stratégies d'authentification: BASIC, FORM, CLIENT-CERT et DIGEST. Je pense que DIGEST a le même problème que BASIC. Aucun des quatre n'est ce que nous voulons. Cette application Web sera le seul client (pour l'instant), donc il n'y a pas besoin d'utiliser BASIC. Y a-t-il une autre stratégie d'authentification que je peux installer? Par exemple, existe-t-il une implémentation de WSSE UsernameToken que je peux utiliser? (Comme décrit dans le chapitre 8 du livre O'Reilly RESTful Web Services.) Le serveur enverrait "WSSE" au lieu de "Basic" dans l'en-tête WWW-Authenticate et probablement le navigateur l'ignorerait et le passerait à travers. Je veux configurer la sécurité là où elle appartient - dans les fichiers de configuration de JBoss, pas dans mon service Web RESTful - donc je cherche une implémentation que je peux simplement connecter à JBoss.

Répondre

7

Le navigateur ne présentera pas la boîte de dialogue de mot de passe s'il ne reconnaît pas le schéma d'authentification dans l'en-tête WWW-Authenticate. Le mieux est peut-être de continuer à utiliser l'authentification de base sur le serveur tout en définissant l'en-tête manuellement sur quelque chose comme "Basic/MyApp" pour les réponses 401.

+0

L'authentification est effectuée avant que la demande n'atteigne le service Web. Puis-je gérer cela en écrivant un filtre qui se trouve devant le cadre de sécurité? Ensuite, je pourrais dire au programmeur web d'ajouter un en-tête "Authorization: Basic/MyApp" à la première requête. Le filtre pourrait alors le réécrire comme "Authorization: Basic" et réécrire l'en-tête "WWW-Authenticate: Basic" dans la réponse en tant que "WWW-Authenticate: Basic/MyApp". Tous les autres clients peuvent utiliser l'authentification de base normale. Est-ce que ça va marcher? Je pense que ça pourrait. –

+0

Hmm ... Je supposais que vous aviez le contrôle sur l'authentification au niveau du script sur le serveur, et que l'en-tête serait défini après le traitement de l'authentification mais avant que vous ne retourniez une réponse. Je ne connais pas très bien JBoss, mais si vous pouvez filtrer et réécrire les requêtes avant que l'authentification n'arrive, il semblerait que ce soit votre meilleur choix. Et en définissant l'en-tête Autorisation dans l'application Web, les clients normaux ne seront pas affectés. Agréable. –

+0

Comme il se trouve, vous ne pouvez pas avoir un filtre de pré-connexion. Le serveur WebLogic le permet, mais la norme ne le permet pas et JBoss et Tomcat ne l'autorisent pas. On dirait que je vais devoir jouer avec JAAS pour faire ça. –

Questions connexes