MVC6 Identity3 - Как создать общие учетные записи пользователей для нескольких WebApps

Question

Я новичок в MVC и в настоящее время работает с MVC6 (EF7, Identity3, VS2015) ...

Я хотел бы создать два различных/независимых WebApps в один домен компании (в разных поддоменах).

Я бы хотел использовать общую/общую систему идентификации/входа для обеих приложений - разными словами я бы разрешил пользователю иметь одну учетную запись в обоих приложениях.

У меня нет возможности для аутентификации домена (компания не использует домен - я знаю, что это странно), так что я должен? используя индивидуальные учетные записи пользователей ...

Каков наилучший способ/практика создания и использования общей учетной записи пользователя в нескольких приложениях?

В первую очередь я думал о создании двух различных DbContext в обоих приложениях: один для удостоверениях (пользователей БД) и второй для App-связанной Дб ...

Такой подход позволил бы дать мне три различные базы данных:

• IdentityDb - общие для обоих WebApps,
• App1Db
• App2Db

Однако у меня есть сомнения, если это хорошая практика и лучший способ?

Вероятно, будет достаточно одного DBC-контекста с надлежащей конфигурацией, но у меня нет идеи, с чего я должен начать.

Я читал о SSO (Single Sign On) - но насколько я понимаю, это процесс аутентификации, так что это немного позже - так что я не уверен в этом направлении.

В любом случае не удается найти пример, как создать общую учетную запись пользователя/профиль в нескольких приложениях.

UPDATE:

Мой первоначальный вопрос, вероятно, слишком открытым ... Я хотел бы спросить, не только «что делать», но и «как это сделать в MVC6» ...

Итак, мой дополнительный вопрос: как я могу добиться этого в MVC6? Что мне нужно сделать? Возможно, какой-то пример?

Если я решаю использовать отдельный пользовательский БД - тогда с точки зрения приложения у меня будет две БД? Что делать с этим кодом? Должен ли я создать два отдельных DBC-контекста - или один?

Кроме того, я прочитал несколько мнения здесь на SO, что, используя только один DbContext лучше и проще вариант ...

Во всяком случае у меня есть попробовать вчера работаю с 2м DbContext - все работает, когда я создаю новый контроллер для IdentityDbContext , но у меня ошибка при попытке создать любой контроллер для второго DBContext (не связанного с Identity) ...

(я поместил описание этой ошибки на новый вопрос: MVC6 Working with two DBContexts and error when create new controller)

Заранее спасибо за любые советы :)

Answer 1

Ответ на ваш вопрос, если иметь три базы данных является лучшим способом, является : Это зависит.

Ответ на вопрос о том, является ли это хорошей практикой, не имеет значения.

Позвольте мне уточнить.

Понятие каждого приложения, имеющего свою выделенную базу данных, основывается на старомодном мышлении. Архитектуры крупных предприятий состоят из всех видов хранилищ настойчивости, каждый из которых выбирает то, что может сделать лучше всего. Таким образом, это не имеет ничего общего с хорошими практиками. Вы должны хранить данные, где они подходят лучше всего. Взгляните на дизайн, управляемый доменами и ограниченные контексты, в частности, чтобы лучше понять, о чем я говорю.

Так что, если вам нужны три базы данных, если в вашей конкретной ситуации это лучший вариант, то это то, что вы должны делать. Чтобы закончить этот ответ, я опишу нашу ситуацию. У нас есть старая пользовательская база данных с пользователями в ней. Мы не можем избавиться от него, пока все веб-приложения не будут отменены. Чтобы минимизировать эффект, который он оказывает на наших клиентов. Поэтому для наших новых веб-приложений мы используем только эту старую базу данных для пользователей и используем лазурное хранилище для всего, что нам нужно хранить. Другими словами, концептуально наша ситуация подобна тому, что вы описываете. Отдельное хранилище для пользователей, которое использует все другие веб-приложения.

звучит как хорошее решение проблемы для вас?

Обновление Что касается MVC6, то Identity Server 3 определен. Сервер ID 3 имеет возможность использовать пользовательскую службу пользователя, которая позволяет вам связывать любое пользовательское хранилище, которое вы хотите. Вот подробности: https://identityserver.github.io/Documentation/docs/advanced/userService.html. Это именно то, что мы сделали.

Что касается вашего другого вопроса; мы поместим пользователей в хранилище таблиц Azure и извлечем их оттуда через IdentityServer4, когда все старые приложения исчезнут. Прямо сейчас в устаревшей базе данных MySQL ничего не осталось, кроме пользователей. Но есть некоторые старые приложения, которые все еще используют его, поэтому ...

Ответит ли это на ваши вопросы?

Answer 2

В предыдущей версии ASP.NET идентичности (2) совместное использование куки-файлов cookie через субдомены было sloution. Я не уверен, что веры 3, но вы можете проверить это:

изменение Идентичность конфигурация в Configure методе Startup класса:

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