Security – Part 2

Data security policies

Prerequisite – Please note to work through this lab you will need to have Admin rights to the system and have basic AOT navigation skills.

Microsoft have introduced an alternative to the ‘Record level security’ used in AX 2009 which caused huge performance issues. This alternative is known as ‘XDS’ (Extensible Data Security).

The concept is extremely simple and it doesn’t take long to setup a XDS query of your own. In this blog I will start by explaining the ‘concept’ behind XDS after which I will run through a simple lab.

Note – Microsoft have have made extensive notes on this feature. Please find the links at the bottom of this page.

Concept

“XDS limits a specific Role to only see a specific set of data within an AX table”  

Above I’ve attempted to summaries in one line the primary function of XDS. In essence the XDS security policy will apply a permanent filter onto a specific table within AX. To understand this better I will work through a simple business requirement.

Company A have two manufacturing sites (Site 1 and 2) they require the Production managers (Worker Z, Worker Y and Worker X) to see specific sets of data.

workers

Worker

Site 1

Site 2

Z

Yes

 

Y

 

Yes

X

Yes

Yes

Above we are attempting to display that the share the same AX security roles (the ability to access the same forms and preform the same tasks) however they should only be able to see the data from their respective sites.

Requirement gathering for XDS

The first step in setting up an XDS policy is simply identify the table you would like to apply a filter too, the field you are filtering on and the variants of this filer. So working through this for the scenario above you would end up with:

  • Table to be filtered?                                  Production order table
  • Field you would like to filter on?               Site
  • Variants required?                                     1 and 2

Next we will need to identify the Primary table and the Constrained tables. These have been defined below:

Constrained table – The constrained table act as the table you desire the filter to appear upon (Note – There can be multiple constrained tables as long as the primary table and the filtered field can been seen in that constrained table).

Primary table – The primary table can typically be defined as the field used to filter the constrained table.

In order to identify which tables meet the above definitions navigate to the table you desire to filter upon and identify the appropriate table relationships. Below I have worked through the example of filtering the production order table down by site. This should help you to apply the same logic to your desired business scenario.

  1. Open Production control > Common > Production orders > All Production orders.
  2. Make sure you have the field site displayed to do this click View > Dimensions
  3. Select site and save the changes
  4. Firstly we will identify the Constrained table, right click on the field ‘Production order number’ and click ‘Personalize’ in the menu
  5. Within the Personalization screen identify the table used (this can be seen in the screen shot below)
    1
  6. Next we will need to identify the primary table and field. In our case the field ‘Site’
  7. Right click the field ‘Site’ and select ‘Personalize’
  8. Within the Personalization screen identify the table and field used (this can be seen in the screen shot below)
    2
  9. This information has been summarised below:

    Primary table

    Filtered field

    Applier filter

    Constrained table

    XDS – Production orders – Site 1

    InventDim

    InventSiteID

    =”1″

    ProdTable

    XDS – Production orders – Site 2

    InventDim

    InventSiteID

    =”2″

    ProdTable

  10. If you can create an advance query to represent your desired outcome you will also be able to create this using XDS. Also it will help you understand how the relationships work.
    3

Pre-XDS setup

Prior to setting up the XDS policy you will also need to create a new Role within AX. This will generate less maintenance than applying the XDS directly to an existing security role. If you were to apply the XDS security policy directly to the production manager security role you would need to then create two production security roles and therefore maintain two production manager security roles rather than the one security role with an additional XDS role on top of that. Instead I would suggest that you create three new security roles one called ‘XDS_Site_1’, ‘XDS_Site_1_2’ and ‘XDS_Site_2’.

To do this follow these steps:

  1. Open the AOT (Ctrl+D)
  2. Navigate to Security > Roles
  3. Right click on the ‘Roles’ node and select New Role
  4. Name the roles appropriately (remember to change the name and the label)

Setting up XDS

In this next section we will run through the steps you would need to take in order to create the XDS policy.

  1. The first thing you will need to do when creating an XDS policy will be to create a project within the AOT. This will help to keep your work together and simplifies the deployment of code too.
  2. Open the AOT (Ctrl + D)
  3. Open the projects screen (Ctrl+Shift+P)
  4. Right click the ‘Shared’ folder and select New > Project
  5. Select an appropriate name for the project (XDS_PRODUCTION_ORDERS_SITE_1)
  6. Right click and Open the project

