Discussion :

[baptx]

Bonjour à tous,

Je cherche depuis déjà un petit moment une solution à mon problème mais j'avoue que je suis perdu. Je vais donc vous expliquer le contexte de mon application et ensuite ce que je souhaite faire, en espérant que quelqu'un saura m'aider.

Dans le but de me connecter à un cube sur SQL Server Analysis Services (SSAS), j'utilise la dll fournie par Microsoft : msmdpump.dll (plus d'infos ici). Pour le moment, la connexion est en mode Anonyme, et donc quand l'utilisateur se connecte à la DLL, IIS utilise l'utilisateur autorisé à se connecter à SSAS.

Maintenant, j'aimerai faire un site web qui utilise un plug-in pour naviguer de façon graphique dans le cube, en l'occurrence Flexmonster.

Mon problème est le suivant : Une fois que le site web sera publié, n'importe quel utilisateur qui se connectera aura accès au cube. Je pourrai rajouter une couche de connexion avant l'accès au cube, mais du coup n'importe qui utilisant un sniffer de requête HTTP trouvera l'url de connection au cube en clair. Et aura donc accès au cube de façon anonyme.

La solution serait donc d'activer l'authentification directement sous IIS. L'utilisateur se connectant au site rentrerait ses informations Active Directory, et IIS exécuterait la DLL sous ce compte. Comme ce compte aura accès à MSAS, alors il se connectera au cube.

J'ai lu sur les docs Microsoft que pour se connecter à Active Directory, il fallait utiliser l'identification Windows avec NTLM. Mais il y a aussi écrit que pour un usage Internet, cela n'était pas recommandé et qu'il fallait notamment que le client et le serveur soient sur le même domaine, ce qui n'est pas le cas ici.

J'ai aussi trouvé un article sur l'impersonnalisation, mais cela ne permet pas de résoudre mon problème car le site sera toujours exécuté sous un seul utilisateur autorisé.

Je recherche donc un moyen, à partir d'un site web, de s'identifier en rentrant un login / pass. Ce login / pass sera envoyé à IIS qui ira vérifier dans Active Directory si cet utilisateur est reconnu. Si c'est le cas, alors l'instance du site web sera exécutée sous cet utilisateur et il pourra se connecter à la dll.

Si quelqu'un a déjà eu affaire à ce cas de figure, je suis preneur.

N'hésitez pas à renommer ce topic si le titre n'est pas clair, ou à le déplacer dans une autre rubrique le cas échéant.

Merci beaucoup de votre aide.

[juno107]

Je pense que la plus fiable des solutions serait d'installer un certificat pour accéder à ce module; oui, je sais, c'est lourd mais quoi de plus pratique pour un utilisateur d'accéder à du contenu protégé depuis le web?

[Michaël]

Bonjour

J'ai lu sur les docs Microsoft que pour se connecter à Active Directory, il fallait utiliser l'identification Windows avec NTLM. Mais il y a aussi écrit que pour un usage Internet, cela n'était pas recommandé et qu'il fallait notamment que le client et le serveur soient sur le même domaine, ce qui n'est pas le cas ici.

En utilisant NTLM :
En fait, techniquement, tu n'es pas obligé d'avoir le client et le serveur dans le même domaine AD. Il suffit de connaitre un login de l'AD et c'est bon En revanche, c'est la sécurité qui en prend un coup : je me connecte sur un pc lambda (non contrôlé par l'IT de ton entreprise) donc tu vas pas savoir dans quel état est ce poste. Ca se trouve, il est vérolé jusqu'à la moelle (ou quelqu'un de mal intentionné est dessus) et va donc pourrir ton appli/réseau. Evidemment, le même principe s'applique à un poste de ton réseau mais il y a normalement moins de chances qu'il représente un danger. NTLM est attaquable selon la version de l'OS utilisé donc ça peut représenter un problème de sécurité aussi.

En utilisant kerberos :
Là il faut que le poste soit dans le domaine (mais pas forcément dans le même réseau, en vpn ça passe). Kerberos est très sensible à l'heure : il ne faut pas plus de 5 minutes d'écart entre le serveur et le client sinon plus rien ne marche. C'est plus sécurisé mais pas utilisable sur un pc lambda.

Je recherche donc un moyen, à partir d'un site web, de s'identifier en rentrant un login / pass. Ce login / pass sera envoyé à IIS qui ira vérifier dans Active Directory si cet utilisateur est reconnu. Si c'est le cas, alors l'instance du site web sera exécutée sous cet utilisateur et il pourra se connecter à la dll.

Ce qu'il te faut, c'est en réalité ADFS (Active Directory Federation Services). Il s'agit d'un serveur qui va faire l'interface entre une source d'authentification (ad interne notamment) et ton serveur IIS. L'idée, c'est :
- Tu te connectes sur IIS sans être identifié
- IIS n'a pas reçu de ticket d'authentification : tu es redirigé vers ADFS
- Tu t'authentifies avec ton login sur ADFS : il va te filer un ticket d'authentification. A partir de ce moment, tes identifiants ne seront plus transmis sur le réseau.
- Tu es redirigé automatiquement vers IIS : il voit le ticket d'authentification et va le valider. Une fois que c'est fait, tu as accès aux ressources. Lors d'un changement de page (selon la config de IIS), le ticket sera représenté à IIS et tu seras authentifié directement (sans à transférer ton mot de passe encore une fois sur le réseau).

La mise en place d'ADFS (v2) est pas forcément évidente : il faut prendre le temps de bien lire technet. L'avantage d'ADFS, c'est que tu pourras fédérer (c'est sa fonction première ) d'autres sources d'authentification. Par exemple, tu pourras fédérer l'AD d'un client qui veut accéder à tes ressources. Le client se connectera avec ses identifiants de son réseau et sera authentifié chez toi… à condition bien sûr d'établir des relations de confiance entre vos serveurs

Ah oui, j'allais oublier : il faut utiliser https avant même de commencer à toucher à l'authentification ! On protège d'abord les communications puis la session utilisateur