Как правильно создавать новые и использовать существующие SecurityKey

[Владимир Максимов]

При переходе на Ax2009 столкнулся с принципиально другой концепцией организации управления правами доступа по сравнению с Ax2.5 Чтобы не "наломать дров" хотел бы уточнить "как правильно" организовать это управление?

Поискал по форуму и статьям, но ответа на интересующие меня вопросы не нашел. В первую очередь интересуют ответы на следующие вопросы:

1. Следует ли при создании новых таблиц/форм/отчетов создавать новые SecurityKey или же использовать существующие 9 ключей в каждом модуле?

2. Как правило, при создании новых таблиц/форм/отчетов требуется, чтобы этот новый объект был НЕ доступен никому, кроме некоторых пользователей, список которых будет уточнен позднее. Это значит, что по умолчанию новые объекты не должны быть доступны никому (ну, кроме админа, разумеется). Можно ли это организовать без "ручного" снятия прав для новых объектов?

3. Следует ли вообще давать доступ на уровне Security Key или же следует давать доступ только на уровне объектов, подчиненных соответствующему Security Key?

Другими словами, интересует процесс организации прав доступа именно с позиции программиста. Что требуется от программиста и что он должен требовать от того, кто будет заниматься настройкой прав доступа в Ax2009?

[Ivanhoe]

Поиск по форуму результатов не дал? Система прав доступа практически не менялась с 3.0 (кроме нюансов с RLS).

Если вкратце:
1. securitykey обычно имеют двухуровневую структуру.
2. Первый уровень - модуль (раздел главного меню). Для человека, настраивающего права доступа интуитивно понятнее искать соответствующий объект именно в разрезе модуля. Т.е. если у вас не новый самописный модуль, а - стандартный, то используйте существующие ключи.
3. Условно стандартные ключи:
3.1. *Tables - все таблицы модуля должны иметь этот ключ.
3.2. Почти все остальные стандартные суффиксы применяются для menuitem - в завимости от того, обычная это форма, настройка, журнал, отчет, запрос или периодическая операция.
3.3. Отдельно выделяется *Misc - для menuitem, которые в Главном меню отсутствуют и вызываются из других форм.
4. Лучше не давать права на сами ключи (но иногда в стандарте без этого никак - проверка идет именно на сам ключ). На своих проектах стараюсь всегда настраивать права только на сами объекты, не на ключи.
5. Желательно все функциональные кнопки на формах делать через menuitem и на них вешать ключ. Настройщику прав далеко не очевидно, что ключ указан прямо на объекте формы (а еще хуже, если вообще не указан).

[Logger]

Добавлю 5 копеек.
В ax 3.0 был неприятный глюк когда добавление корневого ключа приводило к странным багам. он был например выключен у админа. странно начинали работать RLS и.т.п. В 2009-й не проверял.

По п.2 - мы для особо важного функционала создали свои ключи и делали их наследников некоего базового ключа, который был для всех групп пользователей выключен. Таким образом новый функционал был автоматом недоступен никому и не приходилось перебирать кучу групп юзеров, отключая в каждом права.
Также тут выкладывали проект
Как программно изменить права доступа на объект ?
для массовой обработки групп прав.

[someOne]

Добавлю еще кое что от себя...

В ах2009 все же есть особенности, которые требуют несколько иного подхода к настройке прав по сравнению с Ax3.0 (о чем написал Ivanhoe).

Кое что обсуждалось тут
Недостаточно прав на использование таблицы Common (DAX2009)
AOSAuthorization и права пользователей
SysDictField.visible() возвращает неверное значение

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

[Poleax]

How to: Create and Apply Security Keys

Цитата:

You need to apply a security key to:

• Tables
• Views
• Menus
• Menu items
• Form controls
• Report controls

Подробнее использование Security Keys в Microsoft Dynamics AX 2009 Development Best Practices White Paper

[Владимир Максимов]

Если я правильно понял, то основное правило работы с Security Keys заключается в следующем

1. На сам Security Keys не дается вообще никаких прав. Полный запрет. Уровень доступа = "Нет доступа"
2. Права даются на объекты, подключенные к соответствующему Security Keys

Все остальное - это уже следствие данного правила, тонкости реализации и ошибки функционала.

Другими словами Security Key выполняется функцию не собственно назначения прав, а всего-лишь предоставляет возможность настроить права подчиненных объектов. Делает не вполне то, для чего был задуман. Перестал быть "работягой" и стал "начальником"

[someOne]

Цитата:

Сообщение от Владимир Максимов

