DAC Data Model Considerations
Copy
When configuring a DAC policy, it is useful to understand the DAC components particularly because it is configured “bottom-up” by administrators as you will see in section Creating and Activating a DAC Domain Policy.
DAC is far from monolithic. The primary ItemType in DAC is the DAC Definition however it depends heavily on the Derived Relationship ItemType and Derived Relationship Family which in turn depends on the Query Definition. All of these must be configured before the DAC Definition can be completed.
Derived Relationship […]
Departure […]
Destination […]
ID of Leaf item instance (e.g. Document D-123).
Configure the DAC Definition for different Access Types (Update, Delete, etc).
Use custom event handler method in place of the default or ,
Add a new Event method to execute in sequence with the default Event Handler from Aras.
Figure 9.
The Query Definition selects paths and endpoints from the physical relationship structure for use as Derived Relationships (DR) in a Derived Relationship Family (DRF). The DRF tracks changes to controlled items on behalf of DAC.
When defining a DAC Policy first create the Query Definition, use it to complete the DRF and its DRs, and then define rules for the DAC Definition.
Figure 10.
When the Query Definition is linked to the Derived Relationship Family item, Leaf items can be selected (Root is implied) to define Derived Relationships.
Figure 11.
Finally, the DAC Definition links to the DRF and you can assign the Subdomain Rules to each DR.
Figure 12.
Section Creating and Activating a DAC Domain Policy walks through each step.
Tracking Changes to Access Controlled Items
When a DRF is first activated, an ItemType table called unidr_Relationship is populated with query results for every instance of Root->Leaf defined by the Derived Relationships in the family. This may take some time for large databases.
Records in this table contain references to all instances of Root and Leaf items in DAC Subdomains. After first-time initialization, the table is maintained automatically when events (add, delete, modify, etc.) occur against member items in DAC Subdomains. In this manner DAC maintains the integrity of Access Control for all item instances in the policy.
The unidr_Relationship table includes these columns:
Figure 13.
Pointer to DR under DRF linked to DAC Definition containing DAC Rules.
ID of the Root item instance of the Subdomain (e.g. Project X).
As of 12.0 SP5, DRF event handlers have been made configurable / customizable for those who need to execute business logic when changes to item memberships in DAC Subdomains occur.
Customizing DRF Event Handlers
Earlier we discussed the scenario where Project Team “X” gains access to an item added to the Project from another Project under DAC Policy. In some cases, business requirements prohibit the increase of access rights due to inclusion into a Domain.
For instance, a Part belonging to Project Y might be re-used by adding it to Project X. The Project X Team may suddenly gain Update rights to the Part shared with Project Y. The intent may have been to allow reuse but not open the Part from Project Y for modification by the other Project Team X.
Figure 14.
With 12.0 SP5, DAC Domains provide a hidden ‘Events Handlers’ tab under DRF so that Administrators can either specify which Access Levels change(s) are prohibited, enable or disable such checks, or add custom logic as needed.
The Administrator now has the choice to:
Configuring/customizing DRF Event Handlers is an advanced feature. Details on DRF Event Handlers is provided in the Appendix.