Forum Discussion

angela's avatar
angela
Catalyst II
4 days ago

How does the permission system work on database level?

Hi Community,

In Innovator, we can use permissions to specify which users are allowed to view, edit, or delete an item.

I have a federated item type with a custom onGet method. Since SQL federation with onGet bypasses the standard permission system, any restrictions have to be implemented within the SQL query itself.

I am wondering whether it is possible to customize my federation solution to support the existing permission framework. In my case, I would like to use the built-in identities such as "Creator", "Owner", and "Manager" to provide a more "natural and consistent permission experience".

This leads to the question: How does Innovator actually enforce permissions? In the end, all regular data comes from SQL tables, so Aras must be applying some kind of security logic at the database level.

I did some research and discovered the following:

In SQL Server, there are "secured" versions of the regular tables that combine the underlying data with the results of the innovator.EvaluatePermissions function.

My theory is that when a user requests data (for example, "Show me Parts"), the data is not retrieved directly from the innovator.Part table, but rather through the secured.Part function.

Has anyone ever tried to replicate this mechanism in the context of federation? Any tips or ideas?

Angela

Federation
Permissions

1 Reply

  • mconstantin_aras_com's avatar
    mconstantin_aras_com
    Creator III
    3 days ago

    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