Если я правильно понял, то основное правило работы с Security Keys заключается в следующем

1. На сам Security Keys не дается вообще никаких прав. Полный запрет. Уровень доступа = "Нет доступа"
2. Права даются на объекты, подключенные к соответствующему Security Keys

Все остальное - это уже следствие данного правила, тонкости реализации и ошибки функционала.

Другими словами Security Key выполняется функцию не собственно назначения прав, а всего-лишь предоставляет возможность настроить права подчиненных объектов. Делает не вполне то, для чего был задуман. Перестал быть "работягой" и стал "начальником"

До Ax2009 все было так, в принципе.
- Если не считать кое где явную проверку прав на ключ в коде некоторого функционала (hasSecuritykeyAccess), в том числе самописного.
- Если не считать, что некоторые "Умельцы" которые делали Российский функционал в Ax3.0 "вешали" ключ прямо на меню (а не на MenuItem, это касалось например, модуля "зарплата")
В этих случаях приходится давать права на ключ а не на объект.

В Ax2009 применили странную систему. С одной стороны старая система проверки прав на объекты осталась. С другой стороны ряд функционала, (о которой описано выше) требует права на ключи а не на объекты. Например система "AOSAuthorization" работает только с правами на ключи, а не на объекты, и не всегда это легко "обойти".

Например в форме настройки стандартного фильтра Ax2009 при попытке "присоединить" источник данных другой таблицы (n:1 или 1:n) пользователь "увидит" только те таблицы, на КЛЮЧ которых у него есть права, а не на ОБЪЕКТ таблицы, на которую имеет доступ.

И еще одна особенность AX2009 по сравнению, например с Ax3.0.
Если ранее loockup поля "открывались" даже на те таблицы, на которые у пользователя прав нет, то в Ax2009 lookup так же проверяет права доступа. Если доступа на таблицу нет - открывается "пустой" lookup.

[Ivanhoe]

Цитата:

Сообщение от someOne

И еще одна особенность AX2009 по сравнению, например с Ax3.0.
Если ранее loockup поля "открывались" даже на те таблицы, на которые у пользователя прав нет, то в Ax2009 lookup так же проверяет права доступа. Если доступа на таблицу нет - открывается "пустой" lookup.

Ну как же так? Даже не поленился проверить. На какой версии 3.0 в лукапе можно увидеть данные из недоступной таблицы?

[someOne]

Цитата:

Сообщение от Ivanhoe

Ну как же так? Даже не поленился проверить. На какой версии 3.0 в лукапе можно увидеть данные из недоступной таблицы?

Только что проверил - все так.
Воспроизвел на ax3.0 Build #1951.3730/514-193 sp3/OP023-71

Приложение без всяких модификаций.

1. Создал новую группу.Нового пользователя.

2. Дал права на таблицу заказы, строки заказа, меню форму заказы. Это все.

3. Открываю под пользователем test - вижу данные из таблицы "способ поставки"

[Ivanhoe]

Цитата:

Сообщение от someOne

Только что проверил - все так.
Воспроизвел на ax3.0 Build #1951.3730/514-193 sp3/OP023-71
[/IMG]

Я на SP6 проверял.
Для чистоты эксперимента приложите скриншот с "Просмотр" не "Главное меню", а "Контроль доступа" и раскрытой веткой Основное / Таблицы и желательно там же таблицу "Способ поставки". Спасибо.

[Ivanhoe]

Продолжаем эксперимент

Цитата:

Сообщение от someOne

Например в форме настройки стандартного фильтра Ax2009 при попытке "присоединить" источник данных другой таблицы (n:1 или 1:n) пользователь "увидит" только те таблицы, на КЛЮЧ которых у него есть права, а не на ОБЪЕКТ таблицы, на которую имеет доступ.

Такое поведение не повторяется (ru6):

[someOne]

Цитата:

Сообщение от Ivanhoe

Продолжаем эксперимент



Такое поведение не повторяется (ru6):

Продолжаем...

На Ax2009 RU6

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

[Ivanhoe]

Цитата:

Сообщение от someOne

Продолжаем...
На Ax2009 RU6
Из этого видно, что право на картотеку номенклатуры у пользователя есть,
однако добавить эту таблицу в настройку фильтра в форме "заказы" он не может.

А у пользователя есть права на таблицу xRefTableRelation??

[oip]

Да, обычно именно так и поступаем. На сам ключ доступ не дается, только на нужные подчиненные объекты (про исключения уже написали). Новые ключи обычно создаются только если пишется свой модуль.

[Ivanhoe]

