Discussion :

[Kropernic]

Bonjour à tous,

Je vous écris car je suis à la recherche des bonnes pratiques pour ce qui est de la connexion à une base de données Azure Sql Database depuis un App Service hébergé dans Azure lui aussi.

Jusqu'ici, je faisais du développement d'applications desktop dans un environnement entièrement sous windows avec active directory et la connexion à la base de données utilisait la sécurité intégrée ("Integrated Security = true" dans la chaîne de connexion).

Ce qui permettait, par exemple, d'avoir dans des tables, une colonne de type string avec comme valeur par défaut SYSTEM_USER et d'ainsi avoir le login du user ayant créé la ligne dans la table.

J'aimerais, dans l'idéal, parvenir à reproduire le même comportement (l'utilistion de SYSTEM_USER) en provenance d'une application web. Mais jusqu'ici, ce que je vois partout c'est que, si chaque utilisateur à bien son login/password pour s'authentifier dans l'application, pour ce qui concerne la connection à la base donnée, il s'agit du même utilisateur pour tout le monde avec login/password directement dans la chaîne de connexion.

Conclusion, je peux toujours bien utiliser SYSTEM_USER mais c'est le même login partout. C'est donc sans intérêt. Ce qui a poussé les développeurs ayant démarré le projet à faire l'assignation de cette colonne d'audit au niveau du code métier dans l'app service. Transformant, de fait, cette information en information métier. Alors que ça n'a rien à faire là.

J'ai fait quelques recherches via google mais je ne dois pas avoir les bons mots clefs car je ne tombe que sur des pages expliquant juste comment se connecter à une base de données.

Je fais donc appel à la communauté en espérant avoir au moins un début de piste pour continuer mes recherches.

Merci d'avance.

[youtpout978]

Bonjour,

tu l'affectes bien en code depuis l'application web, il n'y a que là que tu sais quel utilisateur est connecté, souvent on utilise l'User Identity Name
https://docs.microsoft.com/fr-fr/dot...tframework-4.8

[Pol63]

azure active directory peut etre

[Kropernic]

Bonjour,

tu l'affectes bien en code depuis l'application web, il n'y a que là que tu sais quel utilisateur est connecté, souvent on utilise l'User Identity Name
https://docs.microsoft.com/fr-fr/dot...tframework-4.8

C'est ce qui fait actuellement. Le user est setté coté c# et c'est un "user générique" (un même login/password pour tous les users) qui est utilisé pour se connecter à la db.

azure active directory peut etre

C'est ce je suis en train de regarder. J'ai p-e trouvé une piste via les managed identities mais pas encore convaincu.

Apparemment, les managed identities permettent de dire au niveau d'azure qu'une ressource A à le droit de se connecter à une ressource B.

Ca ne règle pas mon problème mais au moins, ça retire le login/password du user générique de la chaîne de connexion.

---------------------------------------------------------------
Sinon il y a aussi la méthode bête et méchante qui doit être possible.
Pour chaque client (au sens économique ici --> customer), on crée un groupe dans l'AAD et le login équivalent dans l'Azure Sql Database. Et pour chaque utilisateur de ce customer, on crée un user dans l'AAD et on l'ajoute au groupe.

A partir de là, il doit y avoir moyen de faire qqch. Mais le nombre de user dans l'AAD est limité à 500K en gratuit et après, c'est minimum 5€/user/mois. Si l'application fonctionne, ça peut vite coûter cher.

[youtpout978]

Ah mais les utilisateurs se connectent tous à un même compte

Oui intègre Azure Ad, les utilisateurs pourront se connecter avec leur compte Microsoft, en plus tu peux directement crée un modèle de projet pour sur visual

[Kropernic]

Hello.

Je suis en train de creuser l'utilisation de l'active directory comme suggéré mais il y a un élément que je voudrais clarifier histoire d'être sûr de ne pas "perdre mon temps" (j'apprends des trucs donc ce n'est pas vraiment perdu mais bon...).

Les utilisateurs qui se connectent à l'application web, sont des utilisateurs externes. Actuellement, c'est identity server 4 qui est utilisé. Mais c'est lourd, c'est une boite noire, pas sûr qu'on est besoin de tout ça.

Pour l'instant, les videos que j'ai vue parle bien de sécuriser une application web avec l'Azure AD mais je me demande s'i ne s'agissait d'application web en interne.

Dans mon cas, on parle bien d'une application qui pourrait être accédée par n'importe qui et sur laquelle il pourrait créer un compte.

EDIT :

Je viens de tomber là-dessus. Si je comprends, ça semble confirmer que ça permet bien de faire ce que j'ai en tête donc banco. Il y a tout un projet github avec exemples et tout donc j'vais creuser ce machin mais ça a l'air prometteur.

[youtpout978]

J'ai déjà utiliser Identity Server, c'est clair qu'à première vue ça semble complexe et obscure, mais en faite c'est géniale et c'est open source, l'avantage d'Itentity server à une connexion Azure AD classique, c'est que tu peux utiliser tout un tas de provider externe style microsoft/google/github ... pour te connecter et/ou ta base perso, et aussi tu peux partager ton serveur d'identité entre tes applis pour avoir un seul portail de connexion (bon c'est la même avec Azure).

[Kropernic]

Sur le papier, juste pour identifier un user sur l'application web, oui c'est pas mal.

Par contre si je regarde plus loin et savoir qui se connecte à la db, là c'est plus compliqué.

Après, p-e que je fais fausse route. Jusqu'ici, j'ai toujours considéré que c'était l'utilisateur qui se connectait à la db pour faire l'action.
Mais on pourra aussi considérer que l'utilisateur se connecte à l'app et que c'est l'app* qui fait l'action en db. Du coup, niveau connexion à la db, c'est plus simple mais on retombe dans le cas du user générique que j'évoquais plus tôt et ne peut plus vraiment savoir qui fait quoi. A moins de s'emmerder à assigner manuellement une variable et la faire passer le réseau jusqu'à la db où elle devra être utilisée manuellement également.

* en vrai, l'app fait un call à une api et c'est l'api qui fait l'action en db

Ca fait plein d'actions "manuelles" en fait et j'aimerais autant avoir un truc full intégré le plus possible.

[youtpout978]

Oui tu fais fausse route, en tout cas dans toutes les application web on a une connection string par défaut, et pour logger l'utilisateur on le fait directement en code en récupérant l'utilisateur dans le contexte, si tu veux rester dans le même schéma, il faudrait que tu injectes les données du user dans la connection string par exemple.

En tout cas si tu stock l'utilisateur en bdd en code il faut que ça soit fait à un seul endroit, pour éviter d'oublier de le faire pour certaine tables.

Tu utilises un ORM ou tu fais tout à la mano.