Есть ли способ, которым я могу дать разрешения на основе групп активного каталога в моем веб-приложении asp.net? - PullRequest
Новая
       29

Есть ли способ, которым я могу дать разрешения на основе групп активного каталога в моем веб-приложении asp.net?

3 голосов
/ 08 ноября 2011

Я пытаюсь добиться следующего:

  1. Аутентификация пользователей по Active Directory.
  2. Если пользователь относится к группе "A", я хочу ограничить права пользователя
  3. Если пользователь принадлежит группе "B", я хочу, чтобы в моем коде была другая логика.

Я могу достичь первого в приведенном выше списке.

Я использую проверку подлинности с помощью форм в своем веб-приложении (Intranet). Я провел некоторые исследования, и существуют различные предложения по использованию режима приложений Microsoft Active Directory (ADAM), о которых я полностью не знаю. без использования ADAM? Скажем, предположим, получить список групп в коде и на основе этого я могу сделать звонок, если пользователь принадлежит какой-то группе и т. Д.

Это то, что я думаю только на уровне группы, что ограничивает мои возможности? Или есть какой-то способ, кроме как предоставить пользователю права доступа на уровне группы или я совершенно не понимаю концепцию аутентификации Active Directory?

Ответы [ 2 ]

3 голосов
/ 08 ноября 2011

Проверьте этот вопрос, это та же проблема, хотя и по-разному описанная: Проверить имя пользователя и пароль в Active Directory?

В любом случае ActiveDirectory полностью поддерживается в C #, нет необходимости в дополнительных системах (я не знаю, что такое ADAM).

Чтобы проверить группы имени пользователя, используйте этот код: 

UserPrincipal p = UserPrincipal.FindByIdentity(
domainContext, IdentityType.SamAccountName, userName);
var groups = p.GetGroups();
foreach (GroupPrincipal g in groups) { /* do something */ }
2 голосов
/ 08 ноября 2011

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

По сути, кажется, что вам необходимо контролировать действия пользователя на более детальном уровне, чем на основе только групп.Членство в группах иногда может быть очень широким.Например, не у каждого в «Пользователях» могут быть одинаковые права, и не у всех в «Продажах» будет одинаковый доступ.Но тогда вам не нужно создавать группы, такие как «Менеджеры по продажам», «Продажи - Сотрудники», «Менеджеры по продажам» и т. Д. И т. Д. Это быстро становится громоздким.И независимо от того, сколько времени вы потратите на разработку идеального распределения групп, через несколько лет все изменится, потому что некоторым подгруппам менеджеров по продажам будет разрешено делать что-то, чего не могут другие менеджеры по продажам.

Чтобы обойти эту проблему, используется проверка подлинности на основе утверждений.Вместо того, чтобы указывать права на уровне членства в группе, вы просто проверяете в своем коде, есть ли у пользователя определенная «Заявка».Вы можете сходить с ума и создавать столько претензий, сколько имеет смысл для вашего приложения.Вы можете иметь такие претензии, как «Можно изменить дату рождения», «Можно авторизовать платеж на сумму, превышающую 1000 долларов США» и т. Д. И т. Д.

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

Теперь, как пользователь получает эти «претензии», которые вы спрашиваете?Ну, если вы используете ADFS, в любом случае вы хотите.Очевидно, вы можете сделать это на основе членства в группах AD.Вы можете сделать это на основе поиска в базе данных.Вы можете сделать это во время дня или месяца года, если вы того пожелаете.

Дело в том, что теперь выдача ваших претензий и обеспечение претензий полностью независимы и могут меняться независимо, не влияя друг на друга.В вашем коде просто сказано: «Эй, у этого парня есть претензия, которая позволяет ему делать платежи на сумму более 1000 долларов, поэтому я позволю ему сделать это. Почему у него есть такая претензия, я не знаю или не волнуюсь».Тогда ваша ADFS может выдавать заявки на основе любых критериев, которые она сочтет нужными.Например, «если пользователь является членом группы менеджеров или имеет запись в таблице SuperUsers в базе данных безопасности или имеет имя« Тим Тимский », ему разрешено потратить более 1000 долларов»

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

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

Как всегда, чистое преимущество от разделения двух частей зависит от того, как часто одна изменяется независимо от другой.

...