Можно ли использовать AzMan для авторизации на основе ролей для объектов, которые создаются во время выполнения? - PullRequest
0 голосов
/ 24 августа 2009

Можно ли использовать AzMan для ролевой авторизации на объектах, которые создаются во время выполнения? Если да, как это можно сделать?

Например:

Если объект класса "CustomAlert" создается во время выполнения, я пытаюсь выяснить, могу ли я иметь разные правила для разных объектов класса "CustomAlert". Если объект создается с использованием идентификатора конкретного пользователя, для этого пользователя доступно больше разрешений, считающих его СОЗДАТЕЛЕМ / ВЛАДЕЛЬЦЕМ объекта. Только создатель / владелец может изменять объект.

Ответы [ 2 ]

4 голосов
/ 12 ноября 2009

Для этого, безусловно, можно использовать AzMan. Я реализовал несколько приложений с этой формой безопасности на основе ресурсов и ролей. AzMan на самом деле ОЧЕНЬ гибок, и я также внедрил иерархию ресурсов (например, безопасность файловой системы Windows) с настраиваемыми пользователями и группами и полным наследованием ролей по всей иерархии, а также возможностью запрещать операции на любом уровне. Чтобы сделать это, вам нужно понять Сферы AzMan.

Области AzMan позволяют создавать отдельные наборы ролей / операций для конкретного ресурса. Этот ресурс может быть любым по вашему выбору, это просто строковый идентификатор AzMan. Эти роли / операции являются дополнением к любым ролям, назначенным на уровне приложения.

Способ, который я реализовал ранее, заключается в использовании идентификатора объекта в качестве имени области. В идеале для простоты это должен быть GUID (хотя это делает приложение MMC очень грязным), но в равной степени вы можете использовать формат «type-id», то есть «CustomerAlert-1» (намного более дружелюбный в приложении MMC). Выполняя AccessCheck в azman, вы передаете имя области AccessCheck (на данный момент она занимает только одну область, хотя определение AccessCheck допускает массив).

Я рассмотрю пример того, как это сделать (для всех, кто борется) ...

  1. Создание операций, таких как CustomerAlertView, CustomerAlertEdit, CustomerAlertDelete на уровень приложения.
  2. Создать роль определение называется CustomerAlertOwner на уровне приложения.
  3. Добавить все операции для CustomerOwner роль.
  4. В вашем приложении создайте Scope называется "CustomerAlert-1".
  5. Создать Назначение роли называется "Владелец" на сфера.
  6. Добавить CustomerAlertOwner определение роли для роли «Владелец» назначение.
  7. К этой роли владельца добавьте клиент / пользователь "Дейв".
  8. Теперь, когда вы делаете проверку доступа в скажем DeleteCustomerAlert (), вы просто передать идентификатор CustomerAlertDelete операция и тип / идентификатор объекта, который вы хочу удалить как область видимости т.е. "CustomerAlert-1"

Для проверок доступа на основе свойств объекта (т. Е. Блокировки чтения / записи определенных свойств) есть два подхода, о которых я могу подумать. Во-первых, это назначить операции в области объектов для каждого свойства и типа доступа, т.е. PropertyNameGet, PropertyNameSet, PropertyAddressAdd. Это можно упростить, создав операции на уровне приложения и используя задачи / роли для группировки часто используемых наборов разрешений. Другой способ - использовать область действия для каждого свойства (CustomerAlert-1-Name), но это может быть грязно и не так эффективно, так как вам потребуется отдельно загружать несколько областей при доступе к данному объекту.

Вы должны иметь в виду, что вы не можете явно отрицать операцию в AzMan, вы просто не назначаете роль пользователю в приложении / области. Это означает, что определенные типы иерархий ресурсов (групп / пользователей) и т. Д. Могут быть более сложными при реализации.

Если вам нужна дополнительная помощь с AzMan, не стесняйтесь спрашивать. Я рассмотрел большинство сценариев.

0 голосов
/ 24 августа 2009

Azman поддерживает безопасность на основе ролей, но она основана только на ролях, а не на ACL.Если конкретный пользователь вошел в систему, то у него есть определенные разрешения, основанные на том, кто он, но эти разрешения являются просто статическими значениями - их можно было бы применять для применения ко всем объектам данного типа, но не различать в соответствии с конкретными атрибутами определенныхэкземпляры этого типа.

...