Activation de l'authentification entre applications

J'ai un ensemble d'applications .NET fonctionnant dans un environnement Web public qui se connecte à un composant centralisé composé de pages Web et de services Web.Activation de l'authentification entre applications

Existe-t-il un moyen de mettre en œuvre une fonctionnalité de sécurité pour que les pages Web centralisées soient sûres de l'identité des applications appelantes? Faire une publication et fournir un paramètre de chaîne de caractères indiquant l'application de l'appelant est une solution naïve, quelqu'un peut la modifier manuellement.

Des idées? Tks à l'avance.

Source

2009-07-07 Dante

Je pense que nous avons besoin de quelques détails supplémentaires. Votre serveur, que vous avez écrit est l'application C, et fonctionne dans un environnement de confiance quelque part. Vous avez également des applications A et B que vous avez écrites et qui communiquent avec C via l'Internet public (non sécurisé). Ce qui n'est pas clair, c'est si A et B fonctionnent sur des machines approuvées. Si A et B sont dignes de confiance, c'est relativement facile. Si A et B tournent sur la machine d'un utilisateur (potentiellement) malveillant, alors vous avez un problème beaucoup plus compliqué. Ou êtes-vous inquiet que quelqu'un d'autre ait un programme D avec lequel il pourrait essayer d'accéder à C? –

A et B sont dans des machines de confiance. Mais étant des applications web, quelqu'un peut se tromper avec javascript, les paramètres de chaîne de requête, .... Si quelqu'un regarde l'application A et le voit publier en C, fournissant un paramètre disant "Je suis A", ils peuvent changer le poste et dire "Je suis B". Ce n'est pas bon;) – Dante

TLS/SSL/HTTP. Vous avez juste besoin d'activer l'authentification du client. SSL est généralement utilisé uniquement dans le scénario où le serveur doit être authentifié. Mais la fin du serveur peut également être configurée pour authentifier le client. Les certificats numériques doivent être installés aux deux extrémités. Cela utilise ensuite tout le crypto approprié pour faire le travail, à savoir. authentification publique, établissement de canal sécurisé, à l'aide de Diffie-Hellman, RSA, AES/3DES, tout ce que vous configurez.

Source

2009-07-14 14:59:02

D'autres réponses peuvent également contenir des solutions valables, mais cela semble être le meilleur pour mon scénario. J'ai déjà SSL, c'est un petit pas pour implémenter l'authentification client avec un certificat client. – Dante

Jetez un coup d'œil à this. Bon endroit pour commencer. Une autre option, peut-être avez-vous regardé OpenID?

Source

2009-07-07 15:11:46

Ce n'est pas vraiment ce dont j'ai besoin. J'ai besoin dans l'application 'C' de savoir si un post http a été généré à partir de l'application 'A' ou 'B'. Comment puis-je créer une relation de confiance entre l'application cliente et l'application serveur? Tokens et un émetteur ne résoudraient pas le problème, je pense. – Dante

Désolé n'a pas eu ce que vous vouliez dire dans le message original. Est-ce pour prévenir les attaques CSRF? Voir cet article de Phil Haack: http://haacked.com/archive/2009/04/02/csrf-webforms.aspx Il a eu un lien vers l'article de Dino Esposito et Hanselman sur le sujet. –

Va le lire. Merci pour les liens. – Dante

Affectez des clés secrètes à chaque paire client-serveur et utilisez-les pour signer les messages transmis entre le client et le serveur (en utilisant HMAC par exemple).

Source

2009-07-13 20:24:04 mrk

Si vous communiquez avec les services Web et les pages Web à l'aide de la publication http, vous évitez de placer les informations dans une chaîne de requête.

Envoie les données sur https afin qu'elles ne puissent pas être affichées.

Vous devez ensuite vous assurer que l'appel provient de votre environnement Web public. Une façon de procéder consiste à utiliser l'authentification Windows, en fonction de l'identité du pool d'applications.

EDIT 1

Jetez un oeil à ce lien: http://www.codeproject.com/KB/WCF/WCFBasicHttpBinding.aspx

Il montre comment configurer l'authentification Windows pour WCF base http obligatoire.

Source

2009-07-13 20:32:39

Je n'ai pas obtenu cette partie: "Une façon de faire est d'utiliser l'authentification Windows, basée sur l'identité du pool d'applications" – Dante

La situation actuelle:

