Using XDS to Secure data via the Organization Model (Part 1) - AX 2012

Recently, I posted an article that covered the resources for helping one understand the options, and how best to model a companies organization within Microsoft Dynamics AX 2012. You can find that article here.: A question around Organization Modeling for AX 2012 

As promised, this post kicks off that two part series, in where I will dive into the use of XDS for securing data within AX 2012. 



Before we dive right into securing data, based on the organizational model within AX 2012, first it's important to understand the parts that will make up our solution to this. Keep in mind, that the focus for Microsoft Dynamics AX 2012, is always to model more and code less! 

With that in mind, and referencing the above image the are we are talking about focusing on is the Data Security area. This is where deny takes place, where as above it in theauthorization section, in which we do role based modeling of security, grant takes focus. 

For the sake of this post, and it's focus around data security, lets assume then that you already have your role based modeling of security petty much complete. With that assumption aside, our focus for this effort is around the Data Security Policies. This is where we will live, and what objects we created will have context. 

As mentioned in previous post, Query Elements are meant to be a re-usable API in AX 2012. They are considered modeling elements, vs. custom code elements. 

The idea, is that we create a modeling query used to represent the policy, in what we want to deny. In doing this we then, as stated above, start with a query. For example, if we wanted to model a query that limited prospects, by inbound user id, then that would be the target of our query. 

Lets then look at the start of this example query. Since we want to constrain the Prospects from the Sales & Marketing module, we need to first target the smmBusRelTable. Since we want to constrain these for the inbound user id, lets assume responsibilities have been modeled and we have a "Sales Rep" responsibility tied to prospects. 



With having this, then we need to add to our query, the smmResponsibilitiesEmplTabletable. This is joined to the smmBusRelTable by RefTableId & RefRecId as a 1:n join type in the query design. Further, since we are targeting the "Sales Rep", we add to our ranges, theResponsibilityId field, and add for the value: Sales Rep. 



The next trick we need to focus on, is then having the query take us from the Worker associated with the responsibility for the the prospect, to the user id. This assumes, then that User's are associated with employee's of type workers via user relations. In that assumption, we can make the connection from smmResponsibilitiesEmplTable -> HcmWorker -> DirPerson -> DirPersonUser. 



Now that we have achieved this, we next need to focus on our final range for the DirPersonUser table. That being of the user field. For the value that we supply for the range, it is a function: (currentUserid()) 



Now that we have this supplied, our query is ready to be set for the basis of a Security Policy. That is the next element of focus, in modeling security with XDS, a security policy. Doing this, we create a security policy, set our constraint properties, and finally enable the policy. 



The above we see the correct security policy, and that it is further constraining the SalesQuotationTable as well as the SalesQuotationLine table. Further, the following is the properties of the above listed security policy object. 



With the above enabled, and not having anything supplied for the ContextType, this policy is not enabled for anyone, and will deny access to the Prospects & Quotation tables based on the query we modeled. Meaning anyone that does not have a Sales Rep responsibility association for a prospect will not see that prospect when access AX 2012 from the Rich Client, EP, Reporting or service integration. Only users with System Administration role can see everything. 

This would mean, that most likely you would want to at least apply this by Security Role, say Sales Rep that you had modeled. Then this policy would only deny access by the modeled query, for the specific user id's, when having the Sales Rep Security role applied to their user id. 

Another point about security policies is that the intersection of multiple policies is what is shown. Where as in the grant focused authorization of role based security modeling, that will take the sum of all granted rights, for all applied security roles. Security policies, all that are enabled, must fully be satisfied. This means you could enable overlapping security policies that have adverse affects on what is trying to be achieved. Therefore, like all things, use caution. 

Having the above base knowledge, and walk through for using data security policies to deny access to specific data, we can then move forward with part II of this focus, with using the organization model relating to released products, to model security against. 

That's all for today's post, I hope you find it useful. Check back soon as more to come, including part II of this post, more on BI and the System of Engagement, as well as upcoming AXUG Summit coverage. Till Next Time!