IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Microsoft Azure Discussion :

app service + sql database : bonnes pratiques


Sujet :

Microsoft Azure

  1. #1
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 925
    Points : 4 227
    Points
    4 227
    Par défaut app service + sql database : bonnes pratiques
    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.
    Kropernic

  2. #2
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    2 040
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 040
    Points : 4 147
    Points
    4 147
    Par défaut
    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

  3. #3
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    avril 2007
    Messages
    13 954
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 13 954
    Points : 24 635
    Points
    24 635
    Par défaut
    azure active directory peut etre
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  4. #4
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 925
    Points : 4 227
    Points
    4 227
    Par défaut
    Citation Envoyé par youtpout978 Voir le message
    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.

    Citation Envoyé par Pol63 Voir le message
    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.
    Kropernic

  5. #5
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    2 040
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 040
    Points : 4 147
    Points
    4 147
    Par défaut
    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

  6. #6
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 925
    Points : 4 227
    Points
    4 227
    Par défaut
    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.
    Kropernic

  7. #7
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    2 040
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 040
    Points : 4 147
    Points
    4 147
    Par défaut
    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).

  8. #8
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 925
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 925
    Points : 4 227
    Points
    4 227
    Par défaut
    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.
    Kropernic

  9. #9
    Expert confirmé

    Homme Profil pro
    Développeur .NET
    Inscrit en
    novembre 2010
    Messages
    2 040
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 040
    Points : 4 147
    Points
    4 147
    Par défaut
    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.

Discussions similaires

  1. Chiffrement Database : bonnes pratiques ?
    Par Arnard dans le forum Administration
    Réponses: 10
    Dernier message: 08/03/2018, 15h40
  2. Service avec Binder : bonnes pratiques ?
    Par ®om dans le forum Android
    Réponses: 1
    Dernier message: 16/01/2012, 12h31
  3. Trigger / appel procedure / sql dynamique / bonnes pratiques
    Par Samish dans le forum SQL Procédural
    Réponses: 9
    Dernier message: 25/03/2011, 21h56
  4. Réponses: 4
    Dernier message: 21/07/2008, 20h39
  5. Réponses: 5
    Dernier message: 21/04/2008, 15h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo