На самом деле это хорошая вещь, чтобы отделить личность от бизнес-контекста. Таким образом, у вас будет четкое разделение проблем.
Проблема , с которой вы столкнулись, заключается в том, что информация не является частью контекста .
Смешивание двух контекстов не поможет вам, и запрос обоих контекстов не является решением. Так какой самый простой способ решить это? Убедитесь, что информация становится частью контекста.
В ситуации, когда данные недоступны, вам нужно будет сделать локальную копию нужных вам данных. Поэтому, если вы хотите указать имя пользователя в отчете, вам необходимо создать локальную копию пользователя, включая соответствующую информацию.
Звучит избыточно? Ну, это не так. На самом деле так работает личность. Когда вы входите в систему с внешним провайдером, таким как Google, в таблице AspNetUsers создается локальная копия пользователя. Резервные? Нет, потому что у вас нет доступа к источнику.
То же самое здесь, конечно, вы можете иметь все приложения для доступа к хранилищу пользователей, используя UserManager. Но предположим, что вы не можете и, безусловно, это не так, как вы хотели бы этого. Только одно приложение должно отвечать за личность.
Обратите внимание, что информация о текущем пользователе доступна в претензиях. Важно понимать, что, например, User.IsInRole фактически рассматривает заявки на роль пользователя, а не таблицу AspNetUserRoles.
Для текущего пользователя убедитесь, что все претензии доступны. Поскольку вам нужна информация от других пользователей, вам необходимо хранить ее в бизнес-контексте. Вы можете выбрать какую-либо стратегию для считывания информации из утверждений при входе пользователя в систему или просто добавить функциональность для сохранения информации о пользователе.
Суть в том, что вам необходимо создать таблицу User в бизнес-контексте, содержащую информацию, необходимую для отчетов.
И поскольку это тогда часть того же контекста, вы можете просто получить к нему доступ одним запросом. Вы можете добавить столбец для ссылки на текущий идентификатор субъекта, утверждение sub в OpenIdConnect. Чтобы сопоставить это с текущим пользователем.
Затем вы можете добавить авторизацию на основе этого подпункта без фактической связи между контекстами и пользовательскими таблицами.
Пожалуйста, прочитайте мой ответ здесь, чтобы узнать больше об этом: Подходит ли авторизация на основе утверждений для отдельных ресурсов