Missing permissions for the Shared Access Role?

[DanieleUlrich]

I have found a problem with the shared access role introduced in vRA 7.3: a user granted only this role can see the catalog, select catalog items and start the provisioning process.

But on looking up the request metadata ( composition-service/api/requests/{requestId}/metadata ) it will get a 403 forbidden and the request will fail very fast. I checked this call with all roles and only shared access user role is not accepted with this request.

The tooltip text says "Add one or more users who can use and run actions on the resources that are deployed by other business group members." and in the documentation I have not found additional details​. So I have the following questions:

• can this behaviour be confirmed by others or could this be a missconfiguration of my lab installation?
• if it is confirmed, should this new role be an extension only to the  business group user?

I finally could overcome this limitation by granting both, Business Group User and Business Group Shared Access User, to a user. But I doubt that this is really the intention of this role as it grants also day 2 access (modifications) to all assets within the given Business Group. And if the role should not be granted permission to provision new catalog items the catalog should not be displayed at all.

[daphnissov]

Hi, Daniele. I can confirm this behavior myself. It is just as you describe. A user solely granted Shared Access to a business group inherits the same entitlement to see and start a provision as other users with the same entitlement. As mentioned, the provision immediately fails with a metadata lookup error. Even if I create a new entitlement for a user granted the shared access role which only contains entitlements to actions and no services or catalog items, then prioritize that higher than the rest of the business group, upon login that user can still see the catalog.

When looking at the documentation, there is almost no reference to this new role. The exception is the configuration guide (PDF) which only lists some scenarios that involve said role. Curiously, the wording for all of these reconfigure operations (which involve NSX components) is very specific:

Log in to the vRealize Automation console as a machine owner, support user, business group user

with a shared access role, or business group manager

I've emboldened and underlined the interesting part. It seems to suggest that both the user AND shared access roles are needed, and that would be consistent with your findings as well.

I do agree, however, that the catalog should not be visible if a user/group is granted solely this role. I also think the way the role is described both in the UI and the one paltry sentence provided on page 143 that it is somewhat misleading if this current behavior turns out to be true.

[DanieleUlrich]

Thanks, daphnissov​, at least I have the confirmation that my setup is not corrupted.

The new role is not properly documented and in my installation the properties for {com.vmware.csp.core.cafe.identity@csp.scoperole.sharedaccess.user.name} and {com.vmware.csp.core.cafe.identity@csp.scoperole.sharedaccess.user.description} seem to be missing as well - spaming the logs with warnings.

And yes: if we read the available descriptions with the eyes of a lawyer we could come to the conclusion that it works as designed.

But if you check the roles you'll find:

GET https://{{vra-fqdn}}/identity/api/authorization/tenants/vsphere.local/principals/bgshared@cloudlab.local/roles/

{
    "links": [],
    "content": [
        {
            "@type": "ScopeRole",
            "id": "CSP_CONSUMER_WITH_SHARED_ACCESS",
            "name": "{com.vmware.csp.core.cafe.identity@csp.scoperole.sharedaccess.user.name}",
            "description": "{com.vmware.csp.core.cafe.identity@csp.scoperole.sharedaccess.user.description}",
            "assignedPermissions": [
                {
                    "id": "GUI_CATALOG",
                    "name": "Catalog User Interface",
                    "description": "Access the catalog GUI.",
                    "prereqAdminPermissions": null
                },
                {
                    "id": "GUI_REQUESTS",
                    "name": "Requests User Interface",
                    "description": "Access the requests GUI.",
                    "prereqAdminPermissions": null
                },
                {
                    "id": "CATALOG_CONSUME_SELF",
                    "name": "Catalog Consume Requests and Resources requested by self",
                    "description": "Consume services and resources for one's self and manage one's own requests",
                    "prereqAdminPermissions": null
                },
                {
                    "id": "GUI_ITEMS",
                    "name": "Items User Interface",
                    "description": "Access the provisioned items GUI.",
                    "prereqAdminPermissions": null
                },
                {
                    "id": "SUBTENANT_USER_DATA_MANAGEMENT",
                    "name": "Manage user data (requests, items, tasks etc) within a business group.",
                    "description": "Manage user created objects belonging to a specific business group.",
                    "prereqAdminPermissions": null
                }
            ],
            "scopeType": {
                "id": "CSP_SUBTENANT",
                "name": "CSP Business Group",
                "description": "CSP Business Group scope type",
                "prereqAdminPermissions": null
            }
        }
    ],
    "metadata": {
        "size": 20,
        "totalElements": 1,
        "totalPages": 1,
        "number": 1,
        "offset": 0
    }
}

GET https://{{vra-fqdn}}/identity/api/authorization/tenants/vsphere.local/principals/bguser@cloudlab.local/roles/

{
    "links": [],
    "content": [
        {
            "@type": "ScopeRole",
            "id": "CSP_CONSUMER",
            "name": "Basic User",
            "description": "CSP Basic User",
            "assignedPermissions": [
                {
                    "id": "GUI_CATALOG",
                    "name": "Catalog User Interface",
                    "description": "Access the catalog GUI.",
                    "prereqAdminPermissions": null
                },
                {
                    "id": "GUI_REQUESTS",
                    "name": "Requests User Interface",
                    "description": "Access the requests GUI.",
                    "prereqAdminPermissions": null
                },
                {
                    "id": "CATALOG_CONSUME_SELF",
                    "name": "Catalog Consume Requests and Resources requested by self",
                    "description": "Consume services and resources for one's self and manage one's own requests",
                    "prereqAdminPermissions": null
                },
                {
                    "id": "GUI_ITEMS",
                    "name": "Items User Interface",
                    "description": "Access the provisioned items GUI.",
                    "prereqAdminPermissions": null
                }
            ],
            "scopeType": {
                "id": "CSP_SUBTENANT",
                "name": "CSP Business Group",
                "description": "CSP Business Group scope type",
                "prereqAdminPermissions": null
            }
        }
    ],
    "metadata": {
        "size": 20,
        "totalElements": 1,
        "totalPages": 1,
        "number": 1,
        "offset": 0
    }
}

As you can see, CATALOG_CONSUME_SELF is granted to both roles. I can't help myself, but I think it's more a bug than a feature.

[daphnissov]

Yes, definitely agree. The presence of the feature and the description of the permissions on the role are mutually exclusive--if you can do one, you shouldn't be able to do the other. Otherwise, it's basically just a support user role minus the ability to request on behalf of another entitled user. This should be fixed.