Now we have created a suitable work space to create our policy we will now need to build the query that we would like to run. This should mirror the query set-up in step 10 above.

  1. Right click you project and click New > Query
    4
  2. I find it helpful at this point to also name the query to do right click the query and select ‘Rename’ (XDS_InventDim_SITE_1)
  3. Next we need to define the primary table
  4. Expand the query and right click the ‘Data source’ and select New Data Source
  5. This will create a new node called ‘INVALID TABLE_#’
  6. Selecting this node should bring up a properties plane on the right hand side of the development screen
  7. In the properties screen first select an appropriate name and then specify the table you would liking this node should bring up a properties plane on the right hand side of the development screen
  8. In the properties screen first select an appropriate name and then specify the table you would like to filter on.
    5
  9. We have now selected the primary table but we still need to define the ‘Range’ (Criteria) for the filter.
  10. Expand the data source you created and right click on the ‘Ranges’ node and select New Range.
    6
  11. Again using the Properties screen amend the following fields:

Name

XDS_Site_1

Field

InventSiteId

Value

=”1”

  1. Next select the field’s node and again in the properties amend the property ‘Dynamic’ to ‘Yes’.
    7

Now we have set the query up we need to setup the XDS policy to apply the query to the constrained tables and relate to a specific AX role.

  1. Right click the main project ‘XDS_Production_Orders_Site_1’ and then click New > Security > Security Policy
    8
  2. Select the ‘SecurityPolicy1’ node and modify the properties to be:

Property

Value

Name

XDS_Production_Site_1

Label

Restrict Production orders to site 1

PrimaryTable

InventDim

Query

XDS_InventDim_Site_1

PolicyGroup

Production

ConstrainedTable

Yes

Enabled

Yes

Operation

All operations

Context Type

RoleName

Role Name

XDS_Site_1 (setup in step 14)

  1. Next we need to define the constrained table. Expand the security policy node to reveal the ‘Constrained table’ node right click this node and select New > Add table by relation
  2. Within the properties set the following values:

Property

Value

Constrained Table

Yes

Table

Prodtable

Table Relation

InventDim

  1. We have now setup out XDS policy. Remember to COMPLIE THE WHOLE PROJECT! To do this right click the project and click ‘Compile’ this should then remove the red line next the project. (If it doesn’t try closing the window and navigating to it again)

Now we have successfully created the XDS security policy we will need to test that it works to do this you will need a test user account (Don’t apply it to your user as you will then not be able to change yourself back to admin!)

  1. Open System administration > Common > Users > Users
  2. Select the test user you would like to apply the policy too
  3. Select Assign roles and select the roles Production manager and XDS_Site_1
    9
  4. Close your AX application and open again as a different user to do this hold down ‘Shift’ and right click the AX application and select ‘Run as different user’
  5. Navigate to the appropriate area and test that the filter has been applied.

Summary

To recap on out original requirements we had 3 users Z, Y and X with the following requirements:

Worker

Site 1

Site 2

Z

Yes

 

Y

 

Yes

X

Yes

Yes

To achieve the requirements of Z and Y you would need to create two policies as we did in the example above. However, it should be noted that you CANNOT STACK XDS policies by this I mean if you wanted user X to see sites 1 and 2 but not site 3 you should not apply both two policies created above as they will cancel each other out and you will end up with no data displaying you would need to create a new policy with a query such as =”1”,”2” in a new XDS security role.

The final outcome should be as follows:

 

AX ROLES

Production manager

XDS_Site_1

XDS_Site_2

XDS_Site_3

Worker Z

Yes

Yes

Worker Y

Yes

Yes

Worker X

Yes

Yes

Links:

http://msdn.microsoft.com/en-us/library/hh272123.aspx

Advertisements

4 thoughts on “Security – Part 2

    • Hi,

      It’s important to analyse your requirements carefully before you jump straight into XDS security.

      You would need to understand and analyse the following:

      1. Are all these site’s in the same Legal entity?
      2. Which screens do these users want to filter?
      a. Works orders?
      b. On-hand inventory?
      3. Do the users work across multiple sites?
      4. How much do you trust your employees? We have database logging so the user knows if they do something wrong we can pick it up.

      Setting up these XDS securities should not be a first option you need to consider the admin overhead and the actual benefit of doing this.

    • Well, to cater this what I have done is that I have modified the USERS form and there you can associate a user with multiple sites.

      Instead of hardcoding site 1, simply write code in the xds() method to accomplish this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s