Авторизация WCF - доступ к операциям через утверждения

Я пытаюсь реализовать авторизацию для службы WCF, но столкнулся с некоторыми существенными трудностями. Я думаю, мне нужно использовать гибридное решение, сочетающее пользовательскую аутентификацию и утверждения, но я не уверен, правильно ли это.

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

Пользователям могут быть назначены разрешения через интерфейс приложения. Один уровень иерархии разрешений соответствует доступу к отдельным функциям WCF:

  • Access to module (purely organizational)
    • Access to function (access to WCF function, checked automatically)
      • Function-specific permissions (checked dynamically in code)

Структура образца и использование:

  • Shipping
    • Can Create Shipment
      • Can override naming conventions
    • Can Package Shipment
      • Must be verified by supervisor
      • Могу формировать таможенную документацию ...

class ShippingService : IShippingService
{
    // Access corresponds to "Can create shipment" permission
    public bool CreateShipment(string name)
    {
        ...

        // Check the function-specific permission dynamically.
        if (!ConformsToNamingConvention(name) && !CheckPermission(Permissions.CanOverrideNamingConvention))
            return false;
        ....
        return true;
    }
}

Я думаю, что мне нужно создать настраиваемую политику авторизации, реализовав IAuthorizationPolicy. Это подключится к базе данных, получит разрешения для пользователя и добавит утверждение для каждого из разрешений. Затем мне нужно будет создать настраиваемый диспетчер авторизации, который будет сравнивать запрошенное действие со списком утверждений, чтобы определить, авторизован ли подключающийся пользователь.

Это правильный подход к этому, или я:

а) чрезмерное усложнение проблемы, или

б) неправильное использование компонентов WCF (таких как утверждения, IAuthorizationPolicy, AuthorizationManager ...)

Заранее благодарим за любую помощь и с наилучшими пожеланиями.


authentication authorization wcf
person Malcolm    schedule 18.07.2009    source источник
comment
Я удалил аспект ролей в этой проблеме после того, как marc_s подробно рассказал о том, как я планировал (не) использовать роли.   -  person Malcolm    schedule 20.07.2009

Ответы (1)


arrow_upward
2
arrow_downward

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

Если вы можете жить с заранее определенными ролями, есть несколько решений. Вы проверяли поставщика ролей ASP.NET? Он является частью более общего набора поставщиков ролей и членства в ASP.NET, но может использоваться и сам по себе.

Чтобы активировать его, используйте этот фрагмент в своей конфигурации (после того, как вы настроили базовую инфраструктуру для материала поставщика ролей ASP.NET):

<behaviors>
 <serviceBehaviors>
  <behavior name="CalculatorServiceBehavior">
   <serviceAuthorization principalPermissionMode ="UseAspNetRoles"
                         roleProviderName ="SqlRoleProvider" />
  </behavior>
 </serviceBehaviors>
</behaviors>

Единственная другая идея, которая у меня есть, - это посмотреть на диспетчер авторизации (AzMan): это набор инструментов, позволяющих указать довольно детализированные «атомарные» разрешения, которые бизнес-пользователь может затем объединить в роли и назначить им пользователей. Но в основном, в конце концов, на нижнем уровне детализированных программных функций («Задачи» в AzMan) вы снова имеете дело со статическим набором прав.

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

Марк

person marc_s    schedule 19.07.2009
comment
Спасибо, Марк - определенно хорошее замечание о динамических ролях. Мне все еще нужно предоставлять доступ к функциям для каждого пользователя, поэтому я убрал требование ролей из своего вопроса и сосредоточился на утверждениях и разрешениях. Любые мысли или предложения приветствуются! - person Malcolm; 20.07.2009
comment
Малкольм: пакет ASP.NET, конечно, также предоставляет поставщика членства, который позволяет вам иметь собственную базу данных пользователей и дает вам возможность ограничивать доступ к функциям также на основе имени пользователя. - person marc_s; 20.07.2009
comment
AzMan - подходящее решение, оно поддерживается и развивается. Фактически, в Windows Server 2008 AzMan был усовершенствован для использования SQL-сервера в качестве резервного хранилища. Наша корпоративная веб-служба использует хранилище AzMan в AD на Windows 2003. Существует клон AzMan с открытым исходным кодом под названием netsql azman, который может вас заинтересовать, хотя у меня нет личного опыта. - person softveda; 28.07.2009