Проблема с вложенной авторизацией в ASP.NET Active Directory - PullRequest
Новая
       13

Проблема с вложенной авторизацией в ASP.NET Active Directory

1 голос
/ 16 августа 2010

Я работаю над внутренним приложением ASP.NET, которое использует список рассылки Active Directory для управления доступом к веб-сайту.

Однако из-за того, что этот список рассылки может содержать обапользователи и группы, мне нужно было разработать решение для проверки, может ли текущий пользователь иметь доступ к этому сайту (например, они могут быть в группе, которая является частью этого списка рассылки).Режим проверки подлинности Windows по умолчанию не поддерживает этот тип иерархической структуры.

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

Любая помощь приветствуется!

Ответы [ 3 ]

1 голос
/ 16 августа 2010

Обновление (ответ на комментарий)

Для управления разрешениями для группы используйте следующий блок xml. Обратите внимание, что это будет делать то, что вы упомянули в своем комментарии к другому ответу: это будет блокировать файлы изображений и т. Д ... тоже. 

<authorization>
      <allow roles="domain\group"/>
      <deny users="*"/>
</authorization>

Оригинал

Лучший способ - придерживаться нативных опций: почему бы не использовать поставщика членства? Поставщик членства ASP.Net может обработать все это для вас. Вы можете указать, какие группы могут получить доступ к каким страницам / каталогам, используя файлы web.config без проблем.

Проверьте эти ссылки для получения дополнительных инструкций по реализации поставщика членства Active Directory:

http://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx http://blogs.msdn.com/b/gduthie/archive/2005/08/17/452905.aspx

Этот XML показывает, как вы можете настроить ваш web.config после использования поставщика членства, чтобы он разрешал / запрещал разрешение на файлы и папки (я получил это от http://support.microsoft.com/kb/316871):

<configuration>
    <system.web>
        <authentication mode="Forms" >
            <forms loginUrl="login.aspx" name=".ASPNETAUTH" protection="None" path="/" timeout="20" >
            </forms>
        </authentication>
<!-- This section denies access to all files in this application except for those that you have not explicitly specified by using another setting. -->
        <authorization>
            <deny users="?" /> 
        </authorization>
    </system.web>
<!-- This section gives the unauthenticated user access to the Default1.aspx page only. It is located in the same folder as this configuration file. -->
        <location path="default1.aspx">
        <system.web>
        <authorization>
            <allow users ="*" />
        </authorization>
        </system.web>
        </location>
<!-- This section gives the unauthenticated user access to all of the files that are stored in the Subdir1 folder.  -->
        <location path="subdir1">
        <system.web>
        <authorization>
            <allow users ="*" />
        </authorization>
        </system.web>
        </location>
</configuration>
1 голос
/ 16 августа 2010

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

0 голосов
/ 19 августа 2011

В итоге я свернул свой собственный класс безопасности, чтобы проверить, есть ли у пользователя, вошедшего в систему в данный момент, доступ к Active Directory.

Я использовал функцию GroupPrincipal.GetMembers в System.DirectoryServices.AccountManagement пространство имен.Этот перегруженный метод, который принимает логическое значение, можно использовать для рекурсивного поиска пользователей (что удовлетворяет моей проблеме групп в группах).

Класс безопасности - это Singleton, и список разрешенных пользователей активного каталога хранится внутриСинглтон для быстрой проверки доступа.Я выбрал Синглтон, чтобы на сервере была только 1 копия этого списка.Я сохранил список разрешенных пользователей как SortedDictionary , что значительно увеличило скорость поиска.

Когда пользователь, который не существует, пытается получить доступ к сайту, появится исходный поиск пользователя.обратно отрицательный.На этом этапе класс безопасности обновляет список пользователей, сохраняя отметку времени этого обновления в списке разрешенных пользователей.Этот метод гарантирует, что это обновление выполняется не чаще, чем раз в 10 минут, чтобы пользователи не могли «забить» сайт (и обеспечить отзывчивость сайта для других пользователей).

...