Согласен.

[Poleax]

2Владимир Максимов

Цитата:

Best Practice в данном вопросе бесполезен. Из него совершенно не понятно надо ли давать права на ключи или на объекты; надо ли создавать новые ключи. Он просто констатирует то, что есть сейчас

Как это бесполезен? Там четко написано как и на каких объектах использовать и как именовать ключи.

Зачем использовать ключи Applying Security Keys

Цитата:

Applying Security Keys
The main reasons to apply user-level security are to:

• Allow users to do only their designated tasks.
• Protect sensitive data in the database.
• Prevent users from inadvertently breaking an application by changing code or objects on which the application depends.

You need to apply a security key to:

• Tables
• Views
• Menus
• Menu items
• Form controls
• Report controls

Именование ключей Best Practices for Configuration and Security Keys

Цитата:

One of the nine security keys on a branch (the parent) should take the name of the module. For example, BOM. The other keys (up to eight more on a branch) should have the name of the module followed by one of the following suffixes: Daily, Journals, Inquiries, Reports, Periodic, Setup, Misc, or Tables. For example, BOMReports, BOMSetup, and LedgerPeriodic.

Enterprise Portal keys should have a prefix of EP followed by the name of the role. For example, EPAdmin and EPConsultant. Additional security keys for the role should take one of these suffixes: Misc, Info, Report, or Task. For example, EPAdminInfo and EPConsultantTask.

[Владимир Максимов]

Цитата:

Сообщение от Poleax

2Владимир Максимов
Как это бесполезен? Там четко написано как и на каких объектах использовать и как именовать ключи.

Это не то. Это рекомендации по созданию новых Security Keys и некие общие слова о том, как в принципе их можно использовать. А права доступа-то как настраивать? Не в смысле через какую форму, а сама идеология (концепция) настройки прав.

Ну, вот каким образом коррелируются те цитаты, которые Вы привели с тем что описывают в данной теме все остальные участники? Где, в каком месте Best Practices говорится о том, что надо настраивать права не самих Security Keys, а подчиненных объектов? А права Security Keys настривать как раз не надо.

[Ivanhoe]

Цитата:

Сообщение от Владимир Максимов

Это не то. Это рекомендации по созданию новых Security Keys и некие общие слова о том, как в принципе их можно использовать. А права доступа-то как настраивать? Не в смысле через какую форму, а сама идеология (концепция) настройки прав.

Если нужен официальный документ - то вот.
Там и кратко про ключи, и про концепцию и как искать сложные случаи при настройке прав )

Еще хороший блог.

[Владимир Максимов]

Цитата:

Сообщение от Ivanhoe

Если нужен официальный документ - то вот.
Там и кратко про ключи, и про концепцию и как искать сложные случаи при настройке прав )

Еще хороший блог.

Нет. Мне нужны не "общие слова", а именно те два простых правила, которые я и привел как тот принцип, по которому работают участники данной темы.

1. На сам Security Keys не дается вообще никаких прав. Полный запрет. Уровень доступа = "Нет доступа"
2. Права даются на объекты, подключенные к соответствующему Security Keys

Так вот, ЭТИХ правил в приведенных описаниях нет.

[Ivanhoe]

Цитата:

Сообщение от Владимир Максимов

Нет. Мне нужны не "общие слова", а именно те два простых правила, которые я и привел как тот принцип, по которому работают участники данной темы.

1. На сам Security Keys не дается вообще никаких прав. Полный запрет. Уровень доступа = "Нет доступа"
2. Права даются на объекты, подключенные к соответствующему Security Keys

Так вот, ЭТИХ правил в приведенных описаниях нет.

Цитата:

Approaches to Granting Security
There are a few things to consider when approaching security. For some it is best to begin with the highest permissions level and restrict access to specific objects. For others, it is best to begin with the lowest level and grant access to objects. The best approach may vary for each user group.

The advantage to starting will the highest level and then restricting specific objects is that it leaves permission granted to the parent keys, such as the “Accounts Receivable” key. On its own, this key grants nothing to a user that they can see in the application, but for some operations the inherited pieces may be necessary.

Alternatively, starting with the least access and granting has the advantage of keeping the application as locked down as possible. The disadvantage here is that when a parent key is needed, it must be turned on. This will grant access to all child keys. This means that you must go back and restrict access again, and essentially doubles the effort in a case that the need for a parent key is found.

...

Т.е. многие (в т.ч. я) идут по второму пути - более строгому и защищенному. Но есть более простой способ (и многие идут именно по нему) - давать права от ключей.