Discussion :

[StripMat]

Bonjour,

Mon problème est le suivant : Je dois mettre en place des connexions sur lesquels nos utilisateurs viendront se matcher pour accéder à leurs base de donnée personnelle mais potentiellement partagée, mais malheureusement SQL Server n'autorise qu'un seul utilisateur par connexion et par base de donnée, seulement notre application sera utilisé par plusieurs types d'intervenants : Utilisateur, Assistance, Comptable et Applicatifs.

En soi, prévoir que maximum 5 utilisateurs peuvent éventuellement se connecter sur la même base en même temps, sa passe, je créé 5 connexions différentes et nos users viendraient se matcher dessus. Seulement je ne sais pas combien de comptables ou même d'applications externes peuvent vouloir intervenir en même temps sur la même base ! Je ne pense pas que créer un pool de 50 connexions par type d'intervenant soit la meilleur solution
Comment gérer ce cas ?
Scripter la création d'un couple Utilisateur / Connexion ? Le détruire après l'intervention ?

[mikedavem]

Hello,

Est-ce que ton application peut utiliser des comptes Windows et s'intègre dans un active directory ? ou tu vas obligatoirement passer par des comptes SQL Server ?

++

[StripMat]

Non, nous gardons l'authentification Windows pour nos admins qui utiliseront la console TSE, tout le reste via des comptes SQL

[mikedavem]

Je vois que tu parles d'architecture 3 tiers .. tu peux toujours passer par le compte de service applicatif pour t'authentifier sur le serveur de bases de données (impersonation). Cela t'évite de gérer individuellement les permissions sur SQL Server. Le point d'entrée reste l'application et son compte de service.

++

[StripMat]

Est-ce que tu peux développer ton idée ? je t'avoue que j'ai pas compris le principe, qu'appels-tu un compte de service applicatif ?

[mikedavem]

En architecture 3-tiers le principe est grosso.modo le suivant :

[client] --> [serveur applicatif] --> [base de données]

Le client se connecte au serveur applicatif qui se connecte à son tour à la base de données.

Tu as aussi souvent :

[client] --> [serveur web] --> [base de données]

L'utilisateur interagit avec le serveur web pour afficher les pages et exécuter certaines actions.
Le serveur web exécute les actions sur le serveur de bases de données via un pool d'application (sur IIS)

Dans ce cas comme tu peux le voir c'est le serveur applicatif / web qui se connecte au serveur de bases de données et non l'utilisateur directement (impersonation).
Néanmoins il est bien sur possible de passer de bout en bout le jeton d'authentification du client vers le serveur de bases de données mais cela nécessite l'utilisation de protocoles spécifiques pour effectuer ce que l'on appelle de la délégation.

++