Forum Discussion

angela's avatar
angela
Catalyst II
20 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

2 Replies

  • mconstantin_aras_com's avatar
    mconstantin_aras_com
    Creator III
    19 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

    • angela's avatar
      angela
      Catalyst II
      14 days ago

      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.