ASP Net MVC Жила - Загрузка данных пользователя из Active Directory, когда пользователь просматривает любой страницы,

Question

Вот моя среда разработки:

• Intranet Сайт
• аутентификации Active Directory/авторизацию
• Asp Net Ядро

Я пытаюсь получить данные, хранящиеся в атрибутах Active Directory, когда пользователь впервые входит на любую страницу нашего приложения. Все права и разрешения пользователей, employeeid, studentid и т. Д. Хранятся в атрибутах AD и Группы безопасности. Некоторые атрибуты также должны отображаться на веб-сайте.

Скажем, мой сайт получил следующие ссылки ...

• http://mysite/Home/Index
• http://mysite/Student/Index
• http://mysite/Student/MyJobs
• http://mysite/Staff/Applications

и т.д ....

Любые пользователи могут свободно перемещаться по сайтам/URL-адресам веб-сайта с других порталов Intranet, и я не знаю, где я должен писать код для выполнения этих критериев. Проблема заключается в том, что нет конкретной точки входа в приложение, например, http://mysite/Login или Authenticate и т. Д. Если есть, я мог бы загружать все данные и права пользователей из AD в эту единственную точку входа.

В эпоху MVC5 я использовал Custom Global Authorize Attribute и поместил его на BaseController, наследуемый от всех других контроллеров для загрузки данных AD. Я поместил данные AD в Session при первом попадании и использовал Static Class для отображения в представлениях и использования в контроллерах. Но когда я провел некоторое исследование в MVC Core, некоторые говорят, что он устарел, и я должен использовать политику авторизации вместо пользовательских атрибутов авторизации.

Получение данных из Active Directory уже достигнуто за счет использования старых веб-сервисов, и нам не нужно беспокоиться о том, что ядро ​​.NET не поддерживает AD.

Я просмотрел учебники по вопросам политики и увидел что-то о претензиях и пользовательских менеджерах пользователей. Я не мог решить, какой из них я должен использовать для загрузки данных из Active Directory в объект (вероятно, Scoped Object DI), который длится для всего сеанса пользователя.

Должен ли я загружать данные на претензии атрибутов Ев ...

var claims = new List<Claim>(); 
claims.Add(new Claim("UserName", "John.Smith", ClaimValueTypes.String, Issuer)); 
claims.Add(new Claim("RefNo", "02343001", ClaimValueTypes.String, Issuer)); 
claims.Add(new Claim("Email", "MyEmail@email.com", ClaimValueTypes.String, Issuer)); 

Или я должен написать заказной SignInManager и IdentityUser? Например ...

public class ApplicationUser : IdentityUser 
{ 
    public string RefNo { get; set; } 
    public string Email { get; set; } 
} 

Есть ли где я мог бы поставить свой код, чтобы проверить данные AD и нагрузки? И хранить данные в этом Заявленном объекте, а не использовать данные сеанса?

Не могли бы вы, ребята, посоветуете мне? Не стесняйтесь критиковать, если я что-то пропущу, и моя идея не работает.

Answer 1

Вы правы, говоря, что пока нет служб System.Directory (это на отставание, я обещаю), поэтому есть несколько мест для этого.

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

Однако, если вы хотите поддержать механизм, основанный на формах, вы должны посмотреть на использование the cookie middleware, raw, чтобы хотя бы дать вам простой логин, вызвав ваш веб-сервис, чтобы подтвердить свой логин. Вы можете запросить свой API в коде контроллера и написать файл cookie идентификатора. Этот файл cookie автоматически зашифрован и подписан, поэтому его нельзя подделать.

Проблема возникает, когда вам нужны роли и атрибуты. Если вы отправитесь вниз по пути к файлу cookie, у вас может возникнуть соблазн поставить все те, кто претендует на личность, прежде чем писать личность в качестве файла cookie. Это может работать, если их не так много - файлы cookie имеют максимальный размер (зависит от браузера, но обычно менее 4k). Вы можете использовать куки-файлы, но здесь есть влияние производительности. Вместо этого вы можете использовать ссылочный файл cookie, где вы помещаете ссылку на другой магазин, где хранится фактическое полностью заполненное удостоверение, будь то сеанс, redis или что-то еще.

Затем в the claims transformation middleware вы можете вытащить ссылку, зайти в свой магазин и укрепить личность.

Я бы честно избегал попытки объединить все это в ASP.NET Identity. Это означает, что это единственный источник информации о пользователе в приложении, а в вашем случае это неверно. Ваш единственный источник должен быть AD.

Существует также порт Novell's ldap library к ядру, который должен хорошо стоять в DirectoryServices, если вы хотите избежать вашего подхода к веб-сервисам.