Разрешение WCF - доступ к операциям по претензиям

Question

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

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

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

• Доступа к модулю (чисто организационному)
  • Доступа к функции (доступ к функции WCF, проверяется автоматически)
    • Функции -специфические разрешения (проверяются динамически в коде)

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

• Доставка
  • может создать Пересылка
    • Можно переопределить именования
  • Может пересылку пакета
    • должны быть проверены руководителем
    • Может генерировать таможенную документацию ...

 
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 ...)

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

Answer 1

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

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

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

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

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

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

Марк