Application Web - Authentification utilisateur sur plusieurs domaines

Question

Un de nos clients nous a contactés pour développer une application et, comme à l'accoutumée, sa portée grandit de jour en jour.

Initialement, il s'agissait d'une application dédiée, confinée au sein de leur réseau d'entreprise. L'authentification utilisateur a été établie en obtenant le nom d'utilisateur Windows de l'utilisateur et en utilisant une base de données SQLServer pour héberger les droits d'accès. Tout à fait simple.

Ils veulent maintenant ce qui suit:
- L'application doit être basée sur le Web
- L'application doit être hébergée en dehors du réseau d'entreprise
- L’authentification de l’utilisateur doit fonctionner de la même manière (pas d’utilisation de mots de passe, mais uniquement des connexions Windows)

Pour compliquer davantage les choses, ils souhaitent que les différentes fonctions de l'application soient utilisables par une autre application qui ne déclenche que des requêtes HTTP.
- L'utilisateur se connecte au réseau d'entreprise
- L'utilisateur lance une application d'entreprise
- L'utilisateur traite les détails du client
- L'utilisateur clique sur un bouton
- Une application d'entreprise envoie une requête HTTP à notre application Web hébergée
- La requête HTTP incluait l'authentification nécessaire et les détails du client
- L'authentification de l'utilisateur est complétée 'automatiquement' (aucune implication humaine)
- Les données du client sont transmises de manière sécurisée

Ils tiennent beaucoup à ce que nous le fassions à leur place car notre approche initiale correspondait tout à fait à ce qu’ils souhaitaient. Ils veulent toujours que nous fassions cela, même si de telles applications Web hébergées ne sont pas notre spécificité. Alors je m'adresse maintenant aux experts;
- Quelqu'un a-t-il des conseils sur la façon d'aborder cette question?
- Quelqu'un at-il un avertissement quant aux pièges à éviter?

Answer 1

Il s’agit essentiellement d’un accès fédéré. Vous hébergeriez un point d'authentification sur leur réseau, qui transmettrait à son tour un jeton à votre application qui l'analyserait et autoriserait (ou arrêterait l'accès). C’est assez courant et MS fournit une bonne base pour cela dans le Framework Genève . Cela fonctionnera également pour les appels de service Web, à condition qu'ils puissent modifier leur application pour utiliser WSFed en tant que protocole et dialoguer avec un service de jeton de sécurité qui émet en silence le jeton d'authentification. Dans la plupart des cas, vous utiliserez SAML pour cela. Il présente également l'avantage supplémentaire que les informations d'authentification ne sortent jamais de leur réseau d'entreprise.

La suggestion d'une authentification basée sur un certificat est intéressante, mais elle nécessite davantage de travail pour déployer une infrastructure PKI. Cela peut être coûteux.

CardSpace ne fonctionnera pas - ce n’est pas silencieux comme ils semblent vouloir. OpenID est également un non-démarreur, il n'est pas silencieux non plus.

Points supplémentaires si vous consultez Azure: les bits d’authentification d’Azure utilisent également SAML / WSFed sous le capot et contiennent des fragments de Geneva. Par conséquent, si vous passez au cloud, il vous suffira à chacun de vos clients de configurer une page de connexion au sein de leur réseau. Il vous suffira de faire confiance à cette page pour vous émettre des jetons d'authentification et les analyser conformément à vos règles.

Answer 2

Peut-être une communication WCF avec authentification basée sur un certificat, c'est-à-dire pour les utilisateurs externes qui utilisent le service fourni par l'entreprise, leur fournit un certificat valide. Cela ne nécessiterait alors pas de mot de passe d'utilisateur, mais guiderait l'utilisateur directement.

Answer 3

Avez-vous déjà consulté SAML ?

Answer 4

Découvrez Windows CardSpace , car il s'intègre à votre compte Windows et permet la connexion unique. scénario dont ils ont besoin.

Answer 5

En fonction de la structure de votre application, vous pouvez manipuler la clé machine dans votre Web.config pour autoriser les appels AJAX avec connexion unique (SSO). Cela impliquerait une petite application asp.net au sein du réseau de l'entreprise, dans le seul but de distribuer des jetons d'authentification et de rediriger vers votre application hébergée.

Si les deux applications partagent la même machineKey, le système d'authentification asp.net autorisera volontiers les utilisateurs dans votre application hébergée.

Cette approche présente des problèmes:

• Vous introduisez une autre dépendance dans votre système (l'application d'authentification au sein du réseau d'entreprise.). Ce sera une application simple, mais vous rencontrerez des problèmes lorsque vous essayez de diagnostiquer des problèmes sans accès.
• Vous avez besoin que votre service hébergé se trouve dans le même domaine que l'application d'authentification (pour que le ticket d'authentification du cookie HTTP soit transmis.)
• Vous aurez également besoin d'un certificat SSL pour que votre service hébergé sécurise les informations. (Ce n'est pas vraiment un inconvénient en soi, vous voudrez probablement le faire de toute façon.)
• Etant donné que vous et votre client aurez une machineKey partagée, vous allez lier une instance de votre application à ce client particulier.

Answer 6

J'utiliserais un fournisseur / serveur OpenID privé pour cela.