Hello,
We are using the Australia release and are planning to make the Service Status Subscription Widget available to external/customer users through our portal.
Based on my review of the widget, it appears to require access to the following tables:
- m2m_sp_status_subscription
- cmdb_ci_service
It also appears to rely on the following OOTB roles:
- service_status_subscriber
- service_viewer
Our concern is that the service_viewer role provides broader access than we would like to grant to customer users. Ideally, we would like customers to have read access only to the cmdb_ci_service records required for the widget to function.
In addition, the description of the service_status_subscriber role states:
"This role grants users the ability to subscribe to and unsubscribe from service status updates on the Service Portal. Users with this role can read, create, and delete their own service status subscriptions in the Service Portal service status page."
However, in our testing, users appear to be able to view and update subscription records that do not belong to them. Because of this, we are also reviewing the security model around the m2m_sp_status_subscription table.
For those who have implemented this widget for external users in production:
- Do you assign the standard service_viewer role, or do you replace it with a custom role and ACLs?
- How do you restrict access to cmdb_ci_service while keeping the widget functional?
- How do you secure the m2m_sp_status_subscription table?
- Have you implemented additional record-level ACLs to ensure users can only access their own subscription records?
- Are there any tables, ACLs, or widget customizations that were required beyond the OOTB configuration?
I would appreciate any recommendations, best practices, or implementation experiences.
Thank you.
