Skip to main content

Portal Access Concerns

Core Web App

I have some concerns with the User Portal changes in v2.47, specifically around password visibility and permissions.

First, passwords stored in a client's root folder appear to be accessible to portal users by default. From a security standpoint, I'd prefer a default-deny approach that follows the principle of least privilege. Access should be explicitly granted rather than requiring administrators to take additional steps to restrict it.

This is particularly concerning for existing passwords that may have been created without any expectation of being accessible through the User Portal. We shouldn't have to reorganize credentials into subfolders or modify individual records simply to maintain their existing level of access.

Second, relying primarily on folder-based permissions creates unnecessary complexity. For example, if John needs access to Password 1 and Password 2, but Janet only needs Password 2, we now have to create separate folders to accommodate those permissions. Since a password can only reside in one folder, this also forces us to organize credentials around access requirements rather than their logical purpose.

I understand the goal was to move away from the previous portal's permission model, and I can appreciate the benefits of folder-based permissions for managing access in bulk. However, I think there should still be an option to restrict access by default and grant permissions at the individual password level.

Ultimately, I'd like to see folder-based permissions and individual record sharing coexist. That would provide flexibility without compromising least privilege or creating unnecessary administrative overhead.

3 comments

Log in to comment and vote

Comments3

  • Olive Gizmo

    •

    Oct 14

    Same here, and it's not only passwords. We're self-hosted and rolled back to 2.46.1 the same day.

    Until 2.46, sharing was per item: you ticked the passwords, assets and articles a customer should see. 2.47 only knows folders for passwords and asset layouts for assets. Here's what that means for an MSP with 200 customers, each with password folders like Windows, Printers, Network, Wi-Fi and M365:

    • Passwords: the customer should see their Wi-Fi key and printer logins, but not the admin accounts in the same folders. So every folder has to be split into "customer" and "internal", and 1,000 folders become 2,000. If the office manager should see less than the customer's IT contact, split again, and you need a group per customer and role: 400 groups.

    • Assets: asset layouts are global. To show a customer two of their five printers, you need a second "Printers (portal)" layout and have to get those assets into it, for every layout and every customer. The documentation ends up organized by who may see it instead of by what it is.

    • Defaults: a new group starts with passwords, global KB, IPAM and more allowed. Miss one toggle in one of hundreds of groups, and a customer sees credentials or internal articles they were never meant to see.

    • Update day: every portal user loses access until all of this is rebuilt.

    Is this really the intended way, hundreds of groups and thousands of folders? Can't I have one "Printers" folder that every customer has, and share only some of its passwords?

    Please keep per-item sharing alongside the group permissions, for passwords, assets and KB articles, and start new portal groups with nothing allowed.

  • Linked to Restrict passwords by default