ASP Net Core - сочетание внешнего поставщика удостоверений с индивидуальными учетными записями пользователей для отслеживания аудита

Я создал веб-приложение ASP Net Core MVC по умолчанию с индивидуальными учетными записями пользователей. Я добавил настраиваемое поле UserID INT в таблицу AspNetUsers и связал его как внешний ключ со всеми моими другими настраиваемыми таблицами, чтобы я мог отслеживать, какие пользователи вставили / обновили записи в моей базе данных. Я сделал это, так как предпочитаю использовать поля INT для первичных ключей. В этом случае все работает нормально.

Сейчас я думаю об использовании внешнего поставщика удостоверений, такого как Azure Active Directory, однако я не могу понять, как связать пользователя в Azure AD (или любом другом поставщике удостоверений) с таблицами моей локальной базы данных для поддержания ограничений внешнего ключа идентификатора пользователя. Из всех моих исследований я не могу найти статей для этого сценария.

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

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




Ответы (1)


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

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

введите здесь описание изображения

person Fei Xue - MSFT    schedule 20.07.2017
comment
Это имеет смысл, однако означает ли это, что таблица AspNetUsers избыточна? Если вся информация о пользователе может поступать от поставщика идентификации, я предполагаю, что могу добавить свой INT PK в качестве дополнительного поля в таблицу AspNetUserLogins вместо этого, которое может ссылаться на другие мои настраиваемые таблицы, и поэтому я могу выгрузить все другие таблицы AspNet *. - person OjM; 20.07.2017
comment
Это не лишнее. Вся информация о пользователе взята из AspNetUsers таблицы. AspNetUserLogins предназначен только для учетной записи от внешнего поставщика идентификационных данных. - person Fei Xue - MSFT; 21.07.2017
comment
В чем преимущество хранения информации о пользователях как в локальной таблице идентификации (AspNetUsers), так и во внешнем провайдере идентификации? Разве это не приведет к дублированию пользовательских данных и не потребует дополнительного обслуживания? - person OjM; 21.07.2017
comment
Какие пользовательские данные вы имели в виду под дублированием? AspNetUserLogins - это хранилище информации о loginProvider. - person Fei Xue - MSFT; 24.07.2017
comment
Возможно, я неправильно понимаю, но я имею в виду таблицу AspNetUsers, а не таблицу AspNetUserLogins. Разве IDP не будет хранить ту же информацию, что и таблица AspNetUsers? Если да, то зачем хранить таблицу AspNetUsers? - person OjM; 25.07.2017
comment
Насколько я понимаю, удостоверение Asp.net не знает, какой внешний поставщик данных удостоверения будет использовать веб-приложение. Также нельзя гарантировать, что вся информация о пользователе в удостоверении Asp.net может совпадать с использованием внешнего поставщика данных удостоверения. Поэтому лучше всего использовать AspNetUsers для хранения информации о пользователе, и если учетная запись получена от внешнего поставщика данных идентификации, максимально сопоставьте утверждения, а также пользователи могут обновлять другую информацию, если поставщик данных идентификации не предоставляет. - person Fei Xue - MSFT; 25.07.2017
comment
Чтобы пользователь всегда выглядел одинаково для веб-приложения, поскольку веб-приложение будет искать пользователя только в таблице AspNetUsers. - person Fei Xue - MSFT; 25.07.2017
comment
хорошо, спасибо, теперь это имеет гораздо больше смысла. Однако в какой момент новый пользователь создается в таблицах AspNetUsers и AspNetUserLogins после создания во внешнем IDP. Является ли это частью процесса регистрации, который будет перенаправлять на внешний IDP, который возвращает новый идентификатор, и если этот идентификатор не может быть найден в таблице AspNetUserLogins, создайте новую запись в таблицах AspNetUsers и AspNetUserLogins? - person OjM; 26.07.2017