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

Question

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

Для примера:

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

Answer 1

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

Answer 2

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

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

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

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

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

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

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

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