MVC6 Identity3 - Comment créer des comptes d'utilisateurs communs pour plusieurs WebApps

Question

Je suis nouveau MVC et travaille actuellement avec MVC6 (EF7, Identity3, VS2015) ...

Je voudrais créer deux WebApps différents/indépendants un domaine d'entreprise (dans différents sous-domaines). Je voudrais utiliser un système d'identité/de connexion commun/partagé pour les deux applications - en d'autres termes, j'autoriserais l'utilisateur à avoir un compte sur les deux applications.

Je n'ai pas d'option pour l'authentification de domaine (la société n'utilise pas le domaine - je sais que c'est bizarre), donc je dois? utiliser les comptes d'utilisateurs individuels ...

Quelle est la meilleure façon de créer et d'utiliser un compte d'utilisateur commun sur plusieurs applications?

En premier lieu, je pensé à créer deux DBContext différents dans les deux App: l'une pour l'identité (DB Users) et seconde pour App-connexes Db ...

Une telle approche me donnerait trois bases de données différentes:

• IdentityDb - commun pour les deux WebApps,
• App1Db
• App2Db

Cependant, j'ai des doutes si c'est une bonne pratique et la meilleure façon?

Probablement sera un seul DBContext avec la configuration appropriée, mais je n'ai pas idée où je devrais commencer. J'ai lu à propos de SSO (Single Sign On) - mais pour autant que je sache, il s'agit du processus d'authentification, donc c'est un peu plus tard - donc je ne suis pas sûr de cette direction.

Quoi qu'il en soit, vous ne trouverez pas d'exemple comment créer un compte/profil d'utilisateur commun entre plusieurs applications.

MISE À JOUR:

Ma question initiale est probablement trop ouverte ... Je voudrais demander non seulement « ce qu'il faut faire » mais aussi « comment faire MVC6 » ...

Donc, ma question supplémentaire est: comment puis-je y parvenir en MVC6? Ce que je dois faire? Peut-être un exemple?

Si je décide pour une base de données utilisateur distincte - alors du point de vue de l'application, je vais avoir deux DB? Que faire avec ceci dans le code? Devrais-je créer deux DBContexts séparés - ou juste un?

Aussi j'ai lu quelques avis ici sur le SO, que l'utilisation seule DbContext est meilleure et option plus simple ...

Quoi qu'il en soit je hier essayer travaille avec 2x DBContext - tout fonctionne lorsque je crée nouveau contrôleur pour IdentityDbContext , mais j'ai une erreur en essayant de créer un contrôleur pour le second DBContext (non associé à Identity) ...

(je l'ai mis description de cette erreur nouvelle question: MVC6 Working with two DBContexts and error when create new controller)

Merci à l'avance pour tout conseil :)

Answer 1

La réponse à votre question si avoir trois bases de données est la meilleure façon, est : Ça dépend.

La réponse à la question de savoir si c'est une bonne pratique n'est pas pertinente.

Laissez-moi élaborer.

La notion de chaque application ayant sa base de données dédiée provient de la pensée démodée. Les grandes architectures d'entreprise sont composées de toutes sortes de stockages de persistance, chacun étant choisi pour faire ce qu'il peut faire de mieux. Cela n'a donc rien à voir avec les bonnes pratiques. Vous devriez stocker les données là où elles conviennent le mieux. Jetez un coup d'œil à la conception orientée domaine et aux contextes bornés, en particulier pour mieux comprendre de quoi je parle.

Donc la question si vous avez besoin de trois bases de données, si dans votre situation particulière c'est la meilleure option, alors c'est ce que vous devriez faire. Pour compléter cette réponse, je vais décrire notre situation. Nous avons une ancienne base de données utilisateur avec des utilisateurs. Nous ne pouvons pas nous en débarrasser jusqu'à ce que toutes les applications Web aient été éliminées. Pour minimiser l'effet qu'il a sur nos clients. Donc, pour nos nouvelles applications web, nous utilisons uniquement cette ancienne base de données pour les utilisateurs et utilisons le stockage azure pour tout ce que nous avons besoin de stocker. En d'autres termes, conceptuellement, notre situation ressemble à ce que vous décrivez. Un espace de stockage séparé pour les utilisateurs que toutes les autres applications Web utilisent.

ressemble à une bonne solution au problème pour vous?

Mise à jour Quant à MVC6, Identity Server 3 spécifique. Le serveur d'identification 3 a la possibilité d'utiliser le service utilisateur personnalisé, ce qui vous permet de coupler tout stockage utilisateur souhaité. Voici les détails: https://identityserver.github.io/Documentation/docs/advanced/userService.html. C'est exactement ce que nous avons fait.

Comme pour votre autre question; nous allons probablement mettre les utilisateurs dans Azure Table Storage et le récupérer à partir de là via IdentityServer4 lorsque toutes les anciennes applications auront disparu. À l'heure actuelle, il n'y a plus rien dans l'ancienne base de données MySQL, mais des utilisateurs pour nous. Mais il y a quelques vieilles applications qui l'utilisent encore, alors ...

Est-ce que cela répond à vos questions?

Answer 2

Dans la version précédente d'ASP.NET Identity (2) partager le cookie d'identité à travers les sous-domaines était la sloution. Je ne suis pas sûr ver 3 mais vous pouvez le tester:

changement config d'identité dans Configure méthode de Startup classe:

services.AddIdentity<ApplicationUser, IdentityRole>(config => 
    { 
     config.Cookies.ApplicationCookie.CookieDomain = ".domain.com"; 
    }) 
    .AddEntityFrameworkStores<ApplicationDbContext>() 
    .AddDefaultTokenProviders();