Add Security around Changing Categories on Objects

[ryan]

This was originally logged with Autodesk under Case: 14070193 - Circumventing Security Permissions using Change Category and Change State and I was advised to post to the IdeaStation.  Personally, I think this is a bug and a fairly concerning one at that but I've been told the product is working "as designed" which is hard to wrap my head around.  Nevertheless, following the path I was advised to take.

If your role security grants you the ability to "File Change Lifecycle Definition" (in Vault 2018, this would be the Document Manager Level 2 role), you can completely bypass your workflow securities.    Here's a simplified test scenario;

1. Create a user account that has Document Manager level 2 permissions.
2. Create two categories, each using their own lifecycle.
3. In each of the lifecycle definitions, have a state called WIP and RELEASED and ensure that your user account created in Step 1 does NOT have permission to move from WIP to RELEASED.
4. Add a file to vault that is on the base category.
5. Change the category of this file to one of the categories created in Step 2 above.
6. Immediately after doing so, change the category to the other category created in Step 2 above.
7. Then, use the Change state command, change the lifecycle to the one that belongs to the category and you can now pick the Released state! The net result is that you can release a file when you were not authorized to do so.

I have provided a link to a ScreenCast that demonstrates this behaviour, also confirmed by Product Support on the case indicated above.

The answer given to me by development is that the product is working as designed given that the transition security check is only built around moving between states within the same lifecycle.   Fair enough; however, limiting the transition security check so that it does not check between workflows opens up a major security hole.

Although downgrading the security role to Document Manager Level 1 prevents this problem, it also takes away some other functionality needed by a customer.

EDIT: Adding the screencast link as it did not come through on original post; https://knowledge.autodesk.com/community/screencast/7706a1d5-5b8e-43b7-ad7f-acaaff39316e

[ihayesjr]

@ryan, with 2019 and the ability to create Custom Roles, you can create a new role and remove the user's ability to change categories by removing the File Change Category permission. This should solve this request.

[ryan]

Irvin,

Provided you don’t need to change category I absolutely agree with you and in smaller vault deployments this is probably true as the customer has perhaps only a few categories (or maybe only 1) and therefore all the categorization can be done using rules.

However, in most medium to large deployments this isn’t the case and users need the ability to change category as it’s impossible to capture all the necessary categorization with rules.

So, if you are on 2019 I agree that you can do this using custom roles or on an earlier release as I stated by changing to document manager level 1 (to remove change lifecycle state definition). However if users need these functions, it leaves an open hole.

To be honest, this would be much less of a concern if we had the ability to limit what categories users/groups can pick and I’d *WAY* rather have this functionality. Granted it could still leave a security issue but it would be mitigated and bring much needed functionality to the product.

[ihayesjr]

Ryan,

Can you expand on this statement?

it’s impossible to capture all the necessary categorization with rules.

---

[ryan]

In every vault implementation I always maximize categorization using rules, often times using prebuilt templates with different property values that the rules are built upon.

One scenario though where this breaks down is when you have data you are adding to vault that is coming from an external source. Data downloaded from the internet to use as library data is a good example. Since those files were not built using your prebuilt templates, and assuming we are talking about a multi-departmental vault, they need to go on BASE category and allow the user to assign as needed after upload.

Another example; let’s suppose I am building some automation equipment such as conveyor, packaging, etc and my customer sends me 100 AutoCAD drawings that I need to put into vault. Here again, I would probably put them on base category as the source data might be specific to one department and they would subsequently have to categorize.

We agree completely that using document manager level 1 or a custom role in 2019 mitigates this; however, there are cases where customers require these functions and everything can not be categorized using rules so in this case, we do have a security loophole. Has this been a widespread problem across numerous customers? No, but concerning for the customer in question.

[Gabriel_Watson]

To illustrate this issue better:

Even if we could write down all the processes of types of files being checked into Vault, there are processes that require us to copy design certain files to save them either as new Standards, Libraries, or Customer Deliverables, based on original files that were simply mechanical designs used in production. We can copy those and reset their category, but it will be up to the user to re-define that category.

There are simply too many reasons why we have to leave the ability of re-categorizing a file in the hands of the user, and changing file lifecycles as well. But, in the specific case that hurts our team the most, we are transitioning from an individual-publish style of Mechanical Library (where everyone is allowed to download/create, check-in, and release/publish their own files to be categorized as Mech. Lib) to a librarian-controlled process, where 1 or 2 librarians review the Mech. Lib content added by others before releasing those library files.

Now that a few users know they can circumvent the system by changing lifecycle and releasing at the same time, they have defeated the filtering process that SHOULD work according to the software's expected mechanics.

BOTTOMLINE: we do not see the functionality Ryan demonstrated above as a particularly useful and expected behavior, except if you are willing to 'cheat' the rules. So, now we can either update all Inventor users to 2019 (after just a few months ago having to go through the ordeal of setting up 2018 for everybody), AND hope for an update to fix this, or wait almost 2 years (or normal update cycle) to get updates on all the functionality of Vault, also hoping this loophole is closed.

[ihayesjr]

Great. Thanks for the feedback.