This would be a great improvement to have. Our company has an on-prem version which we would likely use windows auth but we are moving to the Azure so Microsoft Entra Id would be a great IdP to support for us
What do you currently use for user authentication?
Active Directory / Windows Authentication
Microsoft Entra ID (Azure AD)
What authorization capabilities would you like to see supported?
Role-based access control or Integration with roles/groups managed by your identity provider
What auditing requirements do you have?
User activity auditing
Exporting audit data to SIEM or log management platforms
For reference, everything in our Azure environment runs behind private networking / endpoints and we have run into a bunch of different issues because of that. Something to consider when designing this out
Would it be sufficient that if we would have a “reader” and “writer” role that you have add to your IDP to be present in the token for out platform to check access?
Would such an approach work for your org? If not, providing more context would be appreciated. If you have any minor or important requirements do share them here on on this issue.
Would it be sufficient that if we would have a “reader” and “writer” role that you have add to your IDP to be present in the token for out platform to check access?
We might need a bit more gainularity, maybe an admin role as well. Not sure what was envisioned for what they would be able to do with reader vs writer. If reader is → able to just see the everything without ability to retry anything and then writer can do anything within the app? Maybe an admin or some higher priveledge role to allow update the configuration section, allowing the edit message functionality. Those are the two things we might consider having slightly higher permissions for a user
As far as the auditing stuff, the OTEL stuff would be ideal for us as we already utilize that just about everything
Sorry I’m a bit late to join the discussion, but here is my feedback:
Authentication
Active Directory / Windows Authentication
Microsoft Entra ID
Auth0
OpenID Connect
Auditing
All requirements listed in the initial post.
Authorization
Due to our federated structure with various independent teams that each manage their own endpoints, we currently have a complex set-up of 30+ different ServicePulse/ServiceControl instances, one for each team. Access to each instance is regulated in IIS: a user has access to an instance or not.
This was done because our business is dealing with sensitive data (Payroll) and we missed more fine-grained authorization capabilities in the product. Having authorization built-in in the product will allow us to drastically reduce our complexity by setting-up 1 single instance and configure what the team members can or cannot do, based on their role and/or group:
Per endpoint:
List failed messages
Read failed messages
Read failed message headers
Read failed message data
Retry failed messages
Reroute failed messages
Delete failed messages
Clear the input queue
Delete subscription(s)
Delete the endpoint itself.
Mark an endpoint as favorite (to limit the amount of queues in the (monitoring) views to a workable amount.
Per message type:
Read failed message data (overrides per endpoint authorization)
AD / Windows auth will only be supported via IIS reverse proxy. Entra, Auth0 are already supported via OpenID connect.
Auditing:
We will have a structured audit log for API allows/denies and per action audit trail via OTLP (Open Telemetry)
Authorization:
In the upcoming release we have defined 3 roles reader, writer, admin, so “Update license” is separated from the writer role.
Resources scopes:
Both message types and endpoint information is part of the message headers (FailedQ and EnclosedMessageTypes). Without exactly knowing how we will be implementing resource scopes we will likely have behavior that can obtain a specific value from a claim that we can match against a user configured header value. However, we are not sure how to implement this from a UI perspective. For example, should the whole UI support partitioned views based on these filters or would it only be sufficient to apply these filters when actually viewing message details or when the message is archived/retried.
You now having this context, how do you think your request that per message type should override per endpoint auth? Could you provide some pseudo rules/flow? We can use that input to craft an improvement issue when adding support for resource scopes.
My previous estimation of 30+ servicepulse/servicecontrol combos was a bit low: we have more than 50 in our 3 production environments (production, customer-test & production for ourselves, which is totally separated from the normal production environment, due to the highly sensitive data that we handle).
If we would combine all 50 in 3 instances, imagine being a team member of one of those 50 teams that needs to monitor how the team’s endpoints are doing and what messages have failed.
You would get a view with more than 700 endpoints and on a bad day thousands of failed messages. Good luck finding what’s relevant for you. Ideally, you wouldn’t want to be bothered with alerts of non-response endpoints from other teams, nor with failed messages reported by these non-relevant endpoints. If hiding them based on authorization rights is not possible, you should at least have a way to switch between viewing everything and your list of “favorite” endpoints and their failed messages.
As for the “message type” question: some events or commands contain sensitive data, which may or may not be encrypted. Besides auditing who accessed the message data, we would like to effectively limit the access to the message contents of some events or messages to individual team members that have signed an NDA, no matter in what endpoint the event or message was processed.
I hope this makes things a bit clearer.
The rest of the requirements I mentioned are some minor things that we are missing, like the possibility of removing one or all subscriptions for a endpoint that was decommissioned, without needing to deploy a dummy version that unsubscribes itself, or manually deleting the subscription records directly in the database.
Or completely clearing the input queue, or all messages of a certain message type for an endpoint in trouble without needing the help of a DBA.
The message type restriction seems more like a not authorized to view, then it is to retry.
It makes sense to block access to certain messages types even when authorized for the queue/endpoint. I now understand your requirement and I think here you would want to act it like and AND filter. User must match all filter that can match against certain properties for it to be viewed.
Some of your request aren’t specific to feature we have like unsubscribing. What I understand from that request is that you would like to see a feature that allows to unsubscribe detected subscriptions from ServicePulse. I don’t think such a feature request exists for that yet but do agree that if such a feature existed that it should only be permitted by a certain (admin like) role.