Аутентификация Active Directory с авторизацией на основе локальных ролей

Question

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

Для авторизации роли будут храниться в локальной базе данных (ПРИМЕЧАНИЕ: мы не можем использовать группы Active Directory для выполнения авторизации - роли должны быть локальными ролями приложений, поскольку мы поддерживаем несколько поставщиков authn, а администраторы AD не хотят создавать пользовательские группы в AD только для нашего приложения). Я ожидаю, что нам потребуется создать "заглушки" учетных записей пользователей в нашей локальной базе данных, чтобы выполнить сопоставление "Роль пользователя назначена". Эти учетные записи пользователей-заглушек также будут использоваться для указания того, какие пользователи авторизованы для доступа к приложению (не все в базе данных AD должны иметь доступ).

Ожидаемый поток управления будет:

1. Пользователь заходит на страницу входа в систему> вводит учетные данные> отправляет учетные данные на сервер приложений.
2. Приложение проверяет учетные данные против AD. На данный момент мы знаем, аутентифицирован ли пользователь.
3. Приложение проверяет SID пользователя, чтобы узнать, существует ли в локальной базе данных учетная запись "заглушки" с этим SID. Если нет, приложение отображает пользователю сообщение об ошибке "не авторизовано".
4. Приложение выполнит поиск ролей для пользователя в таблице "Пользователь назначен для ролей" в локальной базе данных.

Идентификационная информация пользователя, включая роли, будет храниться в виде утверждений, и приложение будет использовать типичные разрешения на основе утверждений (например, ClaimsAuthorizationManager).

Мой вопрос: каков наилучший способ создания "тупых" учетных записей в моей локальной базе данных? Я предполагаю, что мы должны использовать своего рода сценарий экспорта AD для экспорта учетных записей AD для тех пользователей, которым должен быть предоставлен доступ к приложению ASP.NET, а затем импортировать этих пользователей в локальную базу данных (ПРИМЕЧАНИЕ. Я ожидаю, что учетная запись-заглушка будет содержать минимальную информацию - возможно, только SID пользователя из AD и, возможно, имя пользователя).

Пакетный экспорт / импорт, вероятно, в порядке начального процесса развертывания. После того, как приложение будет запущено и новые пользователи присоединятся к организации, я ожидаю, что для предоставления доступа нового пользователя к нашему приложению потребуется более удобный механизм (кроме экспорта / импорта учетной записи нового пользователя из AD в нашу локальная база данных). Я предполагаю, что нам понадобится своего рода экран браузера пользователя, чтобы администратор нашего приложения мог просматривать каталог AD, выбирать пользователя, нажимать кнопку и затем автоматически создавать учетную запись этого пользователя в нашем приложении.

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

Answer 1

Пожалуйста, не стесняйтесь, если это может помочь вам авторизация пользовательских аннотаций

Это всего лишь обходной путь, или просто идея, а не решение...

Чтобы использовать его, вам нужно использовать только аннотацию в контроллере, например

 [ARQAuthorize]
public class BlaBlaController : Controller .....

Answer 2

В настоящее время я внедряю подобное решение. Вот как работает приложение. Я использую ASP.NET MVC 5, ASP.NET Identity 2.2.1.

Я использую Identity Framework для управления пользователями и ролями в приложении. Пользователь заходит на страницу входа, вводит свои учетные данные. Приложение проверяет базу данных приложения, чтобы узнать, существует ли пользователь. Если нет, выдает ошибку, что пользователь не существует в базе данных. Если пользователь существует, он аутентифицируется против AD. Если аутентификация не проходит, они получают сообщение об ошибке, если это не так, я создаю ClaimIdentity от пользователя из базы данных (а не от пользователя в AD) и передаю его в метод SignIn.

Мой пользователь в БД приложения имеет то же имя, что и имя пользователя AD, и я использую его в качестве своей заглушки. Я также включаю домен пользователя в БД в том случае, если у меня может быть несколько доменов, которые мне нужно поддерживать. С Identity не забудьте также заполнить поле SecurityStamp с помощью guid.

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