Serveurs A, B et C sont par vous fait confiance et contrôlé. Un visiteur arrive sur le site A et visualise une page qui envoie des données au site C, et les données contiennent quelque chose comme "origine = A". Nous sommes inquiets que l'utilisateur change cela en "origine = B".

Une solution simple:

Vous contrôlez tous les trois serveurs, donc nous allons les communiquer pour vérifier les données entrantes. Par exemple, A changera "origine = A" en "origine = A & jeton = 12345", où la valeur du jeton est aléatoire. L'utilisateur essaie de l'altérer et envoie "origine = B & jeton = 12345" au serveur C. C fait un de confiance connexion à B, en disant "M'avez-vous envoyé quelqu'un avec le jeton 12345?" B dit "Non" et C sait rejeter la demande.

Cela peut être arbitrairement élaboré, selon vos besoins et si vous utilisez https. Peut-être que les jetons expirent après une certaine période. Peut-être qu'ils sont liés à l'adresse IP. Le point est que le serveur C vérifie toute information provenant de l'utilisateur final avec les serveurs A et B.

Source

2009-07-13 21:44:41 Kevin

La bonne façon de générer un tel jeton est d'utiliser quelque chose comme HMAC. Une valeur aléatoire peut être devinée, et même si vous demandez au serveur "avez-vous envoyé quelqu'un avec le jeton 12345", comment savez-vous que l'attaquant n'a pas eu de la chance? En outre, c'est une mauvaise idée de baser l'authentification sur les adresses IP. Pourquoi vous ouvrir inutilement à la possibilité d'attaques de spoofing? Les jetons sont un bon moyen de résoudre ce problème, tant qu'ils sont forts au sens crypto. – Voltaire

Je ne préconisais pas d'utiliser l'adresse IP uniquement; Je disais de ne faire confiance qu'à un jeton quand il est soumis par la même adresse IP que celle à laquelle il a été délivré. Cela ne vous ouvre pas à l'usurpation d'identité, cela empêche le détournement de session. Dans la mesure où un attaquant fait une conjecture porte-bonheur contre un jeton aléatoire, c'est aussi une menace avec HMAC [FIPS 198a, annexe B], et dans les deux cas, il est atténué en choisissant une longueur de jeton suffisante. – Kevin

-1

Peut-être regardez dans le champ HTTP REFERER. Dans certaines conditions, cela peut être considéré comme fiable. En particulier: Un site mimique n'enverra pas les utilisateurs de A à C selon HTTP REFERER.

Source

2009-07-13 21:53:44 Joshua

Vous pouvez toujours modifier l'en-tête de demande HTTP Referrer, n'est-ce pas? –

Comme je l'ai dit, cette réponse dépend d'un ensemble particulier de conditions. Il y a deux ou trois interprétations de la question et cette réponse n'est valide que pour l'un d'entre eux: un type de charpente ou XSS. – Joshua

J'utilise actuellement Http Referrer mais je cherche un moyen sûr de le faire, donc ma question. – Dante

Posez-vous des questions sur l'authentification unique? (c'est à dire.une personne authentifiée sur AppA devrait également pouvoir utiliser AppB et AppC sans se ré-authentifier)

Vous pouvez le faire par configuring the machineKey for your apps so they can share asp.net authentication tokens.

Source

2009-07-13 22:23:33 ninj

Oui, je suis, tout cela est de mettre en œuvre SSO interdomaine. Je ne peux pas voir cette technique travailler sur des applications inter-domaine car un seul cookie est émis pour toutes les applications. Et je ne veux pas partager les clés de la machine parce qu'à l'avenir, il peut apparaître une application cliente qui n'a plus de contrôle sur moi et qui n'est pas fiable. – Dante

La société pour laquelle je travaille actuellement utilise des cookies d'authentification de formulaires partagés dans toute l'entreprise en utilisant les mêmes clés machine sur chaque serveur Web. Toutefois, ce n'est pas idéal si vous souhaitez SSO à travers différents domaines et ce n'est pas très propre pour l'application Windows qui doit entrer dans la ferme Web pour utiliser les méthodes de service Web ...

Alors, où nous devons faire ce que nous utilisons SAML

Mais pour nettoyer tout cela et le rendre plus unifié et plus sûr, nous commençons à mettre en œuvre Geneva

Source

2009-07-13 22:43:23

Activation de l'authentification entre applications

Répondre

Questions connexes