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
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:
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!
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:
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:
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
