emeadaxsupport: Record level security is not enforced in code or is it?

[Blog bot]

Источник: http://blogs.msdn.com/b/emeadaxsuppo...-or-is-it.aspx
==============

I recently came across an unusual behaviour of record level security, that I don’t think has been documented before, so I thought I would share it with you.

The situation here is that there is an employee with emplId=”RLS”, and there is a user group configured with record level security which will allow members to view every employee except “RLS”.Now a user which is a member of this group runs a report, and the fetch() method of the report looks like this:

public boolean fetch()
{
boolean ret = true;
EmplTable emplTable;
;
//emplTable.recordLevelSecurity(false);

select firstonly emplTable where emplTable.EmplId == 'RLS';

return ret;
}


What should be the result - Does the emplTable buffer get populated? Record level security (RLS) isn’t enforced in code, right? Wrong!

Whilst it is true most of the time that RLS isn’t enforced in code, there are a couple of exceptions to that rule: reportRun.fetch(), reportRun.send() and lookup() on form controls.

What happens in the AX kernel is that before the kernel triggers these methods it enables RLS for the whole current X++ stream and then disables it again when the method returns. This has the effect that any code in one of these methods, or any code called out to from one of these methods will have RLS enabled by default.

In the above code if we uncomment the line emplTable.recordLevelSecurity(false) then it will allow the buffer to bypass RLS and get populated successfully.

There are a couple of other noticeable quirks of this – if you print the value used from the emplTable.recordLevelSecurity() method it will show that RLS is not enabled for that buffer – this is because it is actually enabled at a higher level for the whole X++ stream and the buffer’s property isn’t directly set.

The other quirk is that if you enable tracing from the user options -> development tab -> database trace option then you’ll see that RLS is enabled for the calls made to tables in this scenario – this is correct as the tracing picks up whether RLS was actually used when accessing the table in the data layer of the kernel – and it was!

Moving forward in AX2012 this no longer applies – the security framework and reports are re-worked.

--author: Tariq Bell--editor: Tariq Bell--date: 24/05/2011


Источник: http://blogs.msdn.com/b/emeadaxsuppo...-or-is-it.aspx

[gl00mie]

Вот это да! Хоть и похоже на некий костыль, но все равно очень познавательно - хотя бы тот факт, что RLS может быть включен на уровне "the whole current X++ stream", а не только на уровне отдельных табличных буферов или Query.

[S.Kuskov]

Ещё есть такой skipAosValidation, которым можно отключать AOSAuthorization
http://msdn.microsoft.com/en-us/library/bb278259.aspx

Цитата:

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

RLS может быть включен на уровне "the whole current X++ stream", а не только на уровне отдельных табличных буферов или Query.

А разве разработчику управление этим процессом доступно? Если доступно, то как?
Вероятно можно выполнить какой-нибудь runbuf runas с предопределёнными настройками RLS

А по поводу AX2012 я так и не понял. В следующей версии были неким образом исправлены описанные "quirk" или просто убрали сам метод как таковой?

Цитата:

Сообщение от Blog bot

Moving forward in AX2012 this no longer applies – the security framework and reports are re-worked.

[gl00mie]

Цитата:

Сообщение от S.Kuskov

Ещё есть такой skipAosValidation, которым можно отключать AOSAuthorization

Только чтобы его успешно вызвать, надо получить сперва SkipAOSValidationPermission...

Цитата:

Сообщение от S.Kuskov

А разве разработчику управление этим процессом доступно?

По-моему, нет, но тут интересно еще вот что: хотя в разных контекстах значения по умолчанию свойств одних и тех же табличных буферов могут "трактоваться" по-разному, явное задание этих свойств (recordLevelSecurity в данном случае) всегда однозначно влияет на поведение ядра независимо от контекста. Выходит, значения, по крайней мере, ряда булевских свойств объектов ядра хранятся в виде 3-х значений, подобно UnknownNoYes.

Цитата:

Сообщение от S.Kuskov

А по поводу AX2012 я так и не понял. В следующей версии были неким образом исправлены описанные "quirk" или просто убрали сам метод как таковой?

Про 2012-ю пришут, что там RLS оставлен только для обратной совместимости, и надо переходить на новые механизмы:

Цитата:

In earlier releases, the record-level security (RLS) feature is used to help secure the data. The filters used for record-level security are based on fields in the same table that is being secured. In addition, by default, record-level security is enforced on the client.
In Microsoft Dynamics AX 2012, the Extensible Data Security Framework can be used to help secure the data. The new framework lets administrators create data security policies based on data that may be contained in a different set of tables. Data security policies are enforced on the server side, regardless of the type of client that is used to access the data. In addition, policies can consider security privileges. For example, the administrator can grant view access to one subset of sales orders and edit access to a different subset of sales orders.
CAUTION: The record-level security feature is still supported in Microsoft Dynamics AX 2012 and if previously implemented, they will continue to be used. However, it is recommended to setup new data filter utilizing the extensible data security framework.