Forum Discussion

angela's avatar
angela
Catalyst II
11 months ago

Do I have to give external users "get" permission for an ItemType when using a MAC policy to restrict access?

Hi community,

let´s assume we have a lot of regular Parts in Innovator. An external user now shall have access to a limited amount of these Parts. An additional property specifies which parts he is allowed to see.

This scenario is a perfect job for a MAC policy. MAC policies allow to restrict the user access based on the property.

But I noticed that the external user still needs to be added to the regular permission that is used for Parts (e.g. Permission "Released Part"). Is this really necessary?

The MAC rule it self works fine. But only if the external user is part of the "Released Part" permission. Otherwise he will see nothing.
But I would prefer to avoid adding the user to this general permission.

Reason: When the external user is part of the regular permission, he could see all items by default. Only after the MAC rule is activated, the item access is restricted. But what if we upgrade and forget to reactive the MAC rule? Will the external user see everything until we notice our mistake?

I would prefer things the other way round. The external user must not see any Part UNTIL the MAC policy activated.

Is this behavior possible?

Thanks in advance!

Angela

4 Replies

  • Ichiro_Mizoguchi's avatar
    Ichiro_Mizoguchi
    Creator I
    11 months ago

    Hi Angela,

    I've never implemented a MAC policy in my environment, so please take the following as an informed assumption.

    From a security perspective, I completely understand your concern. Ideally, access to Parts should be denied by default, and only granted once the MAC policy explicitly allows it. That way, even if the MAC policy is accidentally disabled—such as during an upgrade—external users would still not be able to see anything.

    However, based on your observation, it seems that the default permission ("Released Part") must still include the user, and the MAC policy then acts as a filter on top of that. If that’s the case, I agree it introduces a risk: if the MAC policy is not active, the user might gain broader access than intended.

    I would also prefer a setup where access is denied unless explicitly granted by the MAC policy. If such a configuration is possible, I’d be very interested to hear how others have implemented it.

    Thanks for raising this important point!

    Ichiro

    • angela's avatar
      angela
      Catalyst II
      11 months ago

      Hi Ichiro,

      thanks for your feedback on this one!

      Actually the behavior of MAC is clearly described in the official documentation:

      Mandatory Access Control (MAC) imposes an additional layer of access control over Item permissions and Domain Access Control (DAC). MAC does not grant any access - it simply revokes or allows existing access

      --

      Just a side note:

      We use MAC rules since years. Mainly for user visibility restrictions. So far we never had any issues. In the past, I even tried to manipulate and "break" MAC/DAC rule intentionally, e.g. by attacking the Conversion Server until it collapsed. None of my tests in the past had any negative impact on the visibility restriction.

      In general I trust these features. Innovator even warns us when we play around with an active MAC rule. I mainly want to prevent human error during Innovator upgrades or feature updates.

      ---

      I have an idea: Maybe we can implement some kind of "kill switch" for the permission as soon somebody deactivates the MAC rule. 

      The dependency regarding the permission can easily be overlooked. I currently use the "Description" textarea of my MAC rule to describe this connection, but maybe I can make a "real" item link to the permission or "Access" item.

      Basic concept:
      - If MAC rule is deactivated, the linked Access item will be deactivated too.
      - Granting access should stay manual and deliberate – no automation.

      I right now remember your answer from another post:

       link 

      Users will never report if they see something in my Innovator that they shouldn’t. But they will definitely complain if they don’t have access to something they need.


      I will make some tests with my "kill-switch" idea. But I'm still open to better ideas!

      • Ichiro_Mizoguchi's avatar
        Ichiro_Mizoguchi
        Creator I
        11 months ago

        Hi Angela,

        I haven’t implemented a MAC Policy yet, but this thread has been very insightful, so I’d like to share my perspective.

        In general, I believe it’s common for permission settings to be tightly controlled, and I see three typical patterns:

        1. Only I have permission, and no one else is involved in setting permissions.
        2. Multiple people have permission, but changes are made only with my knowledge.
        3. Multiple people have permission, and changes can be made without my knowledge.

        I think cases 1 and 2 are more about internal workflows and team agreements rather than technical capabilities of Aras, so they might not need to be discussed here.

        The real concern is case 3, where changes happen without my awareness. In this case, I think there are two key points to watch:

        • a. Detecting that a permission setting has been changed
        • b. Understanding whether access for external users has been affected

        As I mentioned in a previous comment, I’m not deeply familiar with MAC Policies yet, but I believe point a could be addressed using a server method like onAfterUpdate.

        Point b seems harder to detect directly, but perhaps we can approach it by evaluating whether the change detected in a has expanded access to external users.

        In that sense, the method triggered by onAfterUpdate could include logic to check whether the scope of access for external users (e.g., specific user groups) has been broadened.

        I hope this line of thinking is helpful, and I’m very interested to hear your thoughts or suggestions for improvement.

        Best regards,
        Ichiro

  • rushpaint's avatar
    rushpaint
    Ideator I
    10 months ago

    No, that behavior isn’t possible by default. The user still needs base permission (like “Released Part”) to access items, and the MAC policy only filters within that permission. Without the base permission, MAC rules won’t apply. So yes, your concern is valid—MAC can't override missing base permissions.


    color rush