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.

++

[StripMat]

Ok j'ai compris le principe, mais étant novice en base de donnée je vais plutôt vous expliquer mon objectif.

Ce que vous me proposez est en fait ce que nous avons déja mis en place. mais j'ai pour objectif de réaliser les logs de notre application et donc je souhaite pouvoir tracer un utilisateur ainsi que ses actions en bdd, c'est pour cela que je souhaite l'identifier clairement.

Voici comment cela se passe :

Lors de la connexion à notre application, notre métier interroge une base de donnée dite Générale ou sont stockés tout nos utilisateurs, s'il trouve un utilisateur, il redirige notre métier vers une base de donnée spécifique à cet utilisateur. Seulement plusieurs utilisateurs peuvent, en même temps, utiliser cette base, mais elle peut également être utilisée par d'autres entités comme l'Assistance, les admin, les comptables, ...

C'est donc la que les connexions posent problème, quelle serait la meilleur façon de paramétrer notre serveur de BDD pour pouvoir tracer un utilisateur physique mappé à une connexion commune aux autres utilisateurs ( du type User pour les utilisateurs, Compta pour les comptables, Appli pour les applications tiers, ...)

Et outre l'objectif de réaliser des logs, pour l'instant il est impossible pour User1 et User2, ayant chacun leurs base personnelle BaseUser1 et BaseUser2 et reliés chacun à un compte de connexion User d'utiliser en même temps la base BaseUser1, car SQL Server n'autorise pas deux utilisateurs reliés à un même compte de connexion d'utiliser la même base de donnée, il m'est impossible de créer un utilisateur User2 sur BaseUser1 ayant User comme compte de connexion. :/


Est-ce possible via le compte de connexion du service ? Comment ?

Je répètes que je suis néophyte, j’espère m'être fait comprendre mais pardonnez moi si je m'exprime mal

[SQLpro]

Tout est possible. Ce que vous demandez est possible. Néanmoins j'aimerais savoir :
1) pourquoi faites vous plusieurs bases de données à raison d'un par utilisateur ?
2) combien de bases à terme ?
Parce que je pense que vous faites fausse route sur votre architecture !
Multiplier le nombre de bases, si vous devez en lire plusieurs sera un véritable cauchemar en terme de performances et d'intégrité des données (elle seront toujours désynchronisées, notamment lors des sauvegardes/restaurations....)

Exposez donc clairement votre besoin en terme fonctionnel et non du point de vu théorique avec base1, base2... user1, user2.

A +

PS : je crois que vous auriez besoin d'un sérieux cours d'admin sur SQL Server !

[StripMat]

Nous avons décidé de créer une base par utilisateur pour de simples raisons de sécurité, les données y seront cryptés avec une clé propre à chaque base. Il n'y a aucune limite à terme.

Nous sommes conscient des problèmes de performances mais étant donné que ces bases n'ont aucun liens les unes avec les autres (aucune donnée à synchroniser), et qu'en plus tout ceci est piloté par des threads parallèles de notre appli métier... On limite le problème.

Nos besoins fonctionnels sont les suivant : On veut pouvoir sécuriser chacune des bases client indépendamment des autres et assurer une traçabilité des actions sur notre serveur et sur nos bases de données client; qui fait quoi et quand ?
Je précise que nos utilisateurs sont déjà défini sur chaque base client.

PS: Quand peut-on prendre rendez-vous pour le cours ?

@+

[mikedavem]

Nous avons décidé de créer une base par utilisateur pour de simples raisons de sécurité, les données y seront cryptés avec une clé propre à chaque base. Il n'y a aucune limite à terme.

Pourquoi ne pas passer par les schémas dans ce cas ?
Ceux-ci vous offrent la possibilité d'isoler la sécurité entre vos utilisateurs.

Database
- [schema utilisateur 1].table
- [schema utilisateur 1].table2
- [schema utilisateur 2].table
- [schema utilisateur 2].table2

++

[StripMat]

Merci pour votre réponse, c'est ce que je regardais ce matin, même si pour moi les notions de rôle et de schema restent flou. Je vais chercher un cours là dessus et essayer de gérer sa avec des schémas utilisateurs, comme vous me le conseillez.

[SQLpro]

Vous pouvez jeter un coup d’œil aux cours ADMIN de SQL Server chez orsys. http://www.orsys.fr/formations-sql-server.asp
Certains d'entre nous le donne régulièrement.
Pour ma part, je donne le cours QSA le 30 juin.

A +