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

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!