2

Nous avons une application qui s'adresse aux utilisateurs internes et aux clients externes. Nous souhaitons nous authentifier contre AD pour les utilisateurs internes et contre l'adhésion SQL pour les clients externes. Quelqu'un at-il pris une approche similaire? Aussi, quelle est la meilleure façon d'authentifier contre AD quand dans une zone démilitarisée? Je préfèrerais avoir un proxy quelconque dans le dmz et gérer l'authentification contre les DC AD sur notre réseau interne. Aucune suggestion?Authentification par formulaires contre plusieurs fournisseurs (SQl et AD)

TIA, Kevin

Répondre

1

Nous avons une situation similaire. Nos utilisateurs Internes vont contre AD les gars externes contre un magasin ADAM. Différent de votre approche de base de données, mais similaire en ce sens qu'ils ont deux magasins d'utilisateurs. Notre authentification contre AD se produit dans la zone sécurisée, les serveurs Web de la zone démilitarisée effectuent un appel de service Web dans la zone sécurisée pour l'authentification. Je ne sais pas ce que vous recherchez, mais votre approche semble correcte.

EDIT pour répondre commentaires:

  • Le magasin ADAM ne sont pas synchronisées avec la base de données.
  • Fondamentalement, il y avait deux fournisseurs que le service Web a été configuré pour utiliser, un pour chaque magasin. En fait, il y en avait trois pour une période de temps où les utilisateurs ont été migrés à partir du système existant. Pour déterminer dans quel magasin un utilisateur se trouvait, l'application demandait simplement le fournisseur le plus commun en premier (ADAM dans notre cas) et si l'utilisateur n'existait pas, il passait au fournisseur suivant.
  • Le point de terminaison était le service Web, à l'intérieur du pare-feu, s'exécutant sur un serveur de niveau intermédiaire. Ce serveur a exécuté IIS, donc techniquement, c'était un serveur web, mais en fait notre serveur de niveau intermédiaire car il ne servait aucune page ou hébergeait autre chose que quelques services Web.
  • Il semble donc que vous avez 2 types d'utilisateurs externes. Ceux qui sont vraiment des utilisateurs internes (en AD) et ceux qui sont vraiment externes (en DB). Ce n'est pas très élégant, mais vous pourriez avoir 2 écrans de connexion, un pour chacun. Ne publiez pas l'écran de connexion externe des utilisateurs internes à quiconque sauf eux, et publiez le vrai écran de connexion externe au monde. Un peu hacky mais ça marcherait. Dans le cas contraire, vous vous connecterez le processus devra identifier le type d'utilisateur.
+0

Quelle approche avez-vous utilisée pour déterminer à quel utilisateur du magasin s'authentifie? Ou est-ce que la base de données ADAM est synchronisée avec votre AD? L'approche du Webservice est intéressante, est-ce basé sur quelque chose que vous pouvez partager ou propriétaire? Si vous ne pouvez pas partager la source, pouvez-vous partager l'architecture? Le point de terminaison est-il un autre serveur Web dans votre pare-feu ou avez-vous créé un service Windows en tant que point de terminaison? –

+0

Dans notre cas, les utilisateurs internes sont principalement externes aux locaux. Ils accèdent donc au serveur Web de la même manière que les clients externes. Je voudrais juste qu'ils puissent utiliser leurs identifiants AD au lieu d'avoir un compte séparé et un mot de passe sur le serveur web. Je voudrais éviter les approches comme créer un serveur web séparé à l'intérieur du pare-feu et avoir des utilisateurs "internes" qui s'y connectent, etc. –

Questions connexes