Блог

Мы пытаемся создать веб-приложение для интрасети, и мы хотели бы, чтобы пользователи могли просто использовать свои учетные данные домена для входа на наш веб-сайт и автоматически регистрироваться. Весь пример кода, который я видел с Identity, показывает, что пользователи переходят на страницу регистрации в AccountController, и UserManager используется для создания пользователя там.

Поскольку мы требуем аутентификации на всех страницах, пользователь в настоящее время просто перенаправляется на вход в домен (в настоящее время мы используем активный домен Azure), а затем возвращается на нашу страницу. Похоже, что поведение Identity по умолчанию заключается в том, чтобы не создавать пользователя в базе данных приложения, когда это происходит, поэтому мы получаем аутентифицированный идентификатор и не соответствующий пользовательский объект в нашей базе данных. Есть ли подходящее место для подключения для создания этого пользователя? Каков наилучший способ создать пользователя? И как таблица UserLogin влияет на это, я предполагаю, что она каким-то образом используется для сопоставления ClaimsPrincipal с пользователем базы данных приложения?

Мы используем MVC 5, Entity Framework 6 и WIF 2

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

Я делаю предположение, что вы хотите создать какую-то таблицу пользователей, чтобы вы могли хранить данные профиля пользователя и / или некоторые утверждения авторизации для каждого пользователя. Вы все еще можете это сделать. Например, вы можете создать таблицу в базе данных SQL (или любой другой базе данных, которую вы хотите) для хранения записей профиля пользователя. Хорошим моментом расширения в вашем коде для такого рода вещей является получение класса из ClaimsAuthenticationManager и переопределение метода аутентификации. Здесь вы можете проверить утверждения для входящего аутентифицированного пользователя, посмотреть дополнительные утверждения профиля, которые вы сохранили для пользователя в таблице базы данных, а затем добавить эти утверждения в набор утверждений для ClaimsPrincipal . Одним из утверждений, которые вы получите от Azure AD во входящем основном объекте, является objectidentifier. Это было бы хорошим ключом для вашей таблицы профилей пользователей, чтобы вы могли правильно идентифицировать пользователя при последующих входах в систему.

Альтернативой только что описанному мной подходу к таблице профилей пользователей, который вы, возможно, захотите изучить, является возможность расширения схемы Azure AD с помощью Graph API. Я лично еще не пробовал этот метод. Это также все еще в предварительном просмотре. Но общая идея заключается в том, что вы можете зарегистрировать расширение для своего приложения интрасети, которое будет включать дополнительные свойства для каждого пользователя.