Hi Angela,
Correct, Aras does not normally query the physical item tables directly when evaluating user access. Permission evaluation is pushed down to the database through SQL objects generated by Aras.
In environments using MAC policies, Aras generates secured database functions (for example secured.PART, secured.DOCUMENT, etc.) that combine the item data with the result of permission evaluation logic. These secured functions are evaluated for GET, DISCOVER, UPDATE and DELETE operations.
When Activating a MAC policy, you can observe that the secured function is getting updated with the MAC content.
I have implemented similar solutions where additional security constraints were injected into the database-layer filtering logic, but that was for standard Innovator ItemTypes and MAC policies rather than federation.
I'd also be interested to hear if anyone has successfully reused the standard Permission objects directly in a federated onGet implementation.
regards
Michael
Thanks for the tips! Now I understand why the function contains an EnvAttrs tag. These are the environment attributes defined in our MAC policies (if there are any).
This actually gives me an idea. By default, the SQL functions I checked needed the user´s identity list, and I´m not sure how to handle that in the context of my custom federation function. Maybe I can avoid relying on the identity list altogether and instead use a custom solution that mimics MAC policy behavior. Just thinking out loud...
I haven´t had a chance to do any further testing yet, but I'll definitely revisit this over the next few days.
