sjakalax: DAXCONF - Role-based security (RBS) and eXtensible Data Security (XDS)

[Blog bot]

Источник: http://sjakalax.blogspot.com/2011/01...y-rbs-and.html
==============

I just attended 3 sessions on the new security framework in Ax. The content is just too much for one post. I'll give the highlights:

RBS (role based security)
- The new security framework is based on:
- Roles: a group of duties specific to a function (accountant, mechanic, clerck, manager, …)
- Duties: a group of related privileges needed for a specific task (sales order entry, approve expenses, order picking, …)
- Privileges: a group of entry points (mostly menu items) needed for a specific action (create sales order lines, set up HRM parameters, start a pickingroute, …)
- Permissions: a group of base objects each with the required level of access (update salesTable, update HRMParameters, …)

- Developers are responsible to provide the appropriate privileges and permissions
- An administrator can define roles and duties based on the privileges and permissions -and link uto roles

- Standard out-of-the box all roles, duties, privileges and permissions are available to secure all functionallity in Ax2012! Impressive: previous versions had … no out-of-the-box security configured.

Some other facts:
- SecurityKeys are no longer used
- Companies are replaced by legal entities
- Domains are replaced by organisations
- Users groups not longer used in a security context
- External users (without an AD-account!) now can log on to the EP (using # ways of user authentication in SharePoint 2010)

XDS (eXtended Data Security)
- In previous versions there was RLS (record level security), where you couldn't do much more than restricting the selected data by adding a where clause to tables
- Ax2012 takes RLS to the next level: it's called the XDS framework
- the combination of an application context (form, menu item, ...) and a role context (user, role, ...)
- is applied to a policy (based on queries, so more flexible compared to RLS, also the meta data is used to apply data security on linked tables)
- this policy filters the data as configured

In an example this would be: if you define a query on the salesTable, but a policy defines you can only see customers from a specific group ('x'), you will only see the salesTable records for customers of group 'x' … even if your select looked like 'select from salesTable', it would become something like 'select from salesTable where exits (select from custTable where custTable.PK = salesTable.FK and custTable.group = 'x')'. Applying multiple policies, would add extra 'exists' clauses to the query.

- Ax2012 comes predefined with 11 policies (3 enabled by default)


- This sounds like a performance killer ... well there's a solution (as with most potential performance issues in ax2012). Policies that result in complex queries including multiple joins can be cached in temp tables that will be populated the first time the complex policy-query is executed. The next time this complex query is executed ... it is not ... the results from the temp table are used in the query rather than executing the complex query over and over again. This is called a 'myConstruct' and the refreshrate is customizable (on each execution, per session, ...). Ax2012 comes with 7 myConstruct tables out-of-the-box.



- A super-duper feature for developers is the possibility to get the actual SQL statemets (policies applied) from within X++.

The goal of this new security framework is
- Faster implementation
- Role-tailored user experience
- Comprehensive data security

I'm impressed!


Источник: http://sjakalax.blogspot.com/2011/01...y-rbs-and.html

[TasmanianDevil]

XDS - это вполне реальный убийца производительности может стать. При недостатке технической информации пока весьма спорно выглядят его преимущества.

[pitersky]

Я так понимаю, что фраза "- This sounds like a performance killer ..." была приведена как раз в ожидании подобных комментов

да нифига не убийца
мы похожую херь для 2009 сделали, не тормозит

[fed]

Вообще - ни разу не видел внедрения, которое обошлось бы голым RLS. То есть - даже если удается настроить фильтры на формах и в отчетах, потом все равно выясняется что надо курочить прикладную логику, добавляя, например, какие-то гибкие проверки в классах сопоставлений, книжек, ну или скажем, складской разноски.
Так что конечно, похоже что, этот XDS - это большой шаг вперед, но полностью покрыть требования ограничения доступа к чуствительным данным только на уровне системной тулзы, на мой взгляд, не возможно...

Цитата:

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

не возможно...

я конечно наверное много хочу, на фоне -ТЬСЯ всяких, которые тут повсеместно, но все же коробит слегка

[gl00mie]

Цитата:

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

я конечно наверное много хочу, но все же коробит слегка

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

PS. А еще есть такая банальная вещь: опечатки...

[TasmanianDevil]

pitersky, я прочел эту фразу
Просто упомянутое решение про хранение всего комплекса служебных join'ов для решения проблемы производительности как-то таковым не особо выглядит. При упомянутых режимах обновления этой сервисной информации - только при perSession ситуация выглядит более-менее, а perExecution вообще лишает смысла хранение это инфы(если каждый раз при исполнении запроса пересчитывать эту инфу - то зачем ее хранить ?). Но и даже выглядящий более-менее режим обновления раз в сессию тоже может не оказаться панацеей, когда каждый пользователь при первом открытии в сессии любой формы будет N-нное время ждать перестройки этих данных. Каковым будет это N-нное время - зависит от реализации. Если делали "универсальную шнягу" ( (c) by mazzy ), то задача поиска связи м-ду двумя заранее неизвестными таблицами, не имеющими прямой связи друг с другом, через N промежуточных таблиц может очень хорошо "выстрелить", потому как в таком поиске по прямым связям (через Relations) и косвенным (через EDT полей) будет огромное количество "холостых" и бесполезных итераций и ветвлений поиска. Сей факт как раз и вызывает сомнение про решенность проблем производительности. Хотя, если помнить,что в 6-ке AOS хотят в БД запихать - может и оно и не так будет тормозить.
В общем, будем посмотреть - сейчас можно только гадать ...

[TasmanianDevil]

Сижу, курю Developing_Extensible_Data_Security_Policies_AX2012.PDF...
Первое впечатление - какая-то мутная дрянь по сравнению с